汉字编码标准与识别(一)
代码页(code page)初识
本节是根据以下文章编写出来的,建议认真研读这些专家的高论。
参考1 <> 张 轴 材
<<计算机世界>>周报 97-1-17
参考2 <<张轴材 谈汉字交换码标准建立历程>> <<计算机世界>>周
报记者 黄伟敏 肖春江 99-8-30
参考3 <<中文平台把住“根”留住>> 吴健 <<中国计算机报>>
出版日期:1998-12-21 总期号:348 本年期号:51
参考4 <<为种种unix中文平台号脉>> 孙玉芳 <<中国计算机用户>>
出版日期:1998-07-06 总期号:323 本年期号:26
参考5 cjk.inf:ftp://ftp.ora.com/pub/examples/nutshell/ujip/
doc/cjk.inf
因为本人只是业余水平,不是专家,对于参考资料中许多术语还不
理解,更没有见过任何一种标准的正式文本,错误和模糊之处再所
难免。同时,因为国家有关部门对于宣传,推广和贯彻国家标准方
面力度不够,致使象我这样的初学者或初涉该领域的小企业因信息
资源不足而处于不利的竞争地位。
ascii制订的时候,并没有考虑对多语种,特别是对象中国汉字这样
的象形文字的支持。为此后来又提出了不少解决方案,其中代码页
体系(iso2022)是现在普遍实行的方案,而iso10646/gb13000/unicode
是今后发展的方向。
中国的汉字编码标准gb2312是7bits标准,具体说是双7位字节标准。
而ascii是单7位字节标准,计算机怎么区分呢?一种是在第八位置"1",
提示计算机转入双字节编码,这是最常见的一种实现,也叫euc
(extended unix code)编码.另一种是用特殊标记提示计算机转入双
字节编码,如hz编码就是用开始,用结束的块标识双字节编码区.它们
都是gb2312的一种实现.对象中国汉字这样的象形文字体系,代码页
是根据各个国家,地区或行业标准,按照euc方式编码。代码页向下
兼容ascii,是一种不等长编码。会带来代码的复杂性,同时还会引
起因代码页切换而带来的乱码问题。
unicode是一种多字节等长编码。iso10646/gb13000/unicode现已在
ucs2上实现一致,也就是已实现双字节编码标准。下面所讨论的
iso10646/gb13000/unicode,就只是指ucs2这种情况。unicode对
ascii采取前面加"0"字节的策略实现等长兼容。如"a"的ascii码为0x41,
unicode码就为0x00,0x41。
这里主要从国家标准(gb)系列入手了解unicode。如果不是看了参考5
(英文),我还不知道国家关于汉字编码的标准如此之多。中国人居然
要从英文资料里了解汉字编码标准,实在是很无奈的事情。
常用中文编码标准 资料来源:cjk.inf
gb2312-1980(gb0)(简体) gb7589-1987(gb2)(简体)
gb7590-1987(gb4)(简体) gb13000-1993
gb6345.1-1986(gb0修正)
gb8565.2-1988(gb8,gb0扩充)
gb/t12345-90(gb1)(繁体) gb/t13131-9x(gb3)(繁体)
gb/t13132-9x(gb5)(繁体)
其中横向表示字符集系列。纵向表示各个系列的发展标准。其中
gb2312是基本集,也就是目前最常用的标准。gb7589/gb7590是扩展
集,使用时可能不能和gb2312共存,需要切换使用。gb7589/gb7590
是按部件(部首)和笔顺(笔画)排列,但具体有什么字,怎么排列,
用在什么领域,不清楚。gb2312系列经过两次修正和扩充,已和原
始的gb2312-1980标准有些不同(参考5)。因为没有标准文本,不知
道正在使用的字体是属于哪个标准。根据最新的unicode3.0,国家
标准最新的是gb16500-95 ,更不知是哪个系列的了。iso/iec 10646
等同于gb13000-1993/jis0221-1995/ksc5000-1995这些国家标准。
制订的目标是包容各语种的文字,其中以汉字最多(unicode2.0有
20902个汉字)。关于标准的特点可以看参考1,制订过程中的风风
雨雨,可以看参考2。总之,这是一个我们国家参与并占主导地位
的国际标准。
gbk是gb2312向gb13000过渡的一个中间产物。它是gb2312的一次大
的扩展,编码向下兼容gb2312的euc编码,字汇(字符集)和gb13000
相同,是gb2312的3倍。所以说gbk也包含big5,shift-jis,ksc的
字汇。注意只是包含字汇,而编码与原始的标准是不同的。在具体
应用中,用gbk字体就可以同时显示gb2312,big5,shift-jis,ksc
的字符串。但除了gb2312字符串,其它都要转换(convert)。
因为语焉不详,不清楚制订gbk时是谁占主导地位。因为有些英文资
料说是microsoft制订了gbk,而国家方面也没有进行说明。目前从
这些参考资料只知道,94年iso/iec 10646发布后,microsoft开发
windows95中文版,要制订中文扩展编码。96年《汉字扩展内码规范》
gbk发布(参考1~3)。按标准发布比制定晚一年推算,这是95年的事。
windows95及后续版本中文版支持gbk。
gb2312的euc编码范围是第一字节0xa1~0xfe(实际只用到0xf7),第
二字节0xa1~0xfe。gbk对此进行扩展。第一字节为0x81~0xfe,第二
字节分两部分,一是0x40~0x7e,二是0x80~0xfe。其中和gb2312相
同的区域,字完全相同。扩展部分大概是按部件(部首)和笔顺(笔画)
从gb13000中取出再排列入gbk中。因此gbk并不是gb13000,虽然两者
字汇相同,但编码体系不同。一个是iso2022系列不等长编码,一个
是等长编码,并且编码区域也不同。注意到gbk实际上不是国家标准。
在此之前有一个gb2312基本集,在它之上是一个技术更先进的gb13000。
gbk只是一种过渡和扩展规范。所以在unicode里有gb2312->unicode,
gb12345->unicode的转换表格,而没有gbk->unicode转换表格。只有
microsoft制作的code page 936(cp936.txt)可以算作gbk->unicode
转换表格。但要注意这是一个商业公司制作的文件,而不是国家或
国际标准组织制作的,有可能与标准有不一致的地方。最近在方正字
体网站发现一些有用的标准文件,有兴趣可以下载看看.但要注意
gbk-big5.tab和gb-big5.tab这两个文件有点瑕疵.
http://www.founderpku.com/fontweb/download/gbk-big5.tab
http://www.founderpku.com/fontweb/download/gb-big5.tab
http://www.founderpku.com/fontweb/gb2312.htm
http://www.founderpku.com/fontweb/gbk.htm
在使用这些转换表制作其它标准的相互转换表,会和传统的转换表
有所不同。如用gbk<=>unicode<=>big5制作gbk<=>big5转换表,就
会和传统的gb<=>big5转换表有所不同。主要是汉字有简体和繁体。
前者是gbk(中的繁体字)<=>big5(繁体字),后者是gb(简体)<=>big5(繁体)。
还有就是对一些制表符选用不同。对汉字繁简转换有兴趣的读者,可以看
http://www.basistech.com/articles/c2c.html
http://www.cjk.org
内码与字体的关系
虽然没有标准文本,但还是可以大致了解常用标准有那些字。tlc4.0的
字库带有gb2312,gb12345,big5,gbk标准的pcf字体。可以用xfd实用
程序查看。在http://www.debian.org/chinese下有一个16点阵的unicode
的pcf字体。如果安装了freetype,可以使用xmbdfed软件查看ttf字体。
如果用ms word,可能会更简单些。
在日常使用中,我们实际上熟悉的是字码(内码).在中文win9x下,我们输
入一个双八位字节,就得到一个汉字,就会认为这双八位字节就是对应这
样的字形.这是错误的.其实内码对于字库来说,只是查找字形的索引.如
果换另一个编码标准的字体,同一个字符串就会呈现不同的字形,也就
是乱码。我见过gb2312,big5和iso10646/gb13000的ttf字库.对于操作系
统和应用程序来说,最喜欢的自然是iso10646/gb13000的ttf字库了.因为
这时只需提供一套代码和一套字库,修改外部配置文件,就可以用在不同的
语种环境.这就是国际化和本地化.其中有个技巧就是iso10646/gb13000的
ttf字库可以在使用时可以通过重映射变成其它标准的字库.这时需要的是
gbk->unicode,big5->unicode这些转换表.一个系统要升级支持unicode3.0,
也难也不难.简单的地方是只需修改转换表就行了(如windows
ls*.*).
难的是要升级字库.开发字库是很困难的,可以到方正字库网站看看开发字
库的步骤.win9x使用的是北京中易公司的ttf字库,ms是不可能开发一套中
文字库的.我所见过的iso10646/gb13000的ttf字库,最新的是99年版,unicode2.1
,
方正字库.要想见到unicode3.0的所有字形,也只有等这些专业字库开发商
做出来才行.如果现在就想看,只有问张轴材了.因为每通过一次新标准,中
国方面就要提供所有汉字的48×48高精密字形.使用ttf字体始终是诱人的话
题。但现在了解不多,只能简单谈谈从ttf字体生成bdf/pcf字体的问题。
因为现在中文pcf字体很少,只有宋体,仿宋,黑体,楷体四种。要想有更
多的字体,有个取巧的方法就是使用freetype库。用ttftobdf程序生成bdf
字体,再用bdftopcf程序生成pcf字体。但这种方法生成的字体缩放后比较
难看,而且不宜控制。这可能是ttf->bdf的转换过程丢失了信息,高宽比
也和标准的不一样。机器生成的东西就是机械,是不能和手绘的字体相比
的。同时,因为ttf技术已成熟,所以也没有必要继续开发更多的pcf字体。
x window将接受和大量使用ttf字体。而pcf字体今后主要用在标准字型
(如宋体),小点阵,网上快速下载传输方面。只有实际在x window下用
过unicode和ttf的字体,才会体会到使用unicode和ttf,既是一种能力,
也是一种负担。因为不论是什么格式的字体文件,最后在使用时都转化为
内存里固定点阵字体。如果是16×16点阵,一个汉字就用32字节。unicode3.0
有27786个汉字,至少需要868kb的内存。如果要中文英文美观一致,还得装
载大量的中文字体,所需内存可想而知。如果再使用ttf,还需要另一块内
存来运算和存储。因此,就算x window提供了字体cache和deferglyphs,
还是于事无补。而我们常用的汉字其实很少。根据统计,常用汉字的频率,
前165个汉字频率和>50%,前1000个汉字频率和>95%;按小学教学经验,识
字900个左右,基本可以读书,看报,写作文;按小学教学大纲,小学毕业
识字2500字;gb2312的一级字库的频率和已>99%。我想我自己识字大约为
4000~5000,对比unicode的汉字,好象一个文盲:-)。因此是用gb2312,还
是用gb13000,真是一个两难决择,我们也要为我们的选择付出代价。
最后通过内码与字体的关系,讨论utf8的作用。
utf8是现有ascii系统转向unicode系统的一个过渡解决方案。utf8是保证
ascii兼容性,再向大字符集方向扩展。这是unicode推荐的方案。但是因
为解决问题的角度不同,对现有的中文系统不是好的解决方案。
cjk字符编码标准目前都为一字/两字节。中文在ucs2中的编码范围是
u+4e00~u+9ffff。按照utf8的编码规则,为一字/三字节,增加1/3的空间。
同时和现有的cjk系统不兼容。cjk系统要使用utf8,先转换为ucs2,再转换
为utf8。后一步简直是多此一举。因为从字库的角度看,字的编码只是字形
在字库中的索引。utf8是变长码,不能直接做索引,需要转换为ucs2才能使
用字库。
随着gui的发展,字库逐渐转向ttf。ttf字库的编码标准,有gb2312/gb2312
的euc标准;big5标准;iso10646标准。没有见过utf8的ttf,也不知道cjk
这些国家有哪些系统使用了utf8编码。
目前unicodde有一个特点就是内核代码(corecode)。用户表面上可以继续使
用原有的编码标准,系统内部使用ucs2进行运算和操作。系统使用用户可改
变的标志或模块,以识别用户需要的编码标准,然后进行转换。这样,系统
只需提供一套iso10646的ttf,不修改内部代码,就可以为多个用户同时提供
中文,日文,韩文的支持。windows95及后面的中文版就是采用这个方案。现
有的x window的ttf服务器,x-tt和xfsft也可以使用这个方案。
前者在turbolinux中文版里得到了实现,后者我试验过,效果还不错。还有
一个有趣的现象,就是红旗linux1.1版所带的那个12点阵的pcf字体
/usr/x11r6/lib/x11/fonts/misc/gb12st.pcf.gz。这已不是严格意义上的
gb2312编码的字库了。用xfd实用程序查看,好象是从unicode编码的ttf字体
转换来的,有些gbk的字,可惜太少。如果他们能出些gbk编码标准的pcf字体
就好了。
cjk系统转向ucs2与ascii系统转向utf8,两者的代码修改量是相当的。只是前
者多了转换表,需要内存多些。不过ascii系统使用ucs2,需要增加50%的空间。
目前计算机里大多数还是ascii的信息,看来这也是一个问题。
