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

转载 2007年10月12日 17:01: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的诸位,请务必提高警惕。

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

判断日文的正则表达式

[一-龠]+|[ぁ-ん]+|[ァ-ヴー]+  PHP中GBK和UTF8编码处理一、编码范围1. GBK (GB2312/GB18030)/x00-/xff  GBK双字节编码范围/x20-/x7f  ...
  • ninjya_luck
  • ninjya_luck
  • 2008年04月11日 16:27
  • 11300

日文汉字读音规律

日文中的汉字大抵与中文的汉字意义相同,以下兹列举不同或特殊者: ①日本自创汉字:   畑(はたけ):田地   枠(わく):框子   峠(とうげ):山顶   这些汉字由於是日本自创,华人很难了解其意. ...
  • tlaff
  • tlaff
  • 2015年04月03日 17:44
  • 1110

怎么识别图片中的日文

如果您喜欢某本纸质书籍或某篇文章,那么,只要用数码相机、手机或扫描仪将它拍下来,上传到电脑上,然后用捷速图片文字识别软件轻松的转换成文本文字,可以随时随地用数码相机、手机自由采集书籍、报刊、标牌、展板...
  • hudun12
  • hudun12
  • 2015年06月01日 10:11
  • 8310

日语韩语等常用正则表达式(笔记)

在遇到需要用正则校验数据时,往往是在网上去找很久,结果找来的还是不很符合要求。所以我最近把开发中常用的一些正则表达式整理了一下,在这里分享一下。就当作笔记1.基础\d 匹配一个数字字符。等价于...
  • coder_chenz
  • coder_chenz
  • 2017年03月15日 17:00
  • 2245

关于emwin下的汉字显示

emwin本身是不支持直接显示汉字的,需要添加字库来协助显示,还需要选择编码(UTF-8)方式。   就字库的添加有两种:1、直接在项目代码中添加.c的字库(适合较小的字库);2、把二进制字库文件烧...
  • u010871244
  • u010871244
  • 2015年03月04日 10:38
  • 2033

Unicode中文区间

程中有时候需要用到匹配中文的正则,一般用 [ \u4e00-\u9fa5]+ 即可搞定。不过这正则对一般的火星文鸟语就不太适用了,甚至全角的标点符号都不包含在内。例如游戏里面的玩家名,普通青年一般都是...
  • scmrpu
  • scmrpu
  • 2016年04月08日 15:45
  • 815

php unicode编码转成unioce字符(中文)

有几个unicode编码如下: \u4e2d\u56fd\u4eba 如果将其换成字符的形式呢? ...
  • friendan
  • friendan
  • 2016年10月23日 11:02
  • 1349

python之分析decode、encode、unicode编码转换为汉字

decode()方法使用注册编码的编解码器的字符串进行解码。它默认为默认的字符串编码。decode函数可以将一个普通字符串转换为unicode对象。decode是将普通字符串按照参数中的编码格式进行解...
  • djd1234567
  • djd1234567
  • 2015年04月29日 22:38
  • 6265

常用汉字的UTF-8编码及编码范围

在防止恶意注册中,输入随即图片认证时可以用下面的常用字符集:(请使用IE浏览器打开) \u7684\u4e00\u4e86\u662f\u6211\u4e0d\u5728\u4eba\u4eec\u...
  • god_7z1
  • god_7z1
  • 2014年10月23日 15:31
  • 1663

Unicode中文和特殊字符的编码范围

中日韩统一表意文字(CJK Unified Ideographs),外加一些特殊的字符;用 [ \u2E80-\uFE4F]+基本都涵盖了 。根据Unicode5.0整理如下: 1)标准CJK文字 ...
  • lb521200200
  • lb521200200
  • 2016年12月13日 10:21
  • 3099
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:怎样区分中文汉字和日文汉字
举报原因:
原因补充:

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