将海峰五笔码表转换到 iBus 下使用

2010/05/13 | 23:09 | 分类:Linux与开源 | 标签: | 6,656次阅读

  Update 2011-01-13: 目前 ibus 官方网站已提供海峰五笔和极点五笔的码表下载(ibus-table-chinese)。经简单测试,这个极点五笔转换得似乎更好一些,词库、词频都没大问题。而这个海峰五笔的初始词频有一些问题,例如“nnnn”优先出“书局”而不是“已”、“yngk”优先出“记事”而不是“词”。对于我等不喜欢自动调节词频的用户,不甚方便。
  另外,从 ibus 的版权说明页看,目前极点五笔的授权还不确定,因此,不排除从 ibus 网站撤除的可能性。建议需要的用户下载存留。


  Ubuntu 早已使用 iBus 取代 SCIM 作为默认的输入平台了。但我一直还在用 SCIM,原因就是 iBus 的五笔码表实在有些问题:生僻字或繁体字常常排在常用的简体字前面。它默认会自动调节词频,虽说调节词频是解决上述问题的办法,但这与很多五笔用户的习惯不符。不过其实 SCIM 也有几处用得不爽,例如不方便输入书名号、破折号等。
  我今天简单研究了一下 iBus,发现自动调节词频是可以关闭的(在码表中,而不在界面或配置文件中);而它的标点符号输入也相对自然。因此,决定找一套好用的码表替代原有码表,进而尝试用 iBus 取代 SCIM。我选择了 Windows 下的海峰五笔(86版)码表:其一,它的词库规模适中,我在 Windows 下用过感觉不错;其二,它使用标准的 Windows 码表格式,便于提取数据;其三,作者在主页上宣布“鼓励大家反编译,定制自己的专用输入法”,这种开放的态度让我选择了它。
  将海峰五笔码表转换到 iBus 下,步骤如下:
  1.在 Windows 下使用海峰五笔自带的 ImegenU.exe 工具将编译过的 Sun86.mb 码表逆转换为文本码表 Sun86.txt。不要用 Windows 自带的 Imegen.exe,在实验时发现 Imegen.exe 会产生部分错误的编码,比如“跑”字,暂不知其中原因。
  2.将基于 UTF16LE.DOS.BOM 编码的 Sun86.txt 转换为 UTF8.UNIX.NON-BOM 编码,命名为 Sun86-u.txt。在 Linux 下可使用以下命令:

  1. iconv --from-code=utf16 --to-code=utf8 --output=Sun86-u.txt Sun86.txt
  2. fromdos Sun86-u.txt

  3.编辑 Sun86-u.txt,删除头信息,只保留码表。
  4.编写一个小程序(trans),将 Windows 文本码表转换为 iBus 文本码表,命名为 Sun86-i.txt。

  1. ./trans Sun86-u.txt > Sun86-i.txt

  5.下载 iBus 码表源代码(ibus-table-xingyin),从中提取出原版五笔的文本码表 wubi.txt。
  6.使用 Sun86-i.txt 中的内容覆盖 wubi.txt 的 Table 段。可保留 wubi.txt 中以 zz 开头的一系列非汉字符号的编码定义。
  7.修改 wubi.txt,禁用词频调整:

  1. DYNAMIC_ADJUST = FALSE

  8.编译并覆盖码表:

  1. bus-table-createdb -s wubi86.txt
  2. sudo cp wubi86.db /usr/share/ibus-table/tables

  9.重新登录桌面环境,新的码表即可生效。

  另外,在使用中发现 iBus 默认没有启用无重码自动上屏的选项。Google 了一下,可参考这篇的方法。直接修改 /usr/share/ibus-table/engine/table.py,找到:

  1. self._auto_commit = self.db.get_ime_property('auto_commit').lower() == u'true'

修改为:

  1. self._auto_commit = False

然后使用以下 python 程序:

  1. import py_compile
  2. py_compile.compile(r'table.py')

将其 table.py 编译为字节码文件 table.pyc 即可。

  编译好的海峰五笔(86版)for iBus 码表以及上面提到的 trans 程序源代码可在以下位置下载:
  http://files.linjian.org/c_cpp/SunWB-iBus.tar.gz

带有特殊符号的 SCIM 五笔码表

2010/03/17 | 22:23 | 分类:Linux与开源 | 标签: | 3,183次阅读

  今天有朋友向我询问在 SCIM 的五笔输入法下如何输入各种特殊符号。我们知道,SCIM 五笔所在的 scim-tables-zh 输入引擎功能并不强大,没有 Windows 下常见的软键盘等辅助功能。SCIM 五笔中也只对少数符号设置了编码,如“●”是编码是“pnll”(“实心圆圈”四字的编码),无法输入多数特殊符号。不过作为开源软件,SCIM 的码表扩展还是比较方便的。恰好我以前也被相同的问题困扰过,当时通过扩展编码的方式将区位码表加入了 SCIM 五笔码表。既然有人需要,那就把我修改过的码表略加完善,提供给需要的朋友使用。

  从这里下载带有特殊符号的 SCIM 五笔码表:
  http://files.linjian.org/c_cpp/Wubi-quwei.tar.gz

  如果懒得研究,则直接用解压后的 Wubi.bin 替换系统原有的 /usr/share/scim/tables/Wubi.bin。重新加载 SCIM 之后,可用以下编码输入区位码表中的特殊符号:

  第1区 符号 xxxf(“符”)
  第2区 数字 xxxs(“数”)
  第3区 英文字母 xxxy(“英”)
  第4区 日文平假名 xxxp(“平”)
  第5区 日文片假名 xxxq(与“p”相反的字母“q”)
  第6区 希腊字母 xxxl(“腊”)
  第7区 俄文字母 xxxe(“俄”)
  第8区 拼音注音 xxxi(“音”的韵首)
  第9区 制表符号 xxxb(“表”)
  GBK扩展符号A8区 xxxu(代表符号“╙”、“〒”)
  GBK扩展符号A9区 xxxo(代表符号“㊣”、“〇”)

  这里没有像 Windows 下的很多五笔输入法那样用“z”作为特殊编码的首字母,目的是为了保留“z”的万能查询功能。scim-tables-zh 并不能做更高级的定制,使“z”在不同场合下发挥不同作用。我选择使用“xxx”开头的几个空的编码位置容纳特殊符号,并尽量保证编码的名称有易于记忆的含义。
  如果想改变为其它编码方式,可以修改上面包中提供的 mkquwei.c 文件,并参考以下方式重新生成 Wubi.bin:

  1. gcc mkquwei.c -o mkquwei
  2. ./mkquwei > quwei.txt
  3. iconv -f=gbk -t=utf8 -c -o quwei-u.txt quwei.txt
  4. grep -v -P '\t\t' quwei-u.txt > quwei-f.txt
  5.  
  6. scim-make-table /usr/share/scim/tables/Wubi.bin -o Wubi.txt
  7. sed -i '$d' Wubi.txt
  8. cat quwei-f.txt >> Wubi.txt
  9. echo 'END_TABLE' >> Wubi.txt
  10. scim-make-table Wubi.txt -b -o Wubi.bin
  11. sudo cp Wubi.bin /usr/share/scim/tables/Wubi.bin

智能输入法软件的社会责任问题

2010/01/04 | 09:52 | 分类:IT杂谈 | 标签: | 3,602次阅读

  笑来老师前不久在 twitter 上多次讨论了两个话题:五笔与中医。于是,我于 1 月 1 日晚向他简要提了两句我对五笔和中医的理解[1][2]。1 月 2 日,笑来老师即发表博文称“现在的初学者最好别选五笔输入法”,不知算不算是对我的回应。那篇博文继而引发了一场令他心满意足的争论。感谢他在评论中提到了我的一篇旧文——尽管我也隶属于不赞同笑来老师那篇博文部分论点的行列。
  五笔与拼音作为两种思路迥异的汉字输入法,其争斗由来已久,我的观点已在那篇旧文中做了陈述。如果我有能力引导这场炒冷饭的争论,我不会再将五笔与拼音作为对比对象,而会将传统的、本地的、低智能的输入法(如五笔、郑码、Windows 全拼/双拼、智能 ABC)与新兴的、网络的、高智能的输入法(如谷歌拼音、搜狗拼音与五笔、QQ 拼音与五笔)作为对比对象。比较这二者,我认同后者中的很多理念必然成为未来输入法中的重要元素;但后者目前的技术实现、商业运营及其行业大环境,则不能令我满意。因此,我个人暂时选择传统的五笔,而对于所谓的智能输入法,谨慎观望与期待。
  我首先赞同智能化的大趋势,因为借助技术的进步来降低用户门槛、提高用户体验,是计算机历史发展的必然。对于笑来老师强调的 Google 那篇基于信息论的汉字输入法分析,我对其理论基础和技术愿景都是认可的。不同语言使用的字符集的信息熵不一致,在具有上下文的情况下,确实可以计算出“1 个汉字 ≈ 1.3 次击键”的公式。但对于经过长期历史演化形成的各种现代自然语言,我相信它们具有“表达相同的语义,击键次数基本相同”的特性——前提是所有语言都使用了基于上下文分析的智能输入法(想想手机上的 T9 英文输入法,它基于智能构词;看看国人开发的 Triivi,已经具备基于词组的智能匹配;再看看 eLocutor 这种为斯蒂芬·霍金教授设计的单键输入方案,成功地应用了基于语义的词语匹配)。因此,从这个角度说,即使是英文输入,未来的击键次数都有可能大幅减少。如果仅从输入效率和正确性角度来说,各国语言的输入法必然要选择智能化之路。只不过汉字的特殊性使它率先成为了探索的对象。
  无论借助机器性能的大幅提高,还是新的计算理论的突破,在单机上实现无误的上下文匹配的“1.3 键/字”输入方案都是很有可能的——但前提是语义连续、词汇库固定。语义分析是智能输入的基石,在输入离散内容(如花名册、生词表)时,语义分析随即失灵,智能优势不复存在。同时,再智能的算法也不可能预料“陈冠希”这种新名词的出现,新词入库需要外部机制解决。但在目前的技术条件下,互联网还没有进入自组织、自进化的智能阶段,所谓的社会计算仍然是程序驱动下的被动计算,所谓的网络语料库必然揉合了大量人工的或机械化程序的因素。作为一种过渡,我们可以接受现有的智能输入法;但作为一个技术愿景,它还有很长的路要走。然而,各种领域的智能化都会涉及一个“度”的问题:技术应该在多大程度上代替用户的思维?用户自己还需要保有哪些技能?技术的不恰当使用又会对这个行业乃至整个社会带来什么威胁?这些问题不得不牵扯到笑来老师不以为然的软件社会责任问题。
  首先,是用户对技术的可知、可控性。这有点类似 Richard Stallman 的自由观:你应该对保证你使用的工具是可理解的(当然,对于一般用户来说没有必要理解,但你不能放弃理解它的权力)、可限制其行为范围的。输入法作为一种较为基础而又相当重要的通用软件,应该由用户本人或者一套非专有的机制保证这一关键环节的可控性,而不能将其寄托在若干家专有的互联网公司身上。传统输入法的实践虽缺乏可知(不一定开源),但相对可控(没有联网操作)。我们应当期望智能输入法未来不再受控于专有技术和单一机构;即使依赖于网络,也能够在各类软硬件平台上出现一致的、无用户接口级差别的实现,让用户不再依赖于具体的产品。这一点类似于 Linux 之于 Windows——开源是次要的,派生和商业化也是可行的,但保障自由是关键的。
  其次,汉字输入是否需要作为一种技能而存在,这有待商榷。图形界面的出现让用户不再需要记忆烦琐的命令、Web 的出现让用户不再需要使用其它单调的网络信息协议,用户放弃这类技能是顺理成章的,因为在这些情况下技术对于一般用户来说是生产工具而非劳动对象,应当对用户保持简单和透明。但汉字输入究竟属于一般性的工具,还是属于公民语言文字技能的组成部分,这个定位会决定智能输入法应该智能到什么程度。如果它是语言文字技能的一部分,那么除了快速、正确之外,还有必要保证精确,即在掌握一个汉字的精确发音、写法的前提下,再掌握它的某一项精确的数字化属性,就算单字也可精确录入。目前而言,形码基本符合这一属性,而基于拼音的智能输入法反而更像一种“听写法”、“意识流记录法”,而非文字数字化技能。
  再次,是五笔之父王永民教授老生常谈的汉字教育和文化传承问题。王教授所谓的“拼音毁灭文化”的确言过其实、危言耸听,但目前已经被媒体关注的错别字涌现、提笔忘字等,确实成为了一种智能化引发“网民病”。这一点是输入法“简化记忆负担”带来的副作用,因此智能输入法至少不适合在语文教育的基础阶段推广。但因噎废食不是办法,最好依靠技术之外的社会方法来预防这些社会问题的发生。也许市场的细分可以缓解这一问题:针对一般网民或文秘的输入解决方案(智能输入法)、针对古籍或户籍等离散内容的输入解决方案(形码+基于专用库匹配)、针对速记和同传的输入解决方案(速录机),以及适合文化教育的解决方案(这可能不是单纯的输入法,而是与传统教育结合的整体解决方案)。
  最后,我要说的是当前软件行业的大环境给汉字智能输入法笼罩的阴影。上世纪末本世纪初,刚刚形成气候的中国共享软件生态圈就随着互联网泡沫的破灭而急剧缩水。然而中国民间的软件行业却没有因此销声匿迹,相反,它们探索出了一条“中aaa色”的发展模式:免费是王道(知道自己斗不过盗版);收费靠娱乐(网站形象秀和网页游戏的收入恐怕远大于商务邮箱);功能一定大而全(媒体播放器不管有没有侵权也要支持所有格式);界面一定酷而炫(杀毒软件也需要支持换肤、有卡通助手);对用户要体贴(帮盗版 Windows 用户安装安全补丁,屏蔽“黑屏”补丁);对同行不手软(输入法的强行排序、安全软件的误导性“警告”);对上游要服帖(建设产业链,有钱大家赚);无论何种应用,联网都是必须(还记得去年的“暴风门”吗),一方面可以向用户推送广告(人之常情,可以理解),另一方面则要对用户的行为乃至数据进行收集上报(名曰提高用户体验,但谁知道他们在进行什么勾当)……我并不否认“中aaa色”有相当的可取之处,但其中的某些畸形确实是影响这个行业进步的障碍。我痛恨某些厂商在这一过程中出于自身利益及其它不可公开的目的对用户进行的不良引导,这幅图描述了我的担忧。具体到现有的智能输入法软件,看看上面的多少条可以直接套用呢?笑来老师选择 Google 搜索而非百度搜索的原因不必多说,但谁又能保证这个号称“不做恶”的巨人不会入乡随俗?如果这样的大环境不改变,即使技术的进步使得无误的智能输入成为可能,这类涵盖了太多非功能因素的智能输入法也终将成为少数机构实现自身利益的工具。
  总之,中国人的计算机中“输入层”必不可少,它需要尽量屏蔽语言障碍,让中国人更加自然地使用计算机。但“输入层”决不能不受到社会责任和用户能力制约。

搜狗拼音与 Foxmail 引发的灵异邮件

2009/09/25 | 13:48 | 分类:Windows应用 | 标签: | 3,753次阅读

  当你发现你收到的多封邮件中,同一个人的名字都被“死”字代替,这是不是一件恐怖的灵异事件?这事就被我遇到了。不过经分析,这只是搜狗拼音输入法与 Foxmail 引发的一个小问题。

搜狗拼音与 Foxmail 引发的灵异邮件

  出问题的名字是“查老师”,“”在姓氏中读“zhā”。在搜狗拼音中,输入“zha”,“查”字的排名比较靠后;然而有一个与“查”字外形相似的“”字(注意下面是“且”而不是“旦”)却像李鬼一般地排在了“查”字之前(它做了 SEO 吧 :))。“査”是一个不常用的 GBK 汉字,但是发件人使用的 Foxmail 客户端生成的 MIME 消息中,标称的 charset 却写的是默认的 GB2312(严格地说也算 bug)。于是在我的客户端里,“査”字(96CB)没有被当作 GBK 正确解码,它的第二字节(CB)与“老”字(C0CF)的第一字节(C0)结合,恰好构成了“死”字(CBC0)。
  提醒使用拼音输入法的同学,不要再把“查”误输入为“査”。如果怕输错,可以直接用“cha”代替“zha”。而在邮件客户端方面,可以设置发出的邮件编码,用 GBK 或 UTF-8 取代 GB2312,以免少数非常用汉字导致接收方解析出错,造成对方收到“死”这种很不礼貌的灵异邮件。

浅议客观评价输入法的标准

2007/10/29 | 20:01 | 分类:IT杂谈 | 标签: | 3,364次阅读

  以搜狗拼音、谷歌拼音为代表的新一代基于互联网词库的、以句子为单位的拼音输入法一经推出,随即受到了广大网民欢迎,网上掀起新一轮更换输入法的热潮。与此同时,经典的五笔字型输入法也在推陈出新,以极点五笔为代表的输入法不断适应新的应用需求,在文秘办公与计算机专业领域发挥着重要的作用。

  针对输入法的评论早已不是什么新鲜话题。计算机在中国普遍应用以来,拼音和五笔的“斗争”就没有停息过。早在上世纪九十年代初,五笔字型的发明人王永民先生就发表了《拼音输入:汉字文化的掘墓机》一文,严辞批评拼音输入法;而网上广为流传的一篇署名为“猪八戒”的幽默文章《疯狂批判五笔字型》则用唇枪舌剑直指五笔。传统评价输入法的标准不外乎输入速度与上手的难易程度,这两个标准直接关系到用户使用计算机工作的效率,同时相对易于考察,因此得到了人们的普遍认同。大多数评论输入法的文章都是基于这两点展开讨论的,本文不再赘述。但要客观地评价或对比各类汉字输入法,还涉及很多其它因素,其立足点和标准有待商榷。文本简单讨论一些在评价输入法(特别是智能的拼音输入法与五笔字型)方面值得研究的问题,希望够能起到抛砖引玉的作用。

  一、区分汉字编码方案与汉字输入方法。汉字编码方案是指按照一定的规划,对不同的字或词给予相应的代码;而汉字输入方法是指运用某种编码方案,由操作者向计算机输入汉字的方法[1]。汉字编码方案通常具备重码率低、上下文相关度低、可相对独立地表示汉字等特点。区位码、电报码以及各类笔型编码是典型的汉字编码方案,全拼在一定程度上也可以认为是广义的汉字编码方案。而汉字输入方法则在汉字编码方案的基础上加以扩展,使用简化编码、上下文关联、模糊容错、频度分析等智能技术降低学习门槛,减少重码率,提高输入效率。传统的输入法直接接受汉字编码方案,而新一代输入法超越了汉字编码方案的限制。

  拼音本身的特性使得它容易利用上述几种技术简化和智能化,以句子为单位的拼音输入法成功的关键就在于智能技术的应用在输入方法与编码方案之间架设了一座自动化的桥梁。但智能技术的核心基于的是上下文分析,在不具备上下文环境的情况下对单字、单词的输入,智能技术难以发挥优势。五笔字型是输入法与编码方案高度耦合的典例,它重码率低,上下文无关,但汉字字型的特性又决定了五笔难以利用上述技术智能化。由于大多数输入工作是上下文相关的,这一点成为当前拼音输入法抨击五笔字型的主要论据。

  二、输入法的科学性问题。输入法要求高效还是科学?在辨明汉字编码方案与汉字输入方法的区别后我们可以看到:汉字编码方案的功能是为汉字提供人与计算机都能接受的表示方式,理应强调其规范性和科学性;而汉字输入方法更主要的是为简易高效地录入汉字而设计,其规范性和科学性就会打一定的折扣。以拼音为例,《汉语拼音方案》是经领域专家研究制订,国家法律确定,几十年应用验证的一套较为科学的字音编码方案,而多数拼音输入法的简码、模糊音输入是违反《汉语拼音方案》方案的,这作为提高输入法效率的一种措施,对汉字编码本身的科学性无太大不良影响。同样,如果将五笔字型更多地作为一种输入方法,而非纯粹的编码方案来看待,它对汉字的一些不合常规的拆分方式也是可以理解的。即使是汉字编码方案,本身也不可能是完美的。譬如要说五笔将“礻”上的一点抹去是不科学的,那么同样可以认为《汉语拼音方案》中“q”、“x”不符合国际发音也是不科学的——毕竟输入法不是汉字本身的规范,只是辅助的输入的手段,不必矫枉过正,将科学性强加为批判的把柄。

  三、输入法的运算量与人对机器的依赖性问题。以句子为单位的拼音输入法涉及大量人工智能算法,实现较为复杂,机器运算量大,一些高级功能甚至要依赖网络。而五笔字型这类与编码方案高度耦合的输入法在计算机算法实现上相对简单,一般仅需考虑优化存储与高效查表,因此运算速度快,机器要求低。智能的拼音输入法记录了用户大量的词库、词汇频度、使用习惯等信息,久而久之用户会有“越用越好用”的感觉。但在经过长期的人机相互适应过程后,用户往往会对特定机器上的特定输入法产生或多或少的依赖性,换用其它品牌的拼音输入法甚至为其它用户所磨合的同一输入法后就会有所不适。为解决用户习惯的迁移问题,谷歌拼音采用了网络存储的方案,但这又一次强化了用户对网络的依赖性。相比之下,用户对不同五笔字型输入法的依赖性要小一些,主要集中在词库和辅助功能(如便捷的造词方式、智能编码提示)方面。用户可以较快地适应不同机器上不同品牌的五笔字型输入法。

  简言之,这两种思路的核心区别在于输入法把运算量交给人脑还是电脑——在当今信息时代,让电脑替代人脑的冗繁劳动固然是大势所趋,但自动化永远是双刃剑,我们应防止自己被技术捆住手脚。如何权衡人脑和电脑工作,值得深思。

  四、软件的社会责任问题。计算机和软件在提高人们工作效率的同时也在影响着人们的日常习惯。由于长期使用基于拼音的汉字输入方法导致的“提笔忘字”现象已得到社会的关注。因拼音输入引起的网络文章错字成篇、网络语言使用别字成为时尚,确实对汉字文化及计算机初学者(特别是中小学生)有不利的影响。同时,一些五笔字型用户,特别是专业录入人员,往往形成了只会看稿打字的习惯;熟练的五笔用户在大脑中建立了字到键盘的映射之后也可能忽略汉字字型,同样产生“提笔忘字”现象。软件的社会责任问题深入之即是科学的道德问题,在当今社会以人为本的精神指导下,有必要作为考察输入法的标准之一。

  五、历史包袱问题。一些评论输入法的文章常常喜欢拿输入法的“历史问题”说事。例如批评五笔字型,常说它占了先入为主的便宜、利用政令和考试机制得以发展等;批评拼音,则以早期高重码、低效率的全拼为比照对象。任何事物都是不断发展和变化的,更何况日新月异的计算机技术。我们应以抛开历史包袱以及其它一些无关因素,客观且现时地评价不同输入法的长短优劣。

  总而言之,要对汉字输入法加以评论,客观和全面的标准是必不可少的。上述几点见解希望对读者有所启发。

 

参考文献:
[1] 潘德孚.论汉字字形编码方案的得与失[J].中文信息,1994,(02).

页面: 上页(较新) 1 2 下页(较旧)