从“?”字看开发组之用心

sanwsw

用笔画辅助法输出“㖞”，可发现有两个字形相同的“㖞”字，但两个字的Unicode内码不一样，分别是359E、E81F。检查两字属性，内码359E者字频为0，内码E81F字频为4860。这样处理后，输入wāi，内码为E81F字频为4860的在前，记事本文档保存含有该字时可以保存为默认的GB2312，也可再次正常浏览，否则就会出现问号。要想不出现乱码，保存时需要留心而保存为UTF-8或者UTF-16格式。由此足见开发组之用心。

[ 本帖最后由 sanwsw 于 2009-12-23 19:44 编辑 ]

ZXD4G

很惭愧的说，并非如楼主猜测的那般精致。

实际的原因在于字频统计的资料中用的是E8xx这个编码，而不是处于CJK Ext-A中的编码，目前含CJK Ext-A、B、C的资料还不够大量，所以隶属这些集合的字频无法统计，或者无法产生一个可信度有保障的统计结果，只好将字频设置为0了，即使有些不是0的，也是拍脑门给一个不大的数儿。

ZXD4G

类似顶楼提到的这个字儿(具有两个unicode编码的)，有80个之多，U+E815～U+E864的连续区间是一份，散落在CJK Ext-A的各处凑起来是另一份。长期来看，前者居于unicode的自定义区，严格来说是不大地道的，应该是一种临时性方案，终归还是要标准化的，不能总是自定义吧？
虽然99.xx%的人用不到这80个字，可一旦用上了，它们添的乱子却不小。敝公司有个同事的名字里用到了“”(U+E863和U+4DAE)，不同的开发环境对这个字的处理结果就不同，windows API转换结果为U+E863，跨平台的java实现转换结果是U+4DAE，如果将转换结果存储成GBK编码(无论是内存还是磁盘)，后者非GBK所能包容，必须是GB18030编码了(占用四个字节)。

另外，个人印象中好像windows API也在改变，大约是XP的sp3开始，GBK编码9FFE(“”字)转成unicode也是CJK Ext-A中的U+4DAE了，sp3之前，是转成U+E863的。
刚刚顺便求证了一下，又发现个变故，那个同事改名了——弃“”用“龑”。

本回复对于一般用户没有什么用处，比知道回字的四种写法也强不到哪里去，但对于咱的同行们，或许有点儿价值，我们在处理法律文书时为此付出过不短的时间才找到错误根源，此经验教训应供处理大量文字的程序员们参考。

kingdick

技术贴支持！

改名是必须的，跟赵C一个道理。

sanwsw

这个帖子和老左的回复，都不是讲紫光输入法支持Unicode是为了生僻姓名的输出。“此经验教训应供处理大量文字的程序员们参考”明白告示，楼上扯远了，应该静下心来体会开发组技术处理上平衡兼顾的难处。