随着GB2312时代的没落和中国官方强制推行的GB18030的消沉，所有人都觉得，无需置疑地Unicode一统天下的时代即将，甚至已经来临了。
我也曾经是，现在仍旧是Unicode的推崇者。
推崇的理由很简单——在GB2312，ASCII的时代，一个程序、一个网页当中多种语言（除了英语之外的）无法并存。GB2312编码的文章，在BIG5下就是乱码；反之亦然。一篇文章中同时含有中文和日文，或者中文和法文的事情，更是难以做到。在程序中，编码的不一致就更可怕。你用一个函数传递过去一句问候，可是对方却用了错误的编码来解析你这句问候，结果就是一堆乱码。这给开发带来了很大的不便。
那么，Unicode，在我眼里理所应当要解决这些问题的。在Unicode里面，所有语言的编码互不冲突，因此在同一篇文章里可以同时显示所有语言——于是，我也毫不犹豫地在Windows编程中放弃了A结尾的API，全部使用W结尾的API；在网页上编码全都设置为UTF-8……
可是，事情真的是那样吗？直到最近，我才明白我想的太天真了。
仔细看看上面的两个“直”字，就会发现它们的不同——左边是中文中的直，右边则是日文中的直。类似的汉字还有“才”“具”“画”“角”“骨”等等。
在Unicode制定过程中，像上面这样不同国家的同一个汉字（写法上稍有区别）是否应当编码为同一个字时， 引起了很大的争议。争议的最终结果，是上面两个字被赋予同一个编码。就这样，中文、日文、韩文中的所有汉字都被搜集整理到一起，填充到Unicode编码的0×4E00到0×9FFF的庞大block当中。这些字按照字形排列，不再区分哪个是中文字符，那个是日文字符，哪个是韩文字符，统一叫做“CJK Unified Ideographs”。
这样做的问题就是，一个字符本身不具有了语言的属性，它到底是中文还是日文，取决于显示它的字体。例如上面的“直”字，如果我们用中文字体（例如SimSun, SimHei）显示它，就会得到图中左边的字，如果用日文字体显示它（如MS Gothic），就会得到右边日文的直。
这样做会导致什么问题呢？
1，无法利用文字的编码来区分其属于哪种语言的文字。
Unicode当中的其他语言——例如阿拉伯语，都有其固定的编码范围，例如阿拉伯语是0×0600到0×06FF。这样一个字符处理软件在处理到一个0×0600到0×06FF区间的字符时，它就知道现在在处理的是阿拉伯文。可是汉字呢？中日韩的汉字被无规律地混杂在同一个区间中，是哪国文字以无法辨认。
2，一种字体无法同时表示中文、日文和韩文
由于文字是利用字体显示来表明它自己是哪国文字的，那么一种字体将无法同时表示中文和日文。试想，你在创造一种字体；当你遇到“直”这个汉字时，你要么选择中文写法，要么选择日文写法，两者不可兼得。
这会带来什么后果呢？轻一点的后果，是中日文混用写成的文章中必须设置至少2种字体才能准确表达，因而在一些不支持混用字体的编辑器——例如Windows的记事本当中要么中文字符变成了日语，要么日语字符变成了中文。在日文Windows下浏览UTF-8中文网页的朋友，也发现那些中文字符都变成日文字符了吧（比如“骨”里面的横折跑到了右面）？试想这样“错字”连篇的中文能用在正式场合吗？
严重一些的后果是什么呢？ 严重的后果就是，目前很多软件，尤其是西方欧美的字处理软件都在试图用同一种字体满足所有语言的需要。例如“Arial Unicode MS”字体，就是一种非常常用的Unicode字体。很显然，在事实上这样的字体在规定“直”字之类汉字的字模时也必须选择中文写法还是日文写法。
结果不过说也知道——也许是日本在IT界的影响力高于中国，也许是什么原因，似乎Arial Unicode MS之类的字体中凡是中日写法不同的字体，全都是日文写法。
换句话说，一个使用Arial Unicode MS的老外，即便他在用中文写一篇文章，即便他用的输入法是中文拼音，最后打出来的字符却全都是日文汉字。 他如果是个在学习中文的人，他学到的将是这些日文汉字。更甚之，如果将来这些所谓的“标准Unicode字体”一统天下，宋体、黑体没落的时候，中国人的电脑中的中国汉字也会不知不觉地被日本汉字取代，用电脑学习的小孩子们也会把电脑上出现的日本汉字当作汉字的正确写法。
许多人也许会想：一定要和日本竞争，争取让标准的Unicode字体里的汉字使用中文汉字——现在不是争不争的问题，问题是，既然中文日文中的“直”不是完全相同的汉字，为什么不在制定其编码阶段就把它们分开呢？
我不知道Unicode是否制定了完全把中日韩三种语言孤立开的版本；我只知道目前最流行的Unicode是像上面这样的。 使用Unicode的诸位，请务必提高警惕。
补充：并不是所有中日文里类似的汉字都像“直”字一样被编为同一个编码，例如“步”和“歩”就被分别编码了。但是这样的结果是，有的汉字被编为同一个编码，有的却没有，更加混乱了。
我也曾经是，现在仍旧是Unicode的推崇者。
推崇的理由很简单——在GB2312，ASCII的时代，一个程序、一个网页当中多种语言（除了英语之外的）无法并存。GB2312编码的文章，在BIG5下就是乱码；反之亦然。一篇文章中同时含有中文和日文，或者中文和法文的事情，更是难以做到。在程序中，编码的不一致就更可怕。你用一个函数传递过去一句问候，可是对方却用了错误的编码来解析你这句问候，结果就是一堆乱码。这给开发带来了很大的不便。
那么，Unicode，在我眼里理所应当要解决这些问题的。在Unicode里面，所有语言的编码互不冲突，因此在同一篇文章里可以同时显示所有语言——于是，我也毫不犹豫地在Windows编程中放弃了A结尾的API，全部使用W结尾的API；在网页上编码全都设置为UTF-8……
可是，事情真的是那样吗？直到最近，我才明白我想的太天真了。
仔细看看上面的两个“直”字，就会发现它们的不同——左边是中文中的直，右边则是日文中的直。类似的汉字还有“才”“具”“画”“角”“骨”等等。
在Unicode制定过程中，像上面这样不同国家的同一个汉字（写法上稍有区别）是否应当编码为同一个字时， 引起了很大的争议。争议的最终结果，是上面两个字被赋予同一个编码。就这样，中文、日文、韩文中的所有汉字都被搜集整理到一起，填充到Unicode编码的0×4E00到0×9FFF的庞大block当中。这些字按照字形排列，不再区分哪个是中文字符，那个是日文字符，哪个是韩文字符，统一叫做“CJK Unified Ideographs”。
这样做的问题就是，一个字符本身不具有了语言的属性，它到底是中文还是日文，取决于显示它的字体。例如上面的“直”字，如果我们用中文字体（例如SimSun, SimHei）显示它，就会得到图中左边的字，如果用日文字体显示它（如MS Gothic），就会得到右边日文的直。
这样做会导致什么问题呢？
1，无法利用文字的编码来区分其属于哪种语言的文字。
Unicode当中的其他语言——例如阿拉伯语，都有其固定的编码范围，例如阿拉伯语是0×0600到0×06FF。这样一个字符处理软件在处理到一个0×0600到0×06FF区间的字符时，它就知道现在在处理的是阿拉伯文。可是汉字呢？中日韩的汉字被无规律地混杂在同一个区间中，是哪国文字以无法辨认。
2，一种字体无法同时表示中文、日文和韩文
由于文字是利用字体显示来表明它自己是哪国文字的，那么一种字体将无法同时表示中文和日文。试想，你在创造一种字体；当你遇到“直”这个汉字时，你要么选择中文写法，要么选择日文写法，两者不可兼得。
这会带来什么后果呢？轻一点的后果，是中日文混用写成的文章中必须设置至少2种字体才能准确表达，因而在一些不支持混用字体的编辑器——例如Windows的记事本当中要么中文字符变成了日语，要么日语字符变成了中文。在日文Windows下浏览UTF-8中文网页的朋友，也发现那些中文字符都变成日文字符了吧（比如“骨”里面的横折跑到了右面）？试想这样“错字”连篇的中文能用在正式场合吗？
严重一些的后果是什么呢？ 严重的后果就是，目前很多软件，尤其是西方欧美的字处理软件都在试图用同一种字体满足所有语言的需要。例如“Arial Unicode MS”字体，就是一种非常常用的Unicode字体。很显然，在事实上这样的字体在规定“直”字之类汉字的字模时也必须选择中文写法还是日文写法。
结果不过说也知道——也许是日本在IT界的影响力高于中国，也许是什么原因，似乎Arial Unicode MS之类的字体中凡是中日写法不同的字体，全都是日文写法。
换句话说，一个使用Arial Unicode MS的老外，即便他在用中文写一篇文章，即便他用的输入法是中文拼音，最后打出来的字符却全都是日文汉字。 他如果是个在学习中文的人，他学到的将是这些日文汉字。更甚之，如果将来这些所谓的“标准Unicode字体”一统天下，宋体、黑体没落的时候，中国人的电脑中的中国汉字也会不知不觉地被日本汉字取代，用电脑学习的小孩子们也会把电脑上出现的日本汉字当作汉字的正确写法。
许多人也许会想：一定要和日本竞争，争取让标准的Unicode字体里的汉字使用中文汉字——现在不是争不争的问题，问题是，既然中文日文中的“直”不是完全相同的汉字，为什么不在制定其编码阶段就把它们分开呢？
我不知道Unicode是否制定了完全把中日韩三种语言孤立开的版本；我只知道目前最流行的Unicode是像上面这样的。 使用Unicode的诸位，请务必提高警惕。
补充：并不是所有中日文里类似的汉字都像“直”字一样被编为同一个编码，例如“步”和“歩”就被分别编码了。但是这样的结果是，有的汉字被编为同一个编码，有的却没有，更加混乱了。
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
