使用字典替代拼写转换算法和输入法

由pr: https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant/pulls/21
引入了自定义字典的方案, 我认为是非常实用的想法.
并且在[这里](https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant/pulls/21#note_14014992_conversation_67021512)提到了一些输入法, 通过使用这些自定义字典, 做到一些创新的输入方法.

我已经合并了这个pr, 并且做了一些修改和重构后, 提交到了master分支.(还没有发布新版本): https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant/commit/f16cf6ce809f850aeb9635334e7c5883840b78fd

在整理代码的过程中, 我有一些想法, 也许可以一并实现然后更新个大的:

## 1 字典替代转换算法

现在的实现中, 有一个核心的转换函数, 它输入一个拼写方式(例如"全拼","五笔98全码"), 和一个中文(例如"你好"), 返回该中文的拼写表示, 在这里, 会得到`["nihao"]`(返回数组是因为可能有多音字).
在这个转换的过程中, 现在的实现是, 对于全拼, 我们调用了库, 对于五笔, 我们也自己写了对应的库.
现在在加入"自定义字典"功能的过程中, 实现的方法是查询给定的字典文件.

那么也许可以统一, 只保留一种"查询字典"来转换拼写的方式.
我们可以预设不同的五笔, 拼音模式, 他们都是不同的字典.
用户也可以编写自己的字典.
最终, 用户可以选择一个或多个字典.
这是一种更通用的方法, 并且也能简化代码的逻辑.

这个字典的方案似乎是这个叫rime的输入法的方案.
而这些字典也不需要我们自己编写, 这个项目中很多现成的, 例如:
- https://github.com/rime/rime-pinyin-simp/blob/master/pinyin_simp.dict.yaml
- https://github.com/rime/rime-cantonese/blob/main/jyut6ping3.words.dict.yaml
- https://github.com/rime/rime-jyutping/blob/master/jyutping.phrase.dict.yaml
- https://github.com/rime/rime-terra-pinyin/blob/master/terra_pinyin.dict.yaml
- https://github.com/rime/rime-middle-chinese/blob/master/zyenpheng.dict.yaml
- https://github.com/rime/rime-cangjie/blob/master/cangjie5.dict.yaml
- https://github.com/rime/rime-wubi/blob/master/wubi86.dict.yaml
- https://github.com/rime/rime-stroke/blob/master/stroke.dict.yaml

即使这些字典不全, 基于现有的生成算法, 生成对应的字典也不难.

这些项目的协议是LGPL, 只要不修改这些代码, 我们的协议就不需要修改.

## 2 字典实现输入法

我注意到这些字典里不止包含单字, 有些还包含着常用的词语, 应该可以用这些实现本地的输入法.

## 3 累计自定义词库功能

之前提到过自定义词库功能: https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant/issues/I1NZWJ

这也可以作为一个字典, 通过某种算法确定用户输入的高频词后, 将其写入到这个字典文件中即可.

---

综上, 我觉得这是一个很有搞头的事, 可以大大增加可配置性和输入法体验.
不知各位觉得如何?

@zhishi @zj1d @ijklam

千万不要被gpl传染

LGPL, 只作为引用的话不会被传染.

1 是的, 主要目的是使用统一的模型, 这是实现更强大功能的基础.

如果软件的功能是几个不相关的无法连接的小功能拼凑的, 那么这几个小功能都不能得到更好的发展, 扩展到一定程度后, 他们就会互相冲突. 如果能用一个统一的模型解释他们, 就可以继续扩展了. (当然, 模型也会带来僵化, 对模型涵盖范围之外的功能就比较难加进来, 但我认为建模依然是利大于弊的, 任何复杂的功能都有模型做基础.)

2 输入法的核心机制就是输入给定的字符串后, 将这个字符串转换成一组候选的汉字, 然后由用户选择一个.
如果只考虑这一点, 那么在本插件中, 可以很容易的实现, 只需要读取用户现在输入的字符串, 然后通过比对字典获得候选词, 加入vscode的补全项中即可.

这其中的核心算法, 也就是比对和选择候选词的算法, 这非常简单, 只需要简单的对比输入字符串和字典的开头部分做筛选即可.
所以不太需要移植rime的代码, 因为这段逻辑足够简单.

不过, 如果我们要做更好的输入法, 那么就要考虑更多的事, 我想到的有几点:
- 不是简单的通过字母匹配, 而是允许模糊匹配. 例如, 若字典中有"nihao=>你好"这样的对应, 如果按简单匹配, 用户必须完整的键入"nihao", 至少要键入"nih"这样的字符串, 才能匹配上, 而输入"nhao"这样是不行的(前几个字母必须完整匹配). 但一般输入法中输入"nhao"也可以打出"你好", 这就有一些模糊匹配的算法.
- 能"记住"用户的常见选择, 提供更好的补全项, 就是一个词打多了它就排在第一个了, 现代输入法几乎都可以做到这一点.
- 能主动"记住"用户的自造词, 输入一个网络流行语之类的, 多输入几次输入法也会记住这个词, 现代输入法几乎都可以做到这一点.

要实现这些高级功能, 需要考虑更多的算法, 也许参考rime的代码也可以有一些启发, 不过任何输入法应该都可以.

---

上面提到的"更好的输入法"的第三点其实就是 https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant/issues/I1NZWJ 所说的功能.

而 https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant/issues/I5RJXG 也可以看作这个"更好的输入法"是一种扩展, 即"参考上下文提供更好的候选项". 只是现在的输入法还没有做到这一点, 可能是受限于操作系统, 也可能这是个馊主意, 或者也有输入法实现了只是我没有注意到?

这样一看, 甚至可以说现在实现的补全功能本身, 也是一种实现了"参考上下文提供更好的候选项"的输入法. 只是这个参考的上下文更大一点, 不但参考了当前文本, 还参考了vscode提供的信息.

这又回到了1上, 目前的补全功能, 自定义字典功能, 输入法功能, 以及构想中的"更好的输入法"功能, 这些功能其实全都可以统一为一个"基于vscode实现的输入法"这样一个模型上, 我们可以先实现这个模型的部分功能, 以确保现有的功能不会退化, 而剩下的"高级功能"也可以慢慢补上.

更重要的是, 转换了模型之后, 我们能做的事情就更多了, 从最开始的"给补全项加拼音"变成了"输入法". 以前我们局限于"给补全项加拼音", 所以如果vscode不返回合理的补全项(例如c++的情况), 我们就束手无策, 虽然我们也可以引入"自己分析代码结构"这样的手段, 但无法自圆其说, 不能解释为什么"给补全项加拼音"的软件里会加入"分析代码结构"的功能, 以及这个功能的定位是什么, 放在哪里, 怎样调用. 但如果考虑我们是"输入法"的话, 我们就可以解释"分析代码结构"的定位: 一种输入法依赖的上下文. 这样就可以清晰的实现这个功能而不产生混乱.

现在的模糊匹配是倚靠vsc的匹配机制吧？比如输入 nh 匹配到 你好。
感觉这个方向会在某种程度上代替vsc的匹配机制和代码分析功能，空间的确很大。
也许先从几个实例开始作些需求用例分析？

是的, 现在的模糊匹配是依赖vscode的机制, 但并不能移植到输入法里.
我最近有空的时候尝试写个初步实现看看效果.

关注下进展，实现一个内置输入法的想法很有意思，也确实能很大地增强体验，但是分析代码上下文结构带来的阻力是相当大的，依附于现有 IDE 的生态体系可能还是会省心些

啊哈哈慢慢来最近有点忙在写了在写了(进度0%

刚看这个 rust反馈，印象里之前也碰到过对各语言辅助插件的依赖导致的限制或冲突。对这个设想不知影响大不？

是的, 会有所帮助, 虽然没有细看vscode的实际运行结果, 但估计就是插件并没有返回我们预期的结果.
可行的方案是手动调用插件获得结果, 但这涉及到其他的问题, 例如如何调用语言服务, 如何确定排序之类的...

进展: 我实现了字典树来查找字典, 以此封装了一个依赖本地字典的输入法, 效果:
输入图片说明

看起来还不错, 也没有很慢, 这还没做优化, 可以限制结果返回数量, 还有很大优化空间.

可以先在字典方案分支上体验一下.

赞。刚试了，对标识符补全没啥影响的样子，挺好。
输入图片说明

之前提到的常用词覆盖情况和速度感觉怎样?如果作为本地输入法实现是否算是好用呢?
当然还有很大优化空间, 现在只是基本demo.

个人感觉速度已够用，不大确定的是多出来的那些补全项对用户感官上有多大影响。

刚试了这里的“消耗气力”，发现如果先输入了“消耗”，继续输qili没有触发补全：
输入图片说明
另外，如果已经输入过“消耗气力”，也许以后输入qili时，就可以把“气力”优先级上升，现在是这样：

这大概就和积累词库和调整优先级那两个issue相关了。

另外，如果输入“shifangf”（释放范围），因为匹配不到词补全弹窗会消失（不意外），但此时退格删除最后的f也不会再次触发弹窗。
进入输入法领域，感觉很多工作量会在细节上。个人也倾向步子跨小些，其实从自己需求出发就挺好，先做到最基本功能。

是的, 很多细节还在想...

有几个要讨论的点.

首先先整理一下思路.

理想的工作模式是:

用户键入一些字符.
通过用户输入的字符和当前上下文, 得到一个中文的列表.
- 为方便讨论, 我们假设有函数: 计算补全项 :: 用户输入字符 -> 上下文 -> Array<中文>.
- 上下文指的是一切可以参考的东西, 比如当前语言, 当前代码, 当前工作区文件, 操作系统, 时间, 一切程序能获得的东西都可以看作上下文.
将上一步得到的中文列表显示出来, 并可以按一定方法排序, 供用户选择.
- 假设有函数: 排序算法 :: 中文 -> 中文 -> Bool.
当用户选择某补全项后, 将用户选择的项对应的插入文本插入到光标位置.

这个过程中有很多细节:

目前这个计算补全项的数据来源包括很多部分:
- 调用vsc的api得到的结果
- 当前文件做分词后得到的结果
- 本地字典得到的结果, 用户可以指定一个或多个字典.
- 网络输入法得到的结果
- 按语言分析项目结构和代码得到的结果(也许未来会有)
- ...更多可能
一个已知情况是, vsc的api表现不稳定:
- 对于js这样语言, 它返回的结果和当前输入的字符串无关.
- 对于python, c这样的语言, 它只会返回和当前输入有关的补全项.
- 不知道为什么存在这样的差异, 但从经验来看, 自带的语言服务是前者, 例如js,ts, 依赖插件的是后者, 例如c, python.
- 看起来只返回和输入有关的才是合理的, 但考虑这个情况:
  - js:
    - 在一个A.js中引入了B.js, 而B.js中有一个"你好"的变量.
    - 在A.js中输入B.的时候, 可以从vsc的api中得到你好这个补全项.
    - 在A.js中输入B.n的时候, 依然可以从vsc的api中得到你好这个补全项, 因为在js中返回结果与输入无关.
    - 所以我们能跨文件的引用其他文件中的中文变量.
  - py:
    - 依然是有一个A.py和B.py, B.py中有一个你好的变量.
    - 在A.py中输入B.的时候, vsc的api提供了你好这个补全项.
    - 但如果继续输入到B.n的时候, vsc的api就不再提供这个补全项了, 因为py中返回结果和输入有关, 而n和你好没有交集.
    - 因此对于py这样的, 在跨文件的情况下中文变量补全体验不好.
在将中文列表作为补全项显示出来的过程中, 原理是设置补全项的filterText字段.
- 规则是, 若当前本次正在输入的字符和filterText的开头一致, 则这个补全项就会出现.
- 这里本次正在输入的字符是vsc决定的, 是实际本次输入的, 不会考虑前后文, 比如输入在已有的ni字符后面输入h的时候, 就会被算成h, 对于英文, 就是每次都是输入的那个字符, 对于中文, 如果你用输入发直接输入你好就会是你好, 不会分解成'n''i''h''a''o', 只有当按空格或回车将中文实际打上去的时候才会触发这个过程.
- 这个属性仅仅是用来决定某个补全项是否要显示的.
可以再设置补全项的sortText属性, 这个属性会决定补全项的顺序, 当然, 前提是补全项已经通过了filterText的检查, 不然就不会显示.
最后可以设置补全项的insertText属性, 这个属性决定补全项实际插入的结果.
- 需要注意, 之前得到的中文并不一定就是最终插入的东西.
- 一个可能的用途是片段, 例如可以提供一个加法片段的补全项, 你可以输入jiafapianduan来看到它, 但你选择后并不会插入加法片段, 而是插入var add = a => b => a + b.

这其中需要决定一些问题:

用户键入的字符是否应该假设为字母? 如果用户键入汉字, 我们应该怎么做?
连续输入的问题, 例如文件中先有了ni, 此时用户在这后面紧接着输入h, 我们应该认为输入字符串是nih还是h?
连续输入的问题, 混合情况应该怎样考虑:
- 在你的后面输入h
- 在ni的后面输入好
- 在get投入产出的后面输入b
如何优化py这样的语言的跨文件体验
- 一个可能的方法是, 在输入B.的时候, 缓存vsc提供的项, 并且在输入到B.n的时候加入计算.
如何设置filterText
- 一个方案是, 通过字典反推, 字典提供了汉字和字母的对应关系, 可以一个将汉字转换成字母, 连起来, 就可以作为filterText.
- 这样的话, 这里使用的字典, 和计算补全项中的字典是否要用同一组字典?
- 是否还有其他方案?
如何设置sortText
- 需要一个排序算法, 或一组动态的排序算法, 在不同情况下返回不同的排序.
- 可能还会有一个文件, 记录一些内容, 作为排序的参考.
- 还没具体想.
如何设置insertText
- 永远和之前得到的中文一致吗?
- 是否要允许用户通过配置文件自定义某个补全项对应的insertText?

目前只想到这些问题, 也许在实现的过程中还会有其他问题.
我先按我个人的想法处理这些问题, 对于这些问题有什么想法可以在这里讨论.

多谢详细阐述！
功能和实现细节已展开很多，个人尝试描述一下宽泛的业务需求，看看是否和设想功能一致。 注：仅作讨论分析用，不是第一阶段目标。

借助用户输入和现有代码，提供用户需要的中文代码。“代码”也包括文档和注释等。“提供”可以在补全时进行，也可以在对有错代码“quick fix”时进行。“用户输入”包括中文和英文输入。

谢谢告知。
首页说明变动很大。
本以为只会对修改或增加的功能进行说明。像snippet中文补全功能应该还有吧？

另外一些用语如“中文拼写”和“符号分词”感觉有待商榷。
建议渐进式修改，可以更清楚看出哪些功能有变动，也便于讨论。

snippet的功能并没有删, 文档漏写了, 我之后补上.

我主要修改的地方就是那些对某个语言的测试图片, 上面也说了.

我觉得演示不同语言的运行情况似乎意义不大, 我觉得有些偏离重点. (也许可以放在单独的文件里?)

删了后基本就没啥东西了.

主要是我觉得作为首页文档应该干净整洁有逻辑, 贴太多图片影响对整体的观感, 而且这些图还大小不一...

我觉得对不同语言的测试图片意义不大, 如果你觉得很重要的话, 我把它整理到单独的文件里, 然后在主页放个连接怎么样?

本来是想写拼音的, 但想到还可能有五笔或其他输入中文的方法, 就用了中文拼写, 有更好的建议吗?

一般我们说的分词是比较智能的分词, 比如你好世界会分成你好和世界, 但现在我们的分词实现不是这样, 只是简单通过标点符号做分词标记, 比如类型包含: 字符串, 数字, 布尔这样, 才会分出来字符串``数字``布尔这些词, 所以我用了符号分词这个说法, 有更好的建议吗?

snippet的功能并没有删, 文档漏写了, 我之后补上.

好，谢谢。

我觉得对不同语言的测试图片意义不大, 如果你觉得很重要的话, 我把它整理到单独的文件里, 然后在主页放个连接怎么样?

当时是想作为演示之用，现在看来效果有限。按你所说处理吧，也可作为 文档/功能简述.md 的补充。

关于用语，是否可以从更单纯功能的角度描述？当前的功能已相当于支持拼音等各种模式的内置输入法。相对于普通输入法，长处在于根据代码上下文决定排序。感觉类似这种介绍更简明且易于理解。

至于分词的细节，个人感觉属于内部细节，可以放在 功能简述.md 中，不一定要放在首页。

“在配置中配置”有点拗口。

关于字典的说明是指这篇吗？看起来不错。“同时使用”的意思是，比如有简体拼音和繁体拼音字典，输入拼音后会同时提示简体和繁体词语？

另外，导入操作从这里看还是有点门槛。大多数用户在这次升级后是否可以不用额外操作正常使用呢？换言之，默认配置状态下，原本功能有哪些变动呢？

好的, 改成"可以在配置中调整"怎样?

字典有两个, 一个是"拼写字典", 一个是"本地输入法字典".
拼写字典是决定"如何把中文翻译成拼写"的, 输入法字典是提供"输入法词组"的.

插件的工作原理是通过上下文搜集一些中文, 然后将这些中文转换成拼写, 如果转换出来的拼写和用户实际输入的字母有重叠, vscode就会显示这个补全项, 这个转换的过程使用的是"拼写字典".
而"本地输入法字典"的工作方式刚好相反, 当用户输入一些字母时, 插件会按照这些字母搜索输入法字典中对应的中文, 将中文加入补全项, 这些补全项会和其他来源的补全项(例如vsc提供的, 文件分词的, 网络输入法的)一起被转换为拼写, 然后按用户输入的筛选, 显示.

总的来说, "拼写字典"是核心的, 决定着我们用拼音还是五笔还是什么输入方法来输入中文.
而"本地输入法"只是一个扩展功能, "本地输入法字典"只是为这个功能提供词组.

对于"拼写字典"而言, 比如同时开启了拼音和五笔, 那么就既可以输入拼音, 又可以输入五笔, 都可以得到正确的结果.
对于"输入法字典"而言, 同时提供多个字典, 意味着同时有多个词组的来源, 比如如果同时提供的简体拼音和繁体拼音, 那么本地输入法里就即有简体又有繁体.

我这里的导入操作并不复杂, 只要提供字典的路径即可.

3 我预想的默认配置是使用简体全拼, 就是字典方案分支现在的样子. 这应该和当前商店的版本体验区别不大.
另外会提供几个其他的字典, 例如各种双拼, 五笔之类的, 用户如果要使用这些, 则需要自己去vscode的配置中配置一下, 方法是:

输入图片说明

可以在配置中调整

嗯好些。

则需要自己去vscode的配置中配置一下

之前那样的下拉选择感觉更友好些。

感觉一些使用上的细节还有改进空间，比如：
输入图片说明
发布版的是这样：

要不以你的使用感受为准，在可以接受的范围内就可以发布，以后根据进一步使用和用户反馈慢慢打磨。

另一种比较稳妥的方式是提供新旧两种模式，用户在新版本有使用问题时可以选择切回老模式。不过这样维护成本比较高。

@zhishi 前一阵比较忙, 现在我又回来搞了orz

我在整理码表了, 有一个问题请教一下, 我注意到之前的版本支持四种五笔:
- 86 全码
- 86 四码
- 98 全码
- 98 四码

但我看了之前版本实现的代码:

```
import { 首字母大写 } from '../扩展/字符串扩展'

const 码表 = require('wubi-code-data')

function 五笔(文字: string, 提示方式: string) {
  if (!文字) return ''
  var 键码 = ''
  var 非汉字字符计数 = 0
  var 版本 = 提示方式.substr(2, 2)
  for (var i = 0, len = 文字.length; i < len; i++) {
    var 字 = 文字.substr(i, 1)
    var unicode = 字.charCodeAt(0)
    //如果unicode在符号，英文，数字或其他语系，则直接返回
    if (unicode > 40869 || unicode < 19968) {
      键码 += 字
      非汉字字符计数++
    } else if (提示方式.indexOf('全码') != -1) {
      键码 += 首字母大写(码表.取码(字, 版本))
    } else if (提示方式.indexOf('四码') != -1) {
      if (文字.length - 非汉字字符计数 == 1) {
        键码 += 码表.取码(字, 版本)
      } else if (文字.length - 非汉字字符计数 == 2) {
        键码 += 码表.取码(字, 版本).slice(0, 2)
      } else if (文字.length - 非汉字字符计数 == 3) {
        键码 += 码表.取码(字, 版本).slice(0, i - 非汉字字符计数 < 2 ? 1 : 2)
      } else if (
        文字.length - 非汉字字符计数 >= 4 &&
        (i - 非汉字字符计数 < 3 || i + 1 - 非汉字字符计数 == 文字.length)
      ) {
        键码 += 码表.取码(字, 版本).slice(0, 1)
      }
    }
  }
  return 键码
}

export default 五笔
```

根本就没有判断是98还是86, 只判断了是全码还是四码.

因为我不会五笔, 所以我不知道是是否正常.
如果我想通过这个算法生成上面提到的四种五笔的字典该怎么做呢?
在项目rime中, 我只找到了一份五笔的字典: https://raw.githubusercontent.com/rime/rime-wubi/master/wubi86.dict.yaml
看起来是86版的, 是全码还是四码呢?

码表.取码(字, 版本) 里的版本应该就是 98/86。另见此测试：

    it('86牺', function() {
      assert.equal(演示.取码("牺", 86), "trsg");
    });
    it('98牺', function() {
      assert.equal(演示.取码("牺"), "csg");
    });

你我都不用五笔的情况下，个人建议改版的第一步迈小些，比如先做拼音字典。

哦哦, 我看到了.
那么先提供rime这个86的码表吧, 之后再扩展.
主要是我觉得升级如果将已有功能升没了不太好...

哦，升级之后没98的码表的话，用户就不能选择98版了是吗？
是否方便保留98版选项，然后这部分用老代码呢？

不太方便, 新旧代码的逻辑不太一样, 不过我可以试试把五笔的字典通过这个逻辑生成出来...

应该是这位加了四码支持。个人对五笔不大了解呵。
另外，这位对五笔数据很是了解。

233我还以为你是用五笔的呢

问了问神奇海螺, 输入图片说明 , 看起来挺复杂, 先提供现在这两个字典吧, 是从现在用的码表里抽出来的, 如果有错之类的, 或者要加入四码之类的, 之后如果有用五笔的人反馈再来改吧.

差不多搞完啦, 这几天我再做一些测试就发布!🎉

1.5.0版本已发布!

中文编程/vscode_Chinese_Input_Assistant

内容风险标识

评论 (36)

中文编程/vscode_Chinese_Input_Assistant .gitee-modal { width: 500px !important; }

内容风险标识