如何为码表设置容错码？说得具体些，就是让所有的 ch 解释为 t？

嗯……转念一想，还是希望能让这份日文码表支持一些平文式的拼法，比如，允许使用 ch 来表示 t，允许使用 j 来表示 z 。对着帮助看了半天，感觉应该可以通过设模糊音来完成，但是无法成功。我所尝试的设置步骤如下：

1. 在 %AppData%/yong 下的 yong.ini 里加入fuzzy=...语句，具体来说就是：

[jpn]
name=日语大词库
engine=libmb.so
arg=mb/jpn.txt
overlay=mb/jpn.ini
beep=none
fuzzy=fuzzyjpn.txt

2. 在软件安装目录（我是C:\Program Files (x86)\yong）下新建fuzzyjpn.txt文件，里面写入

^=ch z t j
$=i
t*=ch*
z*=j*

3. 重启小小，切换到“日语大词库”输入法，只见CPU飙了一会儿，小小崩溃。

4. 尝试将fuzzyjpn.txt中的内容改为简单的

ti=chi
zi=ji

结果ji依旧无法解析，chi则被以一种奇怪的方式正确地解析了。它被解析成了“ch i”。

请问我的设置方式错在哪？我的操作系统是Win10 64bit。

另，我希望尽量避免“在主码表直接加入容错条目”这个选项，一来麻烦，二来担心出现性能问题。（之前试着把上面所链的码表编码改成了UTF-8，结果出现了明显的卡顿——UTF-8编码下整份码表大了约10M。）

再另，当前坛子是不是对Chrome支持有问题，“插入图片”之类的按钮点了没反应……已经关闭了Adblock Plus，也选择了“允许所有网站使用弹出式窗口”。

你的词库可能太大了，处理不过来，可以试一下在分词库中加容错看看（不知道速度能否顶住），加载慢尝试加入thread=1选项。

论坛没广告，所以adblockplus没影响。论坛文件上传用的是flash，可以检查一下插件是否启用。

dgod：你的词库可能太大了，处理不过来，可以试一下在分词库中加容错看看（不知道速度能否顶住），加载慢尝试加入thread=1选项。

论坛没广告，所以adblockplus没影响。论坛文件上传用的是flash，可以检查一下插件是否启用。回到原帖

欸，使用分词库不是比只用一个主码表更慢吗？（我是看了这帖的“挂载大的分词库速度慢”条目。）thread这个选项的设置位置是？自带帮助里搜不到……我现在用的小小是2016.6.25版，已用自带的更新功能更到了最新。


另，Chrome这边已经在“内容设置”里设了“允许网站使用Flash”，然而并没有用……但这疑似是Chrome自己的问题，因为在百度贴吧的私信界面，Flash插件也还是屏蔽状态。（但百度那边好歹还能手动允许……）， 我的Chrome是 58.0.3029.110 (64-bit)。

信至：欸，使用分词库不是比只用一个主码表更慢吗？（我是看了这帖的“挂载大的分词库速度慢”条目。）thread这个选项的设置位置是？自带帮助里搜不到……我现在用的小小是2016.6.25版，已用自带的更新功能更到了最新。


另，Chrome...回到原帖

http://yong.dgod.net/read.php?tid=11&fid=7 里有

dgod：你的词库可能太大了，处理不过来，可以试一下在分词库中加容错看看（不知道速度能否顶住），加载慢尝试加入thread=1选项。

论坛没广告，所以adblockplus没影响。论坛文件上传用的是flash，可以检查一下插件是否启用。回到原帖

……不知道为什么，我在顶楼提及的那种卡顿我今天重现不出来了……说得具体一点，我将这份日文码表设为了郑码码表的辅助码表，昨天的时候，在日文码表编码为UTF-8时，不论是作为辅助码表，还是直接切换，都会出现卡顿；但是今天，UTF-8的日文码表作为辅助码表很流畅，只是直接切换时有卡顿。（切换后立刻输字，要等一两秒才出字。之后正常。）


如果设置thread=1情况则会更糟，不设置时，只是头几个字（词）会延迟上屏，设了之后，头几个键直接输出了字母……


顺便打听一下小小的性能是受码表体积影响还是码表行数影响还是其他什么？

信至：……不知道为什么，我在顶楼提及的那种卡顿我今天重现不出来了……说得具体一点，我将这份日文码表设为了郑码码表的辅助码表，昨天的时候，在日文码表编码为UTF-8时，不论是作为辅助码表，还是直接切换，都会出现卡顿；但是今天，UTF-8的日文码表作...回到原帖

直接使用基本不会有速度问题，码表大了是加载慢。

码表体积和码表行数都是码表大了的表象。

dgod：直接使用基本不会有速度问题，码表大了是加载慢。

码表体积和码表行数都是码表大了的表象。回到原帖

又仔细试了一下，发现UTF-8编码下的码表（体积46.5M）在切换后立刻按键的话（我是通过连按a来测），延迟大概是六到七键，GB18030（体积35.6M）的延迟则是三键不到。看样子只能暂时不考虑加容错了。（数了一下，即使只考虑为ふ，じ，ち这三个发音与写法明显不同的假名容错，也会涉及27%的行……）



-------


不死心地做了一份……依旧是直接生成的主码表，GB18030编码下体积也达到了46.4M，用上面的方法测出来的延迟也是七键左右……


另，因为之前在这里提到的Bug，我没有用小小自带的工具对码表进行优化，但我已经合并了所有编码相同的条目并按字典序做了排序，所以效果应该差不多？

信至：又仔细试了一下，发现UTF-8编码下的码表（体积46.5M）在切换后立刻按键的话（我是通过连按a来测），延迟大概是六到七键，GB18030（体积35.6M）的延迟则是三键不到。看样子只能暂时不考虑加容错了。（数了一下，即使只考虑为ふ，じ，ち...回到原帖

优化包括按编码排序和同编码的字词放在同一行