四种拼音输入法的比较以及拼音输入法开发［讨论篇］

stormful

最初由 james_su 发表
什么叫最小匹配模式呀？能说的详细些么？不是很明白。

拼音规则的标准在网上不难找，google 一下就有了。

我现在最感到头痛的是汉字的标准发音。我在google上搜索了很长时间都没有找到相关的国家标准。winpy的码表根本就不能用，太多奇怪的拼音了。最后我使用了chinput的pinyin.map那个文件。

你有相关的资料或url么？能给我一个么？那真是帮了我一个大忙。

stormful

最初由 james_su 发表
智能匹配和数据库有什么关系呢？目前的 scim-chinese 的确是把所有数据都统统的装到内存里面，因为本身数据也不多，十几万词的词库也就才几兆而已，全部装到内存里面可以大大提高检索速度。

而我这里的智能匹配是指智能分词和词的匹配，例如输入以下一个拼音串：

woxiwanghenitaolunsuanfawenti

第一步要分解成正确的拼音串：

wo xi wang he ni tao lun suan fa wen ti

第二步要正确的按照语素进行切分：

wo | xi wang | he | ni | tao lun | suan fa | wen ti

第三步才是匹配成中文串：

我希望和你讨论算法问题

这个例子还是很简单的，很多情况下每一步都会有歧义，包括多音字，多音词等造成的歧义和不同的分词点造成的歧义。而且有些歧义是很难解决的，比如：

woyaoquxian

可以说成：我要去西安，或者 我要去先，歧义无法消除。

在diy设计的早期，我确实打算把所以的数据装在到内存中。呵呵，或许如果那样，这个程序早就提交了。但后来，我放弃了这种想法。一方面是因为我不想走别人的老路，另一方面，从某些实际情况为出发点的。

我们可以算一笔帐。GBK有2万个字，加上12万的词库。我们就有了14万的内容。

每个字或词都要有一个频率计数器，就用int吧，4个字节。平均每个字或词由2个汉字组词，这需要5个字节。在内存中维护词库树最简单的可能就是“键树”了，或许也是最节省的。无论是用数组维护节点还是用联表维护节点，至少都需要每个节点一个指针类型，4个字节。很有可能需要一个parent指针，4个字节。平均每个单元两个汉字，也就是平均每个单元2个拼音。就使用拼音缓冲吧。标准拼音至少有490个，因此每个拼音至少要有2个字节，也就是每个节点4个字节，另外至少要有一个拼音count统计，无论是使用count还是终结符号，至少一个字节。这样每个节点最少需要25个字节。这里还不包括编译器地址对其所浪费的空间。否则至少是28个字节。

140000 * 25 / 1024 / 1024 = 3.3M

呵呵，这可能是最小开销。其实这样的空间也做不出什么太多的花样来。普普通通而已。看来你正在实现整句输入。我对这东西不太懂。但至少需要字或词组的属性描述吧。但每增加一个字节，内存就有可能成兆的增长。

如果考虑到上面说的那个Next－ONE。这就有些不可想象了。

因此，我的测试目标是数据库原理，使用文件级的b-tree进行检索。关键在于各种缓冲机制。我写了一个小型数据库。呵呵，如果能够管理数据并能检索数据就算是数据库，那它就是数据库了。如何组织索引，另diy的缓冲机制更有效，是我现在研究的问题。diy的数据库和其他标准RDMS的区别在于它的索引是多对一的。

到现在为止，diy在2M情况下速度是非常正常的。基本上是毫秒级的。对于字的输入，diy根本就不需要排序，在索引中就已经排好了。在内存中排可能要比diy快。但到底能快多少哪？最好能给我一个统计数据，让我能够优化系统。

关于woyaoquxian的问题。我真是非常非常的感谢你。由于我还没有用diy输入过汉字，只是在控制台上测试，这个问题我根本就没有想过。呵呵，这就是讨论的价值，我欣赏。

用diy的拼音拆分程序其实只是一个43行的小程序。但它在这方面可能对xian问题有所帮助。由于是倒序匹配。它能匹配出两种结果。xian和xi'an。剩下的问题就是输入法实现的策略问题了。

stormful

呵呵，忘了说一个关于内存的重要问题了。我在看FCITX的代码时发现了太多的malloc了。这实在是太糟糕了。因为每个malloc都会浪费掉32字节的空间。

应该使用某种形式的内存池来控制内存的消耗。

对了，这里讨论的这么热闹。怎么没有看到fcitx的作者？

Kingo

最初由 stormful 发表
呵呵，忘了说一个关于内存的重要问题了。我在看FCITX的代码时发现了太多的malloc了。这实在是太糟糕了。因为每个malloc都会浪费掉32字节的空间。

应该使用某种形式的内存池来控制内存的消耗。

对了，这里讨论的这么热闹。怎么没有看到fcitx的作者？

真是很希望Yuking兄与楚狂兄都加入这个讨论呢，这样对于他们的输入法的开发应该大有助益，呵呵。

james_su

最初由 stormful 发表
我现在最感到头痛的是汉字的标准发音。我在google上搜索了很长时间都没有找到相关的国家标准。winpy的码表根本就不能用，太多奇怪的拼音了。最后我使用了chinput的pinyin.map那个文件。

你有相关的资料或url么？能给我一个么？那真是帮了我一个大忙。

奇怪的拼音根本不奇怪，好多字确实有很多奇怪的拼音，比如 石 字 就有一个音念 dan4.

万字有一个 mo4 音。等等。

其实我目前用的拼音表也很不标准，但没关系呀，手头就有标准：《现代汉语词典》。这个应该是权威吧？我花了很大力气把我手头的拼音表的常用字给校对了。基本已经够用了。

目前最全的，但也是相对不是很标准的拼音标注是 Unicode 里面的 UniHan 标准，里面有几乎所有汉字的拼音，包括大部分 GB18030 汉字。但是大部分多音字的拼音都有很多不标准的读音，有些是古代读音有些是方言。换句话说，UniHan 里面的拼音基本是标准拼音表的超集，需要精简。

你可以去 ftp.unicode.org 下载 Unihan.txt

james_su

如果用外存的话，我觉得还不如直接使用现有的数据库系统，像 xsim 那样。这样可以把主要精力放在中文匹配算法上，而不是数据库搜索算法上。

而且我觉得 3M 多的内存对现代计算机来说不算什么。scim-chinese 由于使用了 unicode，占的内存还要多很多，目前大概在 10M 左右，但 scim-chinese 以 10M 内存的代价实现了基本可用的整句输入，相对于智能狂拼这种上百兆的大家伙就不算什么了。

而且在真实输入系统里面，对算法性能的需求会远远高于你这样的实验系统。试想：如果要得到流畅的整句输入，用户每敲一个按键就必须把所有已经输入过的所有按键都从新分析匹配一遍，因为没准下一个按键就会使得已经输入的拼音串和词库里面一个词匹配上了。假设词库里面的最长词是16个字，那么至少最近的16个拼音键必须要重新分析匹配。

另外，真正耗时的算法是拼音串的智能匹配，也就是怎么把拼音串正确的转换为汉字串。用户每敲一个键，这个工作就必须重新做一遍。你试一下 scim-chinese 就知道了。当你输入的时候，所有预编辑汉字都会根据新输入的内容实时的自动匹配。

这样一来你就可以估计一下你的算法是否满足要求了。如果你在词库中搜索一个拼音串的时间是 1 ms 的话，用户输入一个20字左右的句子，平均估计得按100个键，也就是说最少必须搜索100次词库，但实际上搜索次数要比这个大得多，大概需要上千次，具体原因你可以先想想。这样算下来 1ms 的搜索时间就显得非常慢了。因为后期的匹配算法的复杂度大概要比这个高一个数量级。

最初由 stormful 发表
在diy设计的早期，我确实打算把所以的数据装在到内存中。呵呵，或许如果那样，这个程序早就提交了。但后来，我放弃了这种想法。一方面是因为我不想走别人的老路，另一方面，从某些实际情况为出发点的。

我们可以算一笔帐。GBK有2万个字，加上12万的词库。我们就有了14万的内容。

每个字或词都要有一个频率计数器，就用int吧，4个字节。平均每个字或词由2个汉字组词，这需要5个字节。在内存中维护词库树最简单的可能就是“键树”了，或许也是最节省的。无论是用数组维护节点还是用联表维护节点，至少都需要每个节点一个指针类型，4个字节。很有可能需要一个parent指针，4个字节。平均每个单元两个汉字，也就是平均每个单元2个拼音。就使用拼音缓冲吧。标准拼音至少有490个，因此每个拼音至少要有2个字节，也就是每个节点4个字节，另外至少要有一个拼音count统计，无论是使用count还是终结符号，至少一个字节。这样每个节点最少需要25个字节。这里还不包括编译器地址对其所浪费的空间。否则至少是28个字节。

140000 * 25 / 1024 / 1024 = 3.3M

呵呵，这可能是最小开销。其实这样的空间也做不出什么太多的花样来。普普通通而已。看来你正在实现整句输入。我对这东西不太懂。但至少需要字或词组的属性描述吧。但每增加一个字节，内存就有可能成兆的增长。

如果考虑到上面说的那个Next－ONE。这就有些不可想象了。

因此，我的测试目标是数据库原理，使用文件级的b-tree进行检索。关键在于各种缓冲机制。我写了一个小型数据库。呵呵，如果能够管理数据并能检索数据就算是数据库，那它就是数据库了。如何组织索引，另diy的缓冲机制更有效，是我现在研究的问题。diy的数据库和其他标准RDMS的区别在于它的索引是多对一的。

到现在为止，diy在2M情况下速度是非常正常的。基本上是毫秒级的。对于字的输入，diy根本就不需要排序，在索引中就已经排好了。在内存中排可能要比diy快。但到底能快多少哪？最好能给我一个统计数据，让我能够优化系统。

关于woyaoquxian的问题。我真是非常非常的感谢你。由于我还没有用diy输入过汉字，只是在控制台上测试，这个问题我根本就没有想过。呵呵，这就是讨论的价值，我欣赏。

用diy的拼音拆分程序其实只是一个43行的小程序。但它在这方面可能对xian问题有所帮助。由于是倒序匹配。它能匹配出两种结果。xian和xi'an。剩下的问题就是输入法实现的策略问题了。

Yuking

其实已经看这个贴子很久了，但现在讨论的问题对我来说已经太高深了，实在是搞不明白。不过，个人以为拼音的智能匹配似乎已经不是什么问题。事实上，在拼音输入法上，拼音的匹配问题早已经有了约定俗成的“标准”，比如"dange“就是要解析为"dan ge"而不是”dang e"，如果要改变它，用户就要适应这一变化----这显然是不合适的。fcitx的拼音起初就是以所谓的“最大模式”匹配，后来不得不改为目前的“最小模式”。

至于拼音的标准，象james_su说的那样，按《现代汉语词典》来做应该是最好的。只是目前的拼音码表都有这样或那样的错误或非标准，而依赖于这些码表的输入法必然会有问题。从这个意义上说，我们在这里研究拼音的匹配算法还不如找一帮人将《现代汉语词典》中所有单字录入到计算机中更有用处。

如果说拼音的匹配算法已经没有什么花样可翻新，剩下的就是资源占用、速度和功能的问题(功能自然没什么好说的)。资源占用和速度其实是对程序员的考验，有时二者不可兼得，象我这样的业余编程爱好者写出来的程序就存在速度上去了，资源也上去了的问题。

james_su

拼音匹配算法还是大有文章可作的，把 dange 解析成 dan ge 只不过是音节切分而已。下一步才是拼音切分，也就是把拼音串切分成拼音词串，然后才是拼音转换，就是把拼音转换成汉字。我把后面两不称作智能匹配算法。后面两步才是最复杂的。

最初由 Yuking 发表
其实已经看这个贴子很久了，但现在讨论的问题对我来说已经太高深了，实在是搞不明白。不过，个人以为拼音的智能匹配似乎已经不是什么问题。事实上，在拼音输入法上，拼音的匹配问题早已经有了约定俗成的“标准”，比如"dange“就是要解析为"dan ge"而不是”dang e"，如果要改变它，用户就要适应这一变化----这显然是不合适的。fcitx的拼音起初就是以所谓的“最大模式”匹配，后来不得不改为目前的“最小模式”。

至于拼音的标准，象james_su说的那样，按《现代汉语词典》来做应该是最好的。只是目前的拼音码表都有这样或那样的错误或非标准，而依赖于这些码表的输入法必然会有问题。从这个意义上说，我们在这里研究拼音的匹配算法还不如找一帮人将《现代汉语词典》中所有单字录入到计算机中更有用处。

如果说拼音的匹配算法已经没有什么花样可翻新，剩下的就是资源占用、速度和功能的问题(功能自然没什么好说的)。资源占用和速度其实是对程序员的考验，有时二者不可兼得，象我这样的业余编程爱好者写出来的程序就存在速度上去了，资源也上去了的问题。

Yuking

这样说来，还是拼音整句输入的问题。“输入法论坛”(URL一时想不起了)上好象曾经就基于词的第二代拼音输入法和基于句的第三代输入法作过讨论，结果是否定了第三代输入法。回头我找找，将那篇文章贴出来看看

Yuking

这是一篇较有名的评论文章，我贴的目的是看看从用户的角度是怎么选择的----在大部分情况下，编程人员和最终用户想的都不太一样……
---------------
我使用电脑中文处理十年来，因为自小学习熟练的是汉语拼音，所以拼音输入法用了好几个，先后有双拼双音，中文之星，智能ABC，微软拼音，紫光拼音，其中多有欣喜与无奈，比较优劣加上个人喜好，现在选中了紫光拼音。

在四通打字机和电脑的DOS时代，双拼双音输入法最受我喜爱，将双拼方案那三个特殊双字母声母和所有韵母位置记死，就可以享受常见且通用的词组一并输入了，这比惯用的单字母输入自然快了许多，也是能够流行的基本原因。但是这要死记硬背声母韵母在键盘上的位置，与多数声母在键盘上已经标出的位置有许多重复，不下一番功夫不行，便也吓走了不少用户。我就因为强记硬背个别声母和所有韵母的位置后打字显得很快而受到同事的赞许，还有些沾沾自喜呢。但是，双拼双音方案的常用词受到社会约定俗成的限制，与个人习惯不太一致，自己经常要用的人名地名及大量特殊常用词汇方案里没有，还是需要一个一个地单崩。而且方案里常用词的排列位置是死的，即使你使用了100遍，它仍然排在原来的位置，你可能仍然要翻页去后面寻找。再者是各商家的双拼双音方案不一样，那三个特殊双字母声母和所有韵母的键盘位置并不完全一致，使得我在不同的计算机上和不同的方案上需要部分重新记忆，这就令我混淆，造成了不便。


恰在此时，电脑进入Windows3.1时代，我惊奇地发现了中文之星拼音输入法，它的词汇自造和词频调整以及连续声母拼词汇的功能令我耳目一新欣喜异常爱不释手，这正是我使用多年一般双拼双音法所缺乏的所感不便的。我可以从拼出的单字里任意选择几个组成自己的常用词，而且根据使用这些常用词的频率，方案能自动将它们的排列位置靠前或靠后，我还可以减少对双拼韵母位置的记忆，这些都极大地缩短了我的词汇选择时间，写东西的速度明显提高，手动选择词汇对写作思维流的中断和影响明显缩小。此后很长一段时间，我都是使用中文之星，还写了一篇短文到报纸上赞美它。


后来，个人电脑操作系统升级到Windows95，又升级到Windows98再到Windows Me，及至现在的Windows XP，因为中文之星升级版搞不到，也因为发现了Windows自带的智能ABC输入法与中文之星有相似功能，便渐渐转向了智能ABC。它的优点是与中文之星相似，自造词汇词频调整连续声母拼词汇，大多数我喜爱的功能都在。但是，我慢慢发现它有些地方不尽如人意，例如，我对朋友打出：志强你好。那么我再次打出zhiqiang的时候，并不能出现志强，还是需要我去单字里寻找，而且“志”字“强”字都不能自动靠前排列，仍然固守它们原来的位置。又例如，我现在再次打出youliru，并没有出现“又例如”，而是出现5个发出youli声的词汇，我只能清除这些显示，重新输入you，寻找“又”，再输入liru，寻找例如来搭配。而且，它的词组不是逐个字母显示，而是最后敲一下空格才出来，因为总是不能出现自己期望的结果， 便令人每每担心自己刚才的辛苦输入是不是又成了无效劳动。这就多花了我太多的时间，增加了我对选择单字和词组的忧虑，天天要打出那么多的个人习惯用语，如此折腾如此反复，往往让人烦躁不已。这些例子说明，智能ABC还是受到社会常用词的过多束缚，对个人习惯常用词的自造功能开发比较弱，词频调整不完整也太不直观
。


这时候，有同学给我推荐了微软拼音法，说它有句子输入功能，且常用字词自动靠前排列，也即词频调整。词频调整功能不算新鲜，我正在使用的智能ABC也有的。但我想试试微软的词频调整是不是完善一些直观一些。用了以后感觉，比较智能ABC，微软的词频调整功能比较完善比较直观，例如，志强你好输入之后，以后再输入zhiqiang，就可以自动出现志强。再拿又例如来说，再次输入youliru，也可以立即显示又例如，不会出现重新组合单字和常用词组的要求。再就是整条句子输入，减少了选择单字和词组的麻烦。只要常用字词基本不出例外，那么打出一个句子的速度显然快了。从这点讲，我偏爱微软拼音法。但是，渐渐也发现一些毛病，有时候竟然到了无法忍受的地步。例如，一个朋友叫霞雁，我搭配着其它词组输入xiayan时，经常是出现夏衍或者瞎眼或者下咽，害的我总是在单字里面再分别寻找霞、雁两字，而且不管你改了多少次，夏衍先生的名字常常自动出现。又例如，“试试”这个词，也总是不听使唤，一旦与别的词组搭配，就不能自动显示了，总要再去单字堆里费力地搜寻。更令人烦恼的是，你如果失误输错了词组，那么以后这个错误词组就可能永远摆在第一位了，虽然可以在设置里选择删除自造词，但是一删就将所有的自造词都
删了，你的正确的自造词也没了，而你费了好多功夫才积累下来的自造常用词，可不希望一同消失。另外，微软拼音法号称整个句子输入，但整个句子输入过程中发生错误搭配的情况很多，输完之后再将光标返回来修改错误的字词，显然不如随时将错误字词修改为好，但是，这又和微软句子输入法强调的自适应词频调整功能发生了冲突，令人左右为难。我从微软拼音法2.0使到了3.0，这些问题依然存在，我深感不便。


就在这时，网上有人说发现了微软拼音法4.0试用版，我特感兴趣，我希望微软拼音4.0能够在词频调整的准确度和字词显示的直观程度上有所改进。于是，我就按照人家说的地方去找，结果并没有找到。我又跑到太平洋电脑城网站去找拼音输入法类别，也没找到。我有些失望，便在这里随意看看各种拼音输入法介绍，看看事过多年之后有没有中文之星升级版本在这里放着让人们使用。我注意到每种输入法介绍里都有星级评定，许多输入法评为三星级，而智能ABC和微软拼音都评为四星级，这与我的感觉一致。突然，我发现紫光拼音法是五星级，猛然为之一动,再看它的版本号是2.3，想到其它输入法都是三点几四点几的版本才最多到四星级，而紫光拼音才2.3的版本号却已经达到五星级的好用程度，我忍不住要试试。不试不知道，一试吓一跳，我的最大感受是怎么今天才见到它！它实在是太好了，自造词组随心所欲，任你有万千特殊组合；词频调整准确无误，真的是按照个人的使用习惯排列字词顺序；字词显示直观练达，错误拼成的词组自然被修正后的正确词组代替。我这么多年推崇的好的拼音输入法的特征这里都有，见过的讨厌的差的特征这里都没有，我都有些怀疑拼音法是不是已经达到了极限，紫光是不是终结了拼音输入。


以上是我的粗浅体会，也许不准确也许不全面，但是我现在实实在在地认准了紫光拼音输入法。(李海林)