词库管理
用户词库、临时词库、词频、候选调整四类数据的管理界面与操作,以及词库缓存机制
设置工具的「词库」页统一管理用户数据——你打过的字词、手动造的词、调频记录、置顶隐藏规则。所有修改即时生效。
词库类型与数据类别
页面顶部的「词库类型」下拉选择数据域——快捷短语(全局)或某个输入方案;下方子标签切换具体数据类别。
下拉里含全部已安装方案,不限于已启用的,也包括自制快符表这类特殊方案——它们各有独立的用户词库与词频记账,与主方案互不干扰。
选择方案后,可管理的数据类别随引擎类型变化:
| 方案类型 | 用户词库 | 临时词库 | 词频 | 候选调整 |
|---|---|---|---|---|
| 码表(含自制快符表等特殊方案) | ✅ | ✅ | ✅ | ✅ |
| 拼音 | ✅ | ✅ | ✅ | ✅ 0.115 新增 |
| 英文 0.114 新增 | ✅ | —— | ✅ | ✅ |
| 混输 | —— | —— | —— | ✅ |
三条容易困惑的地方:
- 英文没有临时词库——临时词库是自动造词的暂存区,而英文没有造词流程
- 拼音只能置顶,不能前移 / 后移——
position = 0(第一个)的含义不随候选集变化,而「第 3 位」在词频衰减、模糊音开关或词库变动后指的就是另一条候选了。0.115 之前拼音下三种调位一律禁用,正是出于后者 - 混输只有候选调整——不是功能缺失。混输方案自己不拥有词库,它的用户词库、临时词库与词频都按候选来源记在被引用的码表方案与拼音方案名下,在那两个方案下管理即可。见混输方案配置
全拼与双拼共用同一个数据域
双拼在词库页被折叠进「拼音」域。导出双拼方案得到的就是整个拼音家族的数据,导入亦然。
候选调整也一样共享,且编码会归一成全拼:双拼敲 hc(小鹤 = hao)置顶的词,切到全拼打 hao 同样生效,反之亦然。规则表里存的是 hao 而不是击键。
通用操作
- 搜索 —— 输入编码或词条即时过滤,编码支持中段匹配 0.113 新增:搜
ya也能搜到haoya,不必从头打起 - 排序 —— 点击表头按该列排序
- 分页 —— 数据量大时分页浏览
- 刷新 / 导入 / 导出 —— 见导入与导出
- 删除、清空等破坏性操作均有二次确认
拼音编码带音节空格 0.113 新增
拼音词库的编码在列表、搜索回显与「出码」按钮里一律显示成带音节空格的形式(ni hao 而不是 nihao),让词库真实的音节结构可见。存储侧不变,仍是扁平码。
由此多出一个用法:在编码框里手打空格即显式声明音节切分,优先于程序的自动推导——自定义切分或生僻音的词,打个空格就能把边界给准。搜索时带不带空格都能匹配。
直接打开到指定方案 0.113 新增
从功能主菜单选「词库管理…」时,直接落在你当前正在用的那套方案上,不再停在「快捷短语」让你再选一次。
要跳得更准,可以用命令行参数指定方案与数据类型:
wind_setting.exe --page dict --schema wubi86 --type shadow也可以挂成短语,用编码一键直达:
cods = $CC("五笔候选调整", setting.open("dict", "--schema=wubi86 --type=shadow"))取值与降级规则见设置工具的命令行参数。
用户词库
收录你手动添加的词,以及自动造词转正后的词条。
手动添加 —— 输入词条后可点「出码」按钮自动生成编码,也可手动填写;支持设置权重。此外可编辑、删除、清空。
也可以在输入时直接加词:Ctrl + = 就地加词(从当前组合造词),Ctrl + Shift + = 打开独立加词小窗。
英文方案的用户词库 0.114 新增
英文方案的用户词库收专有名词、缩写、项目内部词汇。编码就是单词本身的小写——英文词库以小写码做大小写不敏感的前缀匹配,加 WindInput 后打 wind 就能出。
带空格的(thank you)、非 ASCII 的(café)、一个字母都没有的(123)三类词加不进去,加词会提示无法计算编码。详见英文方案配置。
临时词库
自动造词的暂存区。 开启自动造词(码表)或自动学习(拼音)后,连续选字产生的新词组会先落在这里,记录使用次数——立刻可用,但尚未进入正式用户词库。
| 操作 | 说明 |
|---|---|
| 转正 | 把该临时词条转入正式用户词库 |
| 全部转正 | 一键转正当前全部临时词条 |
| 删除 / 清空 | 移除条目 |
用满「转入用户词库次数」设定的次数后也会自动转正。
词频
词频记录(count 使用次数与 last_used 最近使用时间)按「方案 + 编码 + 文本」存储。在这里可以删除单条记录(该词回落原始排序)或清空整个列表。
调频要不要开、按什么策略——那些是每种引擎的全局配置,在对应的方案配置对话框里。排序原理与三种策略的取舍见词频与候选排序。
记账用哪个编码:码表与拼音相反 (0.114)
这里的「编码」两类方案取法不同,是刻意的:
- 码表 —— 记你实际敲的输入码。
d/de/def是三个独立码位,各自的首选独立调整。这也是简码位首选保护按码长分档成立的前提 - 拼音 / 英文 —— 记候选自身的编码。候选码恒是这个词完整的读音或拼写,打
d选了「东西」之后打dongxi也该受益;而且拼音下不能用输入缓冲——双拼的siyr与候选码siyuan、带分隔符的xi'an与xian都对不上
0.113 及以前码表侧也走候选码,导致在 de 下选中「有」(它带的是全码 def)后,打 d 时它也跟着前移。0.114 已按候选来源分流修正。
候选调整
控制特定候选的显示行为,不修改原始词库数据,规则以一层 shadow 规则持久化在 userdata.redb。
| 操作 | 说明 |
|---|---|
| 添加 | 指定编码与词条,类型选固定位置(并填目标位置)或隐藏 |
| 编辑 | 修改已有规则 |
| 撤销 | 取消调整规则,恢复该候选的原始显示 |
| 清空 | 移除全部规则 |
日常使用中直接右键候选词选「置顶 / 前移 / 后移 / 删除 / 恢复默认」,或用快捷键(默认 Ctrl + 数字 置顶、Ctrl + Shift + 数字 删除),产生的规则同样在这里管理。
拼音方案下「前移 / 后移」是灰的,只有置顶可用,原因见上文的类型对照表。删除与恢复默认不受限制。
置顶是硬规则,比调频强得多
候选调整排在整条候选装配流水线的最后,晚于排序、去重、过滤与词频重排——它能翻过拼音的匹配层级闸门,而调频翻不过。
这也意味着置顶不会自己失效:它不随使用衰减,也不会被更常用的词挤下去。想撤销只能在本页删除规则,或右键那条候选选「恢复默认」(得先把它打出来)。给一个词置顶前,值得想一下是不是真的每次打这个编码都要它排第一。
置顶只作用于你当时敲的那个编码
在 hao 下置顶「好」,只影响打 hao 的时候;打 hao1、h 或整句里出现同一个词都不受影响——每个编码是独立的码位。
模糊音也不跨编码:开了 zh = z 时打 zang 置顶的词,打 zhang 不会跟着置顶,因为规则记的是你实际敲的那串。
拼音下想让某个词稳定靠前,调权重仍然不管用
拼音候选权重是百万级,单纯把用户词的 weight 调到几千不足以压过常用拼音词。要么用上面的置顶,要么给它一个不易与自然词碰撞的精确编码(例如 4 字母的 cobd),让它只在该精确编码下出现。
词库缓存与重建
首次加载 .dict.yaml 时会解析成二进制缓存(.wdat),存放在 %LOCALAPPDATA%\WindInput\cache,之后直接内存映射读取,省掉重复解析。
缓存按内容指纹校验,不看修改时间。以下任一情况会自动重建,用户无需手动干预:
- 词库文件内容变化(哪怕只改一个字节)
- 缓存文件或其指纹文件缺失、损坏
- 拼音词库的
import_tables子表增删或改动 - 程序升级带来了解析语义变更
- 词库的
type在english与其他类型之间切换
因为指纹基于内容而非时间戳,用 scp 部署、从版本控制签出等刷新 mtime 的操作不会触发无谓的重建;把文件改回原样也能重新命中旧缓存。
改了 .dict.yaml 之后不需要做任何事
下次加载该词库时自动重建。改方案文件(.schema.toml)同样不需要——base_order、default_weight、base_sort 作用在查询期的排序器上,根本不进缓存。
需要强制全量重建时(例如怀疑缓存异常),用命令行:
wind_input schema rebuild它会清空整个缓存目录。输出里若提示「M 个仍被占用」,是文件还处于内存映射中,再执行一次即可清掉,不影响正确性。详见命令行工具。
只投放 .wdat 而无 .dict.yaml 的词库无法重建
词库也可以只分发编译好的 .wdat 而不带 yaml 源。这种词库直接映射加载、完全绕过指纹校验;一旦加载失败会明确报错,此时只能更换词库文件,改 yaml 没有意义(根本没有 yaml)。
删除操作不可恢复
删除与清空操作不可撤销。重要数据建议提前备份。