Struts原理与实践_PHP

Struts

本篇我们来讨论一下struts的国际化编程问题，即所谓的i18n编程问题，这一篇我们讨论其基础部分。与这个问题紧密相关的是在各java论坛中被频繁提及的中文乱码问题，因为，英、美编程人员较少涉及到中文乱码问题，因此，这方面的英文资料也是非常奇缺的，同时也很少找到这方面比较完整的中文资料，本文也尝试对中文乱码问题做一些探讨。要解决上述问题，需要有一定的字符集方面的知识，下面，我们就先介绍字符集的有关情况： 

一、从ASCII到Unicode（UTF-8） 

电子计算机技术是从美国开始发展起来的，因为美国使用的文字为英文，美国规定的计算机信息交换用的字符编码集是人们熟知的扩展ASCII码，它以8bit字节为单位存储，ASCII的0-31及127为控制符，32-126为可见字符，包括所有的英文字母，阿拉伯数字和其他一些常见符号，128-255的ASCII码则没有定义。 

ASCII对英语国家是够用了，但对其他西欧国家却不够用，因此，人们将ASCII扩展到0-255的范围，形成了ISO-8859-1字符集。值得一提的是，因为考虑到程序中处理的信息大多是西文信息，因此有些WEB容器（如：Tomcat4.x）在处理所接收到的request字符串时，如果您没指定request的编码方式则系统就缺省地采用ISO-8859-1，明白这一点对理解后面的问题会有帮助。 

相比西方的拼音文字，东方的文字（如中文）的字符数要大得多，根本不可能在一个字节内将它们表示出来，因此，它们以两个字节为单位存储，以中文国标字符集GB2312为例，它的第一个字节为128-255。系统可以据此判断，若第一个字节大于127，则把与该字节后紧接着的一个字节结合起来共两个字节组成一个中文字符。这种由多个字节存储一个字符的字符集叫多字节字符集（MultiByte Charsets），对应的象ASCII这种用一个字节存储一个字符的字符集叫单字节字符集（SingleByte Charsets）。在GB2312字符集中，ASCII字符仍然用一个字节存储，换句话说该ASCII是该字符集的子集。 

GB2312只包含数千个常用汉字，往往不能满足实际需要，因此，人们对它进行扩展，这就有了我们现在广泛使用的GBK字符集，GBK是现阶段Windows及其他一些中文操作系统的缺省字符集。它包含2万多个字符，除了保持和GB2312兼容外，还包含繁体中文字，日文字符和朝鲜字符。值得注意的是GBK只是一个规范而不是国家标准，新的国家标准是GB18030-2000，它是比GBK包含字符更多的字符集。 

我国的台湾地区使用的文字是繁体字，其字符集是BIG5，而日本采用的字符集则是SJIS。它们的编码方法与GB2312类似，它们的ASCII字符部分是兼容的，但扩展部分的编码则是不兼容的，比如这几种字符集中都有"中文"这两个字符，但他们在各自的字符集中的编码并不相同，这就是用GB2312写成的网页用BIG5浏览时，看到的是乱糟糟的信息的原因。 

可见，在字符集的世界里，呈现给我们的是一个群雄割据的局面，各字符集拥有一块自己的地盘。这给各国和各地区交换信息带来了很大的困难，同时，也给国际化（本地化）编程造成了很大的麻烦。 

常言道："分久必合"，随着国际标准ISO10646定义的通用字符集（Universal Character Set即UCS）的出现，使这种局面发生了彻底的改观。UCS 是所有其他字符集标准的一个超集. 它保证与其他字符集是双向兼容的. 就是说, 如果你将任何文本字符串翻译到 UCS格式, 然后再翻译回原编码, 你不会丢失任何信息。UCS 包含了用于表达所有已知语言的字符。不仅包括拉丁语、希腊语、 斯拉夫语、希伯来语、阿拉伯语、亚美尼亚语和乔治亚语的描述、还包括中文、 日文和韩文这样的象形文字、 以及平假名、片假名、 孟加拉语、 旁遮普语果鲁穆奇字符(Gurmukhi)、 泰米尔语、印.埃纳德语(Kannada)、Malayalam、泰国语、 老挝语、 汉语拼音(Bopomofo)、Hangul、 Devangari、Gujarati、Oriya、Telugu 以及其他数也数不清的语。对于还没有加入的语言， 由于正在研究怎样在计算机中最好地编码它们， 因而最终它们都将被加入。 

ISO 10646 定义了一个 31 位的字符集。 然而， 在这巨大的编码空间中， 迄今为止只分配了前 65534 个码位 (0x0000 到 0xFFFD)。 这个 UCS 的 16位子集称为 基本多语言面 (Basic Multilingual Plane, BMP)。 将被编码在 16 位 BMP 以外的字符都属于非常特殊的字符(比如象形文字)， 且只有专家在历史和科学领域里才会用到它们。 

UCS 不仅给每个字符分配一个代码， 而且赋予了一个正式的名字。 表示一个 UCS 值的十六进制数， 通常在前面加上 "U+", 就象 U+0041 代表字符"拉丁大写字母A"。 UCS 字符 U+0000 到 U+007F 与 US-ASCII(ISO 646) 是一致的， U+0000 到 U+00FF 与 ISO 8859-1(Latin-1) 也是一致的。这里要注意的是它是以16bit为单位存储，即便对字母"A"也是用16bit，这是与前面介绍的所有字符集不同的地方。 

历史上，在国际标准化组织研究ISO10646标准的同时，另一个由多语言软件制造商组成的协会也在从事创立单一字符集的工作，这就是现在人们熟知的Unicode。幸运的是，1991年前后ISO10646和Unicode的参与者都认识到，世界上不需要两个不同的单一字符集。他们合并双方的工作成果，并为创立单一编码表而协同工作。两个项目仍都存在并独立地公布各自的标准，都同意保持ISO10646和Unicode的码表兼容，并紧密地共同调整任何未来的扩展。这与当年在PC机上的操作系统MS-dos与PC-dos的情形有些相象。后面，我们将视ISO10646和Unicode为同一个东西。 

有了Unicode，字符集问题接近了完美的解决，但不要高兴得过早。由于历史的原因：一些操作系统如：Unix、Linux等都是基于ASCII设计的。此外，还有一些数据库管理系统软件如：Oracle等也是围绕ASCII来设计的(从其8i的白皮书上介绍的设置系统字符集和字段的字符集中可以间接地看到这一点)。在这些系统中直接用Unicode会导致严重的问题。用这些编码的字符串会包含一些特殊的字符， 比如 '\0' 或 '/'， 它们在 文件名和其他 C 库函数参数里都有特别的含义。 另外， 大多数使用 ASCII 文件的 UNIX 下的工具， 如果不进行重大修改是无法读取 16 位的字符的。 基于这些原因， 在文件名, 文本文件, 环境变量等地方，直接使用Unicode是不合适的。 

在 ISO 10646-1 Annex R 和 RFC 2279 里定义的 UTF-8 （Unicode Transformation Form 8-bit form）编码没有这些问题。 

UTF-8 有以下一些特性： 

UCS 字符 U+0000 到 U+007F (ASCII) 被编码为字节 0x00 到 0x7F (ASCII 兼容)。 这意味着只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 两种编码方式下是一样的。 

所有 >U+007F 的 UCS 字符被编码为一个多个字节的串， 每个字节都有标记位集。 因此，ASCII 字节 (0x00-0x7F) 不可能作为任何其他字符的一部分。 

表示非 ASCII 字符的多字节串的第一个字节总是在 0xC0 到 0xFD 的范围里, 并指出这个字符包含多少个字节。 多字节串的其余字节都在 0x80 到 0xBF 范围里。 这使得重新同步非常容易， 并使编码无国界，且很少受丢失字节的影响。 

UTF-8 编码字符理论上可以最多到 6 个字节长， 然而 16 位 BMP 字符最多只用到 3 字节长。 

字节 0xFE 和 0xFF 在 UTF-8 编码中从未用到。