转载(中文、日文、韩文编码问题)

原创 2007年09月28日 10:14:00
随着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的诸位,请务必提高警惕。

补充:并不是所有中日文里类似的汉字都像“直”字一样被编为同一个编码,例如“步”和“歩”就被分别编码了。但是这样的结果是,有的汉字被编为同一个编码,有的却没有,更加混乱了。 
 

相关文章推荐

常用字符集编码详解:ASCII 、GB2312、GBK、GB18030、UTF-8、unicode

ASCII ASCII码是7位编码,编码范围是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯数字和标点符号等字符。其中0x00-0x20和0x7F共33个控制字符。 只支持AS...

日语的文字编码

1、常用编码日语的文字编码主要是Shift_JIS、EUC-JP、ISO-2022-JP这三种。(1)Shift_JIS主要是Windows和Macintosh使用的文字编码。Shift_JIS的文字...

怎样区分中文汉字和日文汉字

随着GB2312时代的没落和中国官方强制推行的GB18030的消沉,所有人都觉得,无需置疑地Unicode一统天下的时代即将,甚至已经来临了。我也曾经是,现在仍旧是Unicode的推崇者。推崇的理由很...
  • wotiger
  • wotiger
  • 2007年10月12日 17:01
  • 3822

庖丁解牛分词器增加对日文,韩文分词的支持

项目中发现采用庖丁解牛分词器对含有日文的文字都被过滤掉,所以发了一封邮件给qieqie前辈。qieqie前辈的回复:在paoding中,中文、日文、韩文成为CJK,使用的是CJKKnife来切词; C...

【转载】如何用VB6在中文系统下把Unicode编码的日文字符转成Shift-JIS编码

这个题目有点变态,不过有时确实会有这种需求,起码我就碰到过。同样变态的需求还有“如何用VB6在日文系统下把Unicode编码的中文字符转成GB2312编码”。这种需求有个比较时髦的名字,叫做“国际对应...

JAVA中文字符编码问题详解 控制台输出【转载】

 转自:http://helloworlda.iteye.com/blog/1270703 JAVA的中文字符乱码问题一直很让人头疼。特别是在WEB应用中。网上的分析文章和解决方案都很...

unicode字符范围(包括中文、日语、韩文和各种特殊字符集)

在网上搜索了一下汉字的Unicode范围,普遍给出了“U+4E00..U+9FA5”。但事实上这个范围是不完整的,甚至连基本的全角(中文)标点也未包含在内。根据最新的Unicode 5.0版整理如下:...

思源黑体下载 - Google 联合 Adobe 发布免费开源优雅的设计字体 (简繁中文/日韩文)

今天 Google 和 Adobe 宣布合作推出一款免费、开源的字体——思源黑体,也叫做 Source Han Sans 或 Noto Sans CJK。整套字体设计优雅,显示效果优秀,值得收藏!...

vc本地编码程序在日文系统出现乱码无法使用的解决办法

     去年用vc给客户开发了一套基于pdf文档的数字图书馆,界面显示都是古汉语,要求支持unicode5.0标准,在页面上能显示7万多汉字,包括四字节汉字,终于在费了九牛二虎之力后在中文操作系统下...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:转载(中文、日文、韩文编码问题)
举报原因:
原因补充:

(最多只允许输入30个字)