WEB开发网
开发学院WEB开发Jsp 用JAVA转换简繁体的基础知识 阅读

用JAVA转换简繁体的基础知识

 2008-01-05 18:16:27 来源:WEB开发网   
核心提示:ASCII制订的时候,并没有考虑对多语种,用JAVA转换简繁体的基础知识,非凡是对象中国汉字这样的象形文字的支持,为此后来又提出了不少解决方案,没有见过UTF8的TTF,也不知道CJK这些国家有哪些系统使用了UTF8编码,其中代码页体系(ISO2022)是现在普遍实行的方案,而ISO10646/GB13000/Unic

  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。假如不是看了参考,我还不知道国家关于汉字编码的标准如此之多。中国人居然要从英文资料里了解汉字编码标准,实在是很无奈的事情。
  常用中文编码标准 资料来源: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,也难也不难.简单的地方是只需修改转换表就行了(如windowsls*.*).难的是要升级字库.开发字库是很困难的,可以到方正字库网站看看开发字库的步骤.WIN9X使用的是北京中易公司的TTF字库,MS是不可能开发一套中文字库的.我所见过的ISO10646/GB13000的TTF字库,最新的是99年版,Unicode2.1,方正字库.要想见到Unicode3.0的所有字形,也只有等这些专业字库开发商做出来才行.假如现在就想看,只有问张轴材了.因为每通过一次新标准,中国方面就要提供所有汉字的48x48高精密字形.使用TTF字体始终是诱人的话题。但现在了解不多,只能简单谈谈从TTF字体生成bdf/pcf字体的问题。
  因为现在中文pcf字体很少,只有宋体,仿宋,黑体,楷体四种。要想有更多的字体,有个取巧的方法就是使用freetype库。用ttftobdf程序生成bdf字体,再用bdftopcf程序生成pcf字体。但这种方法生成的字体缩放后比较难看,而且不宜控制。这可能是ttf->bdf的转换过程丢失了信息,高宽比也和标准的不一样。机器生成的东西就是机械,是不能和手绘的字体相比的。同时,因为TTF技术已成熟,所以也没有必要继续开发更多的pcf字体。
  X window将接受和大量使用TTF字体。而pcf字体今后主要用在标准字型(如宋体),小点阵,网上快速下载传输方面。只有实际在X Window下用过Unicode和TTF的字体,才会体会到使用Unicode和TTF,既是一种能力,也是一种负担。因为不论是什么格式的字体文件,最后在使用时都转化为
  内存里固定点阵字体。假如是16x16点阵,一个汉字就用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)。用

Tags:JAVA 转换 简繁体

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接