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

james_su

最初由 tram 发表
拼音输入法本身是有毛病的，从编码上来说，拼音本来就不是为输入准备的，所以只能靠程序来处理，而以五笔为首的形码，目的很明确，就是为了输入而准备的，程序就很简洁了。像拉丁文字，谁会考虑输入问题。泰国字一百多个字母，也就是很简单的组合一下就出来了。
做整句，如果到微软研究院那里看一下，就会觉得自己没什么好做的了，人家的语言学分析到那地步。

有一定道理hehe。

不过整句输入还是要做的，至少得做紫光那样的短语输入吧。

float

我一直都是用它里面的五笔功能，自安装以来，觉得它非常好用。

james_su

最初由 float 发表
我一直都是用它里面的五笔功能，自安装以来，觉得它非常好用。

我们在讨论拼音输入法呢。

另外，你用过 SCIM 里面的五笔没？有空可以试一下。除了不能反查拼音以外估计别的都差不多了。

liuspider

最初由 tram 发表
拼音输入法本身是有毛病的，从编码上来说，拼音本来就不是为输入准备的，所以只能靠程序来处理，而以五笔为首的形码，目的很明确，就是为了输入而准备的，程序就很简洁了。像拉丁文字，谁会考虑输入问题。泰国字一百多个字母，也就是很简单的组合一下就出来了。
做整句，如果到微软研究院那里看一下，就会觉得自己没什么好做的了，人家的语言学分析到那地步。

呵呵，同感，自从开始用 二笔后，我一用拼音输入法，不论是windows下的紫光和是微软，抑或SCIM中的，就是觉的不爽，按很多键才上去，还时常是错的，又要回头改，效率极低的说

个人感觉还是形码，或音形码较好

stormful

呵呵，真是一石激起千重浪。看来大家都非常关心拼音输入法问题。这是Linux中国用户的福音。我曾经在政府机关工作过，无论是早期还是现在，普及中国的计算机应用很大程度上就是普及拼音输入。

对于年轻人来说，使用其他输入法可能可行。但对于30－60岁的人来说就非常困难了。我在大学时使用的是五笔。基本上是普通录入员的速度。但写了这么多年的程序后，很多汉字已经不会写了。提笔忘字的情况频频发生。因此，我现在使用拼音。

我看到过很多输入法软件比较的文章。很少有不比较拼音的，而且是重点比较拼音。看来拼音有其独特的魅力和非常宽广的使用人群。对于中国大陆的人们来说，会使用的第一种输入法可能永远是拼音。呵呵，中国大陆这个范围有些问题，应该说是长江以北。

看了从昨天到今天的帖子，我有一个非常深的感触。什么样的拼音输入法才是好的拼音输入法。能不能列举出优秀拼音输入法的众多特点。有没有别人想做但不敢做的东西。也就是，能不能大家统计出一个目标目录？

我在写程序的时候感觉最困难的是概念的建立。能不能做和怎么做？这基本上都不是什么问题。问题在于要做什么。

看了很长时间我才明白james_su所说的智能匹配说的是什么意思。在这一点上我完全赞叹james_su的观点。要么我们不作，要做就做最好的。就算暂时达不到最好，也要努力。

微软拼音可能有非常多的语义学的天才。但只要有足够多的idea，就可以逼近它。我在寻找标准拼音表的时候曾经打开过微软拼音的数据文件。文件有很多，但大多数的文件头描述中有LEX字样。如果是词法分析的话，问题就不太复杂。

但紫光输入在其自己的说明中对于智能组词上好像更像上面所说的那个Next－ONE。这可能需要非常耐心的统计。

stormful

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

万字有一个 mo4 音。等等。

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

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

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

我从ftp.unicode.org下载了那个文件。说实在的没太看明白文件的内容。好像是一些辞海或康熙大词典的索引。如何能获取更近一步的内容。比如拼音的描述。或者词的主谓宾动描述？

这个文件的格式倒是非常简单。如果使用词法和语法分析。2个小时左右应该可以在内存中重现它的结构。

如果在这个基础上有更深一步的资料。非常有可能作出很多文章。

james_su

最初由 stormful 发表
我从ftp.unicode.org下载了那个文件。说实在的没太看明白文件的内容。好像是一些辞海或康熙大词典的索引。如何能获取更近一步的内容。比如拼音的描述。或者词的主谓宾动描述？

这个文件的格式倒是非常简单。如果使用词法和语法分析。2个小时左右应该可以在内存中重现它的结构。

如果在这个基础上有更深一步的资料。非常有可能作出很多文章。

你可以去 http://www.unicode.org/charts/unihan.html 看一下。

注意里面的说明：
# (I) Phonetic data derived from various sources

    * Chinese pronunciations
          o Cantonese (in a modified Yale romanization)
          o Mandarin (in a modified pinyin)
          o Tang dynasty pronunciations
    * Japanese pronunciations
          o Japanese On (Sino-Japanese)
          o Japanese Kun (native Japanese)
    * Korean/Sino-Korean

stormful

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

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

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

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

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

说到数据库的问题。这个话题就太多了。我在给diy添加数据库功能的早期，我就经常在想：在Windows下的某个程序员，如果有资料，如果有一个access数据库，当然懂一点ime api的话，在不考虑系统移植，不考虑内存，不考虑效率的情况下，是个人都能写出拼音输入法。有什么不比一个sql还有效么？

我今天才知道xsim使用的是数据库。呵呵，看来我并不孤独。我之所以要自己写一个数据库，是有其目的的。一方面，我可以完全控制索引的方式。另一方面，我每写一个程序都想给自己留下一个可纪念的东西。

在索引实现中怕的不是字多，而是字少。16个字的输入，太理想了。当然这是对于一个16个字的词组来说。在数据库模式下，而且是在拼音这种情况下。主要的问题是1和2的问题。1表示输入的第一个字，2表示输入的第一个2个汉字的词组。这是最困难的。再往下，重码率级低。基本上不要考虑了。

1的问题现在已经很好的解决的。我使用冗余索引花费了1M的文件空间解决了这个问题。而且再1的情况下，不用任何排序。2的问题是我今天研究的主体。呵呵，我正再矛盾中。

10M的空间，实在是太奢侈了。说实在的，我现在的14万的记录的空间文件空间是5.7M。这里面有14万的汉字或词组，还有32万的索引。

如果我开了一个6M的缓存，速度不会很慢的。另外，对于GBK中的大多数内容来说，是不会使用的，为什么么把它们加载到内存中哪？你完全可以使用一个缓慢增长机制呀。

如果从这一点来看，使用定制数据库还是可行的。用户如果想使用1M的空间，慢一点它也知道原因。呵呵，我使用过的设备，从来就没有低于512M。我开个20M的缓冲，我也理解。

james_su

最初由 stormful 发表
说到数据库的问题。这个话题就太多了。我在给diy添加数据库功能的早期，我就经常在想：在Windows下的某个程序员，如果有资料，如果有一个access数据库，当然懂一点ime api的话，在不考虑系统移植，不考虑内存，不考虑效率的情况下，是个人都能写出拼音输入法。有什么不比一个sql还有效么？

我今天才知道xsim使用的是数据库。呵呵，看来我并不孤独。我之所以要自己写一个数据库，是有其目的的。一方面，我可以完全控制索引的方式。另一方面，我每写一个程序都想给自己留下一个可纪念的东西。

在索引实现中怕的不是字多，而是字少。16个字的输入，太理想了。当然这是对于一个16个字的词组来说。在数据库模式下，而且是在拼音这种情况下。主要的问题是1和2的问题。1表示输入的第一个字，2表示输入的第一个2个汉字的词组。这是最困难的。再往下，重码率级低。基本上不要考虑了。

1的问题现在已经很好的解决的。我使用冗余索引花费了1M的文件空间解决了这个问题。而且再1的情况下，不用任何排序。2的问题是我今天研究的主体。呵呵，我正再矛盾中。

10M的空间，实在是太奢侈了。说实在的，我现在的14万的记录的空间文件空间是5.7M。这里面有14万的汉字或词组，还有32万的索引。

如果我开了一个6M的缓存，速度不会很慢的。另外，对于GBK中的大多数内容来说，是不会使用的，为什么么把它们加载到内存中哪？你完全可以使用一个缓慢增长机制呀。

如果从这一点来看，使用定制数据库还是可行的。用户如果想使用1M的空间，慢一点它也知道原因。呵呵，我使用过的设备，从来就没有低于512M。我开个20M的缓冲，我也理解。

我觉得你还是没有理解拼音输入法真正的问题所在。拼音输入法里面重码和词的切分是最要命的问题。比如：

wolunqifutoukanlexiaqu

这个拼音串一眼就可以看出是：

我抡起斧头砍了下去

但是你可以在各个输入法上试一下，看看有没有哪个输入法能够一次就能正确的匹配出这句话的。反正 SCIM 目前不行。

stormful

最初由 james_su 发表
你可以去 http://www.unicode.org/charts/unihan.html 看一下。

注意里面的说明：
# (I) Phonetic data derived from various sources

    * Chinese pronunciations
          o Cantonese (in a modified Yale romanization)
          o Mandarin (in a modified pinyin)
          o Tang dynasty pronunciations
    * Japanese pronunciations
          o Japanese On (Sino-Japanese)
          o Japanese Kun (native Japanese)
    * Korean/Sino-Korean

简单看了一下。呵呵，太困难了。好多单词不懂。不过好像只是拼音的内容呀。这没有什么用处。有文本的字典么？如果有人能搞一个文本的字典，无论多复杂的结构都是有办法的。

看来汉字输入法的数据来源真是太困难了。如果有一个文本的字典，常用词就太好统计了。而且有主谓宾动属性。实现逼进微软拼音的整句输入只是时间问题了。