[vimim] 双拼输入之小鹤方案
suxpert
http://www.google.com/support/forum/p/pinyin/thread?tid=40233c60b76e275e&hl=zh-CN
这是搜狗输入法的升级日志，其中“功能改进”的8即是支持小鹤：
http://pinyin.sogou.com/changelog.php
据以上信息看来小鹤方案的用户也不少，而且有增加的趋势，下面是小鹤官方介绍：
http://flypy.uueasy.com/read.php?tid=7
非官方介绍：
http://baike.baidu.com/view/2493246.html?fromTaglist
看来这个方案或许真的有不少优势。:)
感觉增加一种双拼方案对于VimIM而言应该不是很难的事，所以，——是否VimIM也支持小鹤双拼方案？
另：为了增加扩展性，双拼方案是否能像直观感受一样，通过给出键盘映射表的方式来表示某种方案，而不是直接在函数中进行表达，——因为如果在函数中表
达，那么这样的函数只能针对一种方案，对不同方案遍需要有不同的函数来实现，但实际上这些函数却是同一个目的。这样会不会有些浪费资源的嫌疑？
个人看法，请专家考虑。:)
--
VimIM —— Vim Input Method
http://vimim.googlecode.com/svn/vimim/vimim.html
Pan Shi Zhu
> 感觉增加一种双拼方案对于VimIM而言应该不是很难的事，所以，——是否VimIM也支持小鹤双拼方案？
>
> 另：为了增加扩展性，双拼方案是否能像直观感受一样，通过给出键盘映射表的方式来表示某种方案，而不是直接在函数中进行表达，——因为如果在函数中表
> 达，那么这样的函数只能针对一种方案，对不同方案遍需要有不同的函数来实现，但实际上这些函数却是同一个目的。这样会不会有些浪费资源的嫌疑？
>
> 个人看法，请专家考虑。:)
1。增加双拼方案对 vimim
来说不困难，只是增加一个函数即可。这些函数看起来是一样的，但实际上上级函数对于特殊情况已经进行了处理。开源的vimim欢迎每个人提交patch。
2。对于脚本语言而言，一个返回dict数据的函数跟一个dict数据本身的资源占用量是相同的。所以并不存在浪费资源的问题。
3。通常双拼并不能简单的表现为键盘映射表。我所知道的所有用键盘影射表方式实现双拼的输入法，在不同双拼方案支持方面都或多或少存在问题。
4。目前对于多双拼支持最好的其实是SCIM，但它却并不是用映射表来支持的，因为事实上映射表不能解决所有的特殊情况，而这会影响双拼用户的用户体验。
arcp...@gmail.com
2010/5/1 Pan Shi Zhu <pan.s...@gmail.com>:
Pan Shi Zhu
> 似乎只有小鹤拼音和自然码不能使用键盘映射达到百分百兼容，其他的都是基于键盘映射表的。
>
我常用的智能ABC双拼方案也不能使用键盘影射达到百分百兼容。
这也是我当初改造vimim双拼部分的原动力。
双拼的本质是韵母代表什么要由声母结合一起来决定，因此会存在相同的韵母，在声母不同时使用的韵母字符不同的情况。而这个情况就决定了必然不能使用声母韵母独立的映射表来实现。
使用组合映射表可以实现，但是要最终用户去输入组合映射表显然是不现实的。而且组合映射表显然是一种资源浪费。
我仍然认为函数实现的方式要优于映射表。
arcp...@gmail.com
我觉得使用映射是可以的，对于每个键，允许其对应一个声母以及多个韵母组合。
参考：http://code.google.com/p/ibus-sogoupycc/wiki/Configuration
原因是合法的拼音是有限的。
对于同时具有 iong 和 ong 的一个键(比如，s)，在和不同声母搭配的时候，会最多只用到 iong 和 ong 的一个，没有冲突。
2010/5/2 Pan Shi Zhu <pan.s...@gmail.com>:
Pan Shi Zhu
nv 对应 nv
nu 对应 nu
jv 对应 ju
ju 对应 ju
单一键盘映射的如何实现我说的形式？
2010/5/3 arcp...@gmail.com <arcp...@gmail.com>:
Pan Shi Zhu
> 我实现的是 ibus-sogoupycc 的双拼。
> 我觉得使用映射是可以的，对于每个键，允许其对应一个声母以及多个韵母组合。
要想让搜狗正确的识别，必须使用 nu, nv, ju, qu, yu, xu.
如果允许 v 键作为韵母映射到 u 那么 nu, nv 就会混淆。
如果不允许 v 键作为韵母映射到 u，那么 jv, qv, yv, xv 根本无法正确的实现智能ABC方案。
因此只使用独立键盘映射是不行的。
arcp...@gmail.com
同样的问题还出现在 ve 和 ue 上。
不过我觉得这更应该是一个和双拼没有关系的问题。
考虑韵母 ve 和 ue，实际上 ve 是见不到的。
那么倘若我把 ve 和 ue 都看成是合法的韵母拼音，并把 ve 映射到 ue 上就解决问题了。
解决你说的这个问题的做法是把 ju 和 jv 都看成是合法的拼音，并把 jv 映射到 ju ……
2010/5/3 Pan Shi Zhu <pan.s...@gmail.com>:
Pan Shi Zhu
> 解决你说的这个问题的做法是把 ju 和 jv 都看成是合法的拼音，并把 jv 映射到 ju ……
这有两个问题：
1。把 jv 映射到 ju ，这即不是一个“键到声母”的映射，也不是一个“键到韵母”的映射，而是一个“双拼到全拼”的映射。
2。这个映射不能设置为全局的，否则会出问题，因为在微软拼音中 jv 代表的是 jue，而不是 ju。也就是说，不同的双拼方案对 jv
的解释是不同的，不能一概的把所有 jv 都认为是 jv 的合法表示形式。
也就是说：有的双拼方案在 jve 和 jue 两者会有两种输入方式，尤其表现为 jv 对应 jue，有的双拼方案在 jv 和 ju
两者会有两种输入方式，表现为 jv 对应 ju。这个特性必须是做到双拼方案中，而不是双拼的全局设置。那么在单个双拼的键盘映射表中无法体现。
arcp...@gmail.com
我说的 jv 认为是合法的拼音是在全拼层面的，双拼的两个键组合起来可能有多种结果，采用哪一个则是看哪一个组合是合法的全拼，一般只有一个。jv
当作 ju 来看待也是在全拼层面的，和双拼布局没有关系，在全拼层面实现这个东西之后就可以依然使用对单个键的映射来表示双拼方案来处理之前提到的智能ABC的情况了～
2010/5/4 Pan Shi Zhu <pan.s...@gmail.com>:
suxpert
虽然说拼音反查对于双拼转全拼而言是相对而言消耗时间，减慢反应速度与增加消耗的“好”方法，但正如我所不喜欢的递归也正好能做到减少程序员脑细胞死亡
率、加快开发进度这种效果一样，反查也有这种不用深入了解机理却也敢“发明车轮”的草根效果。:)
对于给定的键盘映射表，任何拼音可以唯一转换成一个双拼的字串，于是我们就生成了一个拼音转双拼的表（恩，自动生成，我们就不用管了），有了这个表之
后，双拼再转回全拼是不是也就实现了？
其关键在于自动生成，而这个生成规则如果依赖于不同的双拼实现方案，那么这一招貌似会失效（小鹤？？）。
然而，即使因为不同双拼实现方案的生成规则不同而无法统一，我们仍然提供了用户自己修改键盘映射的Freedom，不是吗？
Pan Shi Zhu
> 对于给定的键盘映射表，任何拼音可以唯一转换成一个双拼的字串，于是我们就生成了一个拼音转双拼的表（恩，自动生成，我们就不用管了），有了这个表之
> 后，双拼再转回全拼是不是也就实现了？
因为双拼的输入方法不是唯一的，所以无法唯一的把一个全拼转换成双拼。虽然通常可以唯一的把一个双拼转换成全拼。但是双拼转换成全拼的算法依赖于个别双拼方案的处理，主要处理的就是歧义情况究竟选择哪个全拼。
微软拼音可以用 jv 和 jm 输入相同的字，而智能ABC可以用 jv 和 ju 输入相同的字，这是一个全拼有两种双拼方案的典型例子。
关于 nv 和 nve 的歧义，最初所有双拼方案的设计者都知道，他们一致认为应当取 nv。但是关于 jv 这样的词，应当取 ju 还是
jue ，各种双拼方案设计者就存在了不同意见。于是一个理想的双拼算法就必须对这个问题作出特殊处理。
Pan Shi Zhu
例如：微软拼音输入 jv 应当出现 jue，之所以可以这样支持，因为 jv 不是合法的全拼。
在除了智能ABC以外的多数双拼方案中，v 都能映射三个韵母：v, ui, ve。而且，我咨询过微软拼音用户，其答复是，nv 应当作 nv
解， jv,qv,xv,yv应当做ve解。
如果 jv 是合法全拼，那么就会出现歧义，因为 jv 究竟解析为 jv 还是 jue 无法确定。但是这个歧义一开始就存在了，因为 nv 和
nve 的歧义同样存在。如果规定凡是 v 和 ve 出现歧义时一概取 v
，这是一种方案，但是这个方案又与标准的微软拼音用户体验不同。因为他们认定 jv 一定要是取 jue
我们知道双拼存在的前提是每个双拼可以唯一转换为一个合法全拼。出现歧义肯定是要解决的，然而这个解决方案却在每个双拼方案中都不同。
2010/5/4 arcp...@gmail.com <arcp...@gmail.com>:
arcp...@gmail.com
Pan Shi Zhu
Quark
to ibus-user
show details 11/11/09
你说的这种情况，ibus的处理是正确的，没有任何问题（我用双拼十年多了 -.-）。
按照微软拼音的双拼布局（ibus默认采用），韵母表上，v键只有ui和ue，没有v，y键是v（用v代表Ü，下同，没有省略两点）和uai，u键是
u
而jv的时候是省略两点的u，所以应该是ju，用j + u输入。
即使在韵母表上v键有v，ju也应该是用j + u输入，因为要省略两点
在输入lv（绿）的时候，两点不能省略，这时候按照微软拼音的双拼布局，使用l + y输入，按照UCDOS双拼布局，使用l + v输入。
输入lue（略）的时候，微软拼音的双拼布局，使用l + v或者 l + t输入，按照UCDOS双拼布局，只能使用l + t输入。
- Show quoted text -
On Nov 11, 11:14 am, pansz <pan.shi...@gmail.com> wrote:
> ibus 在处理 jv 这个拼音时非常奇怪，输入 jv 实际输出的是 jue ，这个从双拼输入的角度来看完全是不可思议的。因为输出了一个不相
> 干的拼音，希望能够修正此问题。
>
> 背景：
>
> jv, qv, xv, 这几个拼音，在书写上，可以把两点去掉，写成 u 。虽然后面这个韵母本来应当是 v
>
> 作为双拼的输入法来说，一般应当同时接受 jv 和 ju 两种拼写方式。智能ABC和SCIM的双拼就是如此处理的，使用上很方便。
>
> fcitx 和微软拼音的处理是完全不接受 jv 这种输入，直接报错，这样虽然不方便，但至少不容易出错。而 ibus 接受这种形式的输入却输入一
> 个错误的拼音，这很不合适。
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "ibus-user" group.
iBus project web page: http://code.google.com/p/ibus/
iBus project group: http://groups.google.com/group/ibus-user?hl=en
-~----------~----~----~----~------~----~------~--~---
Reply
Forward
Invite Quark to chat
Reply
|
Quark
补充一下：虽然j + t可以用来输入jue，但是按照微软拼音的双拼布局，j + v也可以，所以不应该报错，没有问题。
11/11/09
QuarkLoading...
11/11/09
Quark
to ibus-user
show details 11/11/09
补充一下：虽然j + t可以用来输入jue，但是按照微软拼音的双拼布局，j + v也可以，所以不应该报错，没有问题。
2010/5/4 arcp...@gmail.com <arcp...@gmail.com>:
> 确实是可以有歧义，但是可以有优先选择的顺序，比如在 MSPY 中，先考虑 v 作为 ue 的合法性，这样就好了 :)
>
arcp...@gmail.com
2010/5/4 Pan Shi Zhu <pan.s...@gmail.com>:
arcp...@gmail.com
，或者是分号，也允许是逗号点号等其他符号，虽然现在没有这样的双拼布局)，指定提供一个映射，该映射有两部分组成，第一部分是一个声母(可能是零声母)，第二部分是韵母表(是有顺序的一个字符串数组)。
至于我随便输入的两个键会产生什么样的全拼串，是由程序决定的，程序会取第一个键的声母，然后从头到尾有顺序地和第二个键的韵母表中的韵母组合，判断是否是合法全拼串，如果是，那么
ok，就是这个结果。
这样做至少可以非常好地处理MSPY，UCDOS双拼方案。
比如 MSPY 方案，对于 v 键，是这样配置的： （refer to
http://code.google.com/p/ibus-sogoupycc/wiki/Configuration）
v = {"zh", {"ui", "ue"}}
也就是说 v 键是不能输入韵母 v 的。
按下 jv 的时候，按照程序的逻辑，会先检查 jui，发现 jui 不是合法全拼串，放弃，再试 jue，发现这个是合法的，那么 jv 就是 "jue" 了。
对于你提到的智能 ABC 使用 jv 输入 "ju" 的问题，我之前说的解决方法是在判断全拼串合法性的程序里把 "jv" 判成合法，这样使用
v = {"sh", {"v", "ue"}} 的配置就可以用 jv 输入 "ju" 了。
我一直反对一个合法的全拼有两种或更多种双拼输入方法，双拼到全拼应该是一一映射。从这个意义上来说，我觉得智能 ABC 方案中 jv 和 ju
都可以是 "ju" 本身就不合理，MSPY 中也有一处这样的不合理，UCDOS 方案是合理的一一映射。所以在智能ABC "ju" 和
"jv" 上较真也不太有意义，因为你可以始终使用 ju 来输入 "ju"。
保持这种设计的原因是我认为这样的设计是简单而规范的，只需要为每个键指定一个声母和韵母列表，然后程序就能自动算出两个键会组合出什么样的全拼。
这种设计不能很好处理的自然码零声母时双打韵母的情况，然而我个人比较偏执地认为自然码并不能算做是标准的双拼，所以并没有为双打的情况提供额外的支持，用户需要在每个韵母按键的声母处填上零声母来兼容这些方案。
2010/5/4 Pan Shi Zhu <pan.s...@gmail.com>:
Pan Shi Zhu
从双拼方案设计的角度来讲，这归究于不同的流派。有的双拼流派认为双拼是基于拼音发音方式而创作，而有的双拼流派认为必须基于全拼的书写方法而创作。当你闭眼的时候，你想到的发音是
v ，因此即便全拼的书写方法为 u ，但是在双拼中仍然用 v 来表示。——我固执的认为在双拼中使用 ju 来代表 ju
是错误的。因为双拼表的是拼音的“音“，而不是全拼的”形“。
另外，ibus-pinyin 的这个问题你有没有什么好的建议呢？
2010/5/5 arcp...@gmail.com <arcp...@gmail.com>:
Pan Shi Zhu
> 这种设计不能很好处理的自然码零声母时双打韵母的情况，然而我个人比较偏执地认为自然码并不能算做是标准的双拼，所以并没有为双打的情况提供额外的支持，用户需要在每个韵母按键的声母处填上零声母来兼容这些方案。
vimim 实现双拼并不比任何其他输入法复杂，但是如果要让我支持自然码零声母双打韵母只需要增加一行代码。我认为这就是设计架构带来的特点，事实上双拼的设计者完全可以做到针对这些情况进行支持。从而给予更好的用户体验。
arcp...@gmail.com
的 jv 没有比较好地支持，如果你需要这个功能的话，再交一个 Issue 比较好。
不知道你有没有对“标准”的一些固执，就是觉得某些东西是“标准”的，如果不标准，我就不去实现，尽管它的用户可能有一些或者有很多。或者说，我实现的东西是比较合理的，为了特意支持某个功能就有一些不太整齐了。
比如 IE 浏览器的 vbscript，就没有其他的浏览器去实现。
HTML5 Canvas 中的阴影，在经过放缩变换之后， Chrome 和 Firefox 对它的尺寸也有不同理解。
我第一个看到的有详细帮助文档的双拼是 UCDOS
的“智能双拼”，从而觉得那是一种比较理想的情况。一一映射并且没有用到多余的分号，从而觉得所有用到分号或者是不是一一映射的双拼方案都是不好的，不愿意去特意实现这些方案。
2010/5/5 Pan Shi Zhu <pan.s...@gmail.com>:
Pan Shi Zhu
>
> 不知道你有没有对“标准”的一些固执，就是觉得某些东西是“标准”的，如果不标准，我就不去实现，尽管它的用户可能有一些或者有很多。或者说，我实现的东西是比较合理的，为了特意支持某个功能就有一些不太整齐了。
>
这种固执，每个coder都会存在，但是具体针对每个问题的时候，就会有不同的看法。
phuang 就认为对智能ABC jv
的支持不舒服，于是不愿意支持。但是这里更多的不是对标准的固执，而是对设计的妥协，因为他当初设计双拼的时候对情况有很多假定，所以在不改动架构的情况下无法很漂亮的支持某个功能。
arcp...@gmail.com
DoublePinyinScheme::buildMap()
http://code.google.com/p/ibus-sogoupycc/source/browse/trunk/linux/src/DoublePinyinScheme.cpp#91
根据已有的单键映射和全拼合法性表自动建立双键映射。
为了达到完全一样的支持双打也好，jv 的问题也好。
我可以加上允许用户传入一个双键映射表，自动生成双键映射之后再读取用户提供的表做一些小修改。这并不麻烦，而它让我觉得不舒服，虽然说双拼没有一个像
ISO 之类的标准可查，但我还是认为一一映射才是好的。
我相信 ibus-pinyin 想支持你说的 jv 这个也是很容易办到的。
对于这个问题没有必要再较真下去了，"jv" 输入 "ju" 的应该被 "deprecated"，全部改用使用 "ju" 输入 "ju”
，就像 "<br>" 最好改成 "<br/>" 一样。
100%模仿已经几乎要退出历史舞台的智能ABC输入法有什么好处呢？要支持一些老旧的又不太合理的东西真是很难受的感觉啊。在这一点上，xterm
的代码也说明了问题。
2010/5/6 Pan Shi Zhu <pan.s...@gmail.com>:
Pan Shi Zhu
> 那我觉得这不是设计的妥协。比如说我的设计，目前是通过
>
> 对于这个问题没有必要再较真下去了，"jv" 输入 "ju" 的应该被 "deprecated"，全部改用使用 "ju" 输入 "ju”
我理解双拼不应当使用 ju 而应当使用 jv ，因为 ju 的使用是书写上的，而双拼是基于发音的。所以，是 ju 输入 ju 应该被
deprecated，而不是 jv 输入 ju 应该被 deprecated。
即便不讨论谁更加标准，照顾用户的使用偏好是一个很基本合理的需求，如果一个厨师，炒了一盘大蒜炒白菜，然后有个人说自己不喜吃蒜，希望厨师不加大蒜炒这盘青菜，厨师回答：象你们这种不吃蒜的人应该被deprecated。。。
其实在自由软件开发中没必要那么狭隘，本身中国人用自由软件的就不多，如果还对用户一个正常的很容易实现的需求觉得不愿意去做，不是一个黑客之道。
vimim
读完所有关于“双拼输入之小鹤方案”的讨论，也来凑个热闹，捧捧场。
所谓标准，其实没有对错之分。如果没有权威规定，那么，用的人多就是
标准。Vim的用户最牛，因为Vim用户可以给自己定制自己的标准。
具体到双拼ju/jv之别，我们的VimIM设计原则应该是全部支持。挑一个
缺省的，然后设置一个选项。这是我们的优势，也是我们牛皮的地方。
还有，“双拼输入之小鹤方案”能不能直接装上？比如说加多几个
函数？发挥我们的优良传统，好歹先上字再说。
想当年，笔者对双拼一窍不通，用最野蛮的操作，写出VimIM五种双拼方
案，居然可以打出经典测试“我有一个梦”。当然，最骄傲的结果是成功
的抛砖引玉，诞生出“史上第一支持五种双拼的云输入法”。
wo.you.yige.meng<C-6>
arcp...@gmail.com
大部分人可能都是这么想的吧，许多新版本的成需对旧版本的程序有不兼容的情况，比如python, lua, 微软的操作系统和 IE 浏览器。
要进步必须要打破陈规，所以牺牲一些兼容性是合理的。
双拼正是处于一种没有标准的混乱状况，即便是用智能ABC双拼的人，也应该不都是都用 jv 来输入
"ju"。基于发音的说法，它是一种说法和基于书写的说法都只是说法，互相不能说服对方。
在这里讨论这个事情之前，我并不知道ABC双拼布局在这一细节上的区别，没有其他人提到这一点。作为程序员可能都是想要尽可能地使用自己设定的框架，对一些自己觉得不合理的东西是不愿意接受的，所以我先前也是习惯式地抗拒的。
不过我已经妥协了无数次了，就比如 Enter 键的行为，所以估计在未来的某一个版本，应该可以完整支持这些双拼布局。
妥协看起来也是很普遍的行为，ibus 1.3 的时候对 focus 检查比较严格，而导致了在 tilda 或者其他的一些不标准的 WM
下程序会随机发生不能输入的情况。这个问题比较讨厌了，虽然责任不在 ibus，在 Window Managers，但大多数 WM
都有这样的问题。所以最终在 ibus 1.3.2 的时候，ibus 做出了妥协，退到了不太严格检查 focus 的做法。
2010/5/7 Pan Shi Zhu <pan.s...@gmail.com>:
> 2010/5/7 arcp...@gmail.com <arcp...@gmail.com>:
>> 那我觉得这不是设计的妥协。比如说我的设计，目前是通过
>>
>> 对于这个问题没有必要再较真下去了，"jv" 输入 "ju" 的应该被 "deprecated"，全部改用使用 "ju" 输入 "ju"
>
> 我理解双拼不应当使用 ju 而应当使用 jv ，因为 ju 的使用是书写上的，而双拼是基于发音的。所以，是 ju 输入 ju 应该被
> deprecated，而不是 jv 输入 ju 应该被 deprecated。
>
> 即便不讨论谁更加标准，照顾用户的使用偏好是一个很基本合理的需求，如果一个厨师，炒了一盘大蒜炒白菜，然后有个人说自己不喜吃蒜，希望厨师不加大蒜炒这盘青菜，厨师回答：象你们这种不吃蒜的人应该被deprecated。。。
>
> 其实在自由软件开发中没必要那么狭隘，本身中国人用自由软件的就不多，如果还对用户一个正常的很容易实现的需求觉得不愿意去做，不是一个黑客之道。
>
> --
> VimIM ---- Vim Input Method
> http://vimim.googlecode.com/svn/vimim/vimim.html
>
--
VimIM —— Vim Input Method
http://vim.sourceforge.net/scripts/script.php?script_id=2506
suxpert
VimIM兄的這一覺睡的夠長的~~:)
對于“學術”這個詞我一直沒什麽好感，或許是受國內“學術界”各種醜惡現象影響，我還是覺得應該放下架子，貼近大眾，只有人民的才是有價值的~:)
額，跑題了，本人依然是“非專業人士”，從用戶的角度看問題比較多，沒本事提出個建設性的意見，權當在湊熱鬧。──并同VimIM兄一道，期待下“史上
第一支持六中雙拼的雲輸入法”。^_^
--
VimIM —— Vim Input Method
http://vim.sourceforge.net/scripts/script.php?script_id=2506
Pan Shi Zhu
> 双拼正是处于一种没有标准的混乱状况，即便是用智能ABC双拼的人，也应该不都是都用 jv 来输入
> "ju"。基于发音的说法，它是一种说法和基于书写的说法都只是说法，互相不能说服对方。
>
> 在这里讨论这个事情之前，我并不知道ABC双拼布局在这一细节上的区别，没有其他人提到这一点。作为程序员可能都是想要尽可能地使用自己设定的框架，对一些自己觉得不合理的东西是不愿意接受的，所以我先前也是习惯式地抗拒的。
正因为输入法设计者，可能并不知道这个细节上的差别，所以我们才耐心的讨论这个问题。理总是越辩越明的，既然互相都不能说服对方，那么我愿意选择两种做法都支持。虽然那确实会给我的代码造成一点点的特例。
这就如同KDE3.5，虽然它的代码看起来远远不如KDE4，因为为了不同人的需求打了太多的补丁，但是KDE3.5用起来至今为止仍然是最贴心的桌面，无可替代。在这个教训中我发现，追求用户体验的极致比追求代码结构优雅方面的极致更加重要。
当我们关注双拼的时候，可能只会发现，冲突仅仅存在于不同的双拼方案。
不过如果你关注全拼，会发现看起来统一的全拼中都存在着太多太多的分歧，模糊音的存在当然是一种，但是关于断字的方案，不同的输入法都大有不同。举两个例子：
guangou 究竟作 guang'ou 解还是 guan'gou 解？
nenou 作 ne'nou 解还是 nen'ou （嫩藕）解？ piao 作 piao 还是 作 pi'ao 解？
分歧是永远存在的，其实即使全拼断字，也没有一个防止四海而皆准的方案。
Pan Shi Zhu
> 并同VimIM兄一道，期待下“史上
> 第一支持六中雙拼的雲輸入法”。^_^
>
楼主提出的帖子中并没有给出小鹤方案的具体细节，如果能够找到相关细节，增加一个支持很容易。
suxpert
正如第一帖给出的一样，细节的实现在其官方与非官方链接中都有描述，因此我没有详细说明。如果发帖时没有顺便给出这些东西，显然就算是文不对题。或许专
家们只注意到了我第一帖中后面的“键盘映射”的提议，于是看上去这一系列讨论基本上就跟小鹤的关系不大。不过在我而言，只是顺便想起，才顺便写出来
的。
当然，由这么一个比较小的问题引发激烈的讨论，这一“导火索”对VimIM的贡献不可谓不大，即使没有去实现什么，至少思想交流与对问题认识的深度等都
随之得到加强。:)
额，说的好别扭……所谓官样文章，果然不是正常人说的，我还是继续我的大众化路线吧~~:D
Pan Shi Zhu
看了看这个，发现好像没有 'er' 的键盘映射？
http://baike.baidu.com/image/29752a9b39d45d90c8eaf431
懂小鹤的出来说说？
2010/5/10 suxpert <sux...@gmail.com>:
--
VimIM —— Vim 中文輸入法
http://vim.sourceforge.net/scripts/script.php?script_id=2506
arcp...@gmail.com
可以参考这篇文章：
http://yongsun.me/2010/04/sunpinyin-2-0%e6%a8%a1%e7%b3%8a%e9%9f%b3%e8%8a%82%e5%88%87%e5%88%86%e7%9a%84%e5%ae%9e%e7%8e%b0/
作者 findsun 是 sunpinyin 现在的主要维护者，他虽然对双拼不是特别熟悉，但对输入法应该是什么样的应该是比较有感悟了。他也是
ibus 最初的开发者之一。
2010/5/10 Pan Shi Zhu <pan.s...@gmail.com>:
Pan Shi Zhu
> 关于全拼的断字，虽然没有最好的办法，但还是有办法的 :)
> 可以参考这篇文章：
> http://yongsun.me/2010/04/sunpinyin-2-0%e6%a8%a1%e7%b3%8a%e9%9f%b3%e8%8a%82%e5%88%87%e5%88%86%e7%9a%84%e5%ae%9e%e7%8e%b0/
>
我不是说没办法，是说没有统一的办法。
目前的方法自然是各种拼音输入法都对可能的情形作出自己的假定。于是输入同样一个全拼在不同输入法中得到的结果可能是不同的。
例如 xiana 可为 xian'a, xi'a'na, xi'an'a, xia'na,
等等。。。那么如果希望制作出无须查词库的算法，必然只有根据贪婪／最小，或者根据经验公式。如果查词库，可能会效率低一点，但最后还是等效为使用经验公式，除非要同时显示出多种候选。
应该说，从这个环节来看，双拼要比全拼简单得多，少了拆分音节的算法，双拼的效率也应该高很多。双拼只是通常可能需要不但处理声母到声母和韵母到韵母的映射，还需要处理双拼作为一个整体到全拼的映射而已。
例如小鹤的 er -> er， ah->ang
，这样的映射我想用传统的声母映射表加韵母映射表是无法实现的，我的想法是先生成双拼整体->全拼整体 的映射表，然后把整体映射表上增加
er->er, ah->ang 这样的映射就很容易实现小鹤的这个功能了。而如果实现了小鹤，那实现智能ABC的 jv->ju
也就无困难了。顺便说一下，不光智能ABC，自然码也要求同时支持 jv->ju 和
ju->ju，更进一步说，我查了vimim的5种双拼方案，只有微软拼音这一种输入法是不要求 jv->ju的。其他四种，都要求。
vimim
> 期待下“史上第一支持六中雙拼的雲輸入法”。^_^
美梦成真!