
0x8140-0xfefe,剔除高位 0x80 的字位。其所有字符都可以一对一映射到 Unicode 2.0,也
就是说 J AVA 实际上提供了 GBK 字符集的支持。这是现阶段 Windows 和其它一些中文
操作系统的缺省字符集,但并不是所有的国际化软件都支持该字符集,感觉是他们并不完全
知道 GBK 是怎么回事。值得注意的是它不是国家标准,而只是规范。随着 GB18030-2000
国标的发布,它将在不久的将来完成它的历史使命。
GB18030-2000(GBK2K) 在 GBK 的基础上进一步扩展了汉字,增加了藏、蒙等少数民
族的字形。GBK2K 从根本上解决了字位不够,字形不足的问题。它有几个特点,
它并没有确定所有的字形,只是规定了编码范围,留待以后扩充。
编码是变长的,其二字节部分与 GBK 兼容;四字节部分是扩充的字形、字位,
其编码范围是首字节 0x81-0xfe、二字节 0x30-0x39、三字节 0x81-0xfe、四字节
0x30-0x39。
它的推广是分阶段的,首先要求实现的是能够完全映射到 Unicode 3.0 标准的所有
字形。
它是国家标准,是强制性的。
现在还没有任何一个操作系统或软件实现了 GBK2K 的支持,这是现阶段和将来汉化
的工作内容。
Unicode 的介绍......就免了吧。
J AVA 支持的 encoding 中与中文编程相关的有:(有几个在 JDK 文档中未列出)
ASCII 7-bit, 同 ascii7
ISO8859-1 8-bit, 同 8859_1,ISO-8859-1,ISO_8859-1,latin1...
GB2312-80 同 gb2312, gb2312-1980, EUC_CN, euccn, 1381, Cp1381, 1383, Cp1383,
ISO2022CN, ISO2022CN_GB…
GBK (注意大小写),同 MS936
UTF8 UTF-8
GB18030 (现在只有 IBM JDK1.3.?有支持), 同 Cp1392,1392
JAVA 语言采用 Unicode 处理字符. 但从另一个角度来说,在 java 程序中也可以采用非
Unicode 的转码,重要的是保证程序入口和出口的汉字信息不失真。如完全采用 ISO-8859-1
来处理汉字也能达到正确的结果。网络上流行的许多解决方法,都属于这种类型。为了不致
引起混淆,本文不对这种方法作讨论。
3. 中文转码时'?'、乱码的由来
两个方向转换都有可能得到错误的结果:
Unicode-->Byte, 如果目标代码集不存在对应的代码,则得到的结果是 0x3f.
如:"\u00d6\u00ec\u00e9\u0046\u00bb\u00f9".getBytes("GBK") 的结果是 "?ìéF?ù",
Hex 值是 3fa8aca8a6463fa8b4.
仔细看一下上面的结果,你会发现\u00ec 被转换为 0xa8ac, \u00e9 被转换为\xa8a6...
它的实际有效位变长了! 这是因为 GB2312 符号区中的一些符号被映射到一些公
共的符号编码,由于这些符号出现在 ISO-8859-1 或其它一些 SBCS 字符集中,故
它们在 Unicode 中编码比较靠前,有一些其有效位只有 8 位,和汉字的编码重叠(其
实这种映射只是编码的映射,在显示时仔细不是一样的。Unicode 中的符号是单字
节宽,汉字中的符号是双字节宽) . 在 Unicode\u00a0--\u00ff 之间这样的符号有 20
个。了解这个特征非常重要!由此就不难理解为什么 JAVA 编程中,汉字编码的错
评论0