字符集的基础知识 博客分类： JAVA面试题 编程OracleLinuxJSFUnix

13.2.1  计算机表示字符的方式与字符集

众所周知，计算机是工作在二进制基础上的。也就是说从本质上讲，计算机只认识数字，而不认识字符。因此，要计算机认识或表示字符就必须提供字符与数字的某种映射机制。这种映射就是通过所谓的字符集来完成的。

字符集是一组文本和图形符号，每个符号映射到一组非负整数。与字符集密切相关的概念是字符编码，字符编码是指字符集映射到特定宽度的一些单元，并定义字节序列化和排序的规则。

13.2.2  字符集的发展

字符集的发展经历了一个从ASCII到Unicode（UTF-8）的演变过程。ASCII是美国信息交换标准委员会（American Standards Committee for Information Interchange）的缩写。我们知道，电子计算机技术是从美国开始发展起来的，因为美国使用的文字为美国英语，美国规定的计算机信息交换用的字符编码集是人们熟知的ASCII码，它以8bit字节为单位存储，ASCII的0-31及127为控制符，32-126为可见字     符，包括所有的英文字母，阿拉伯数字和其他一些常见符号，128-255的ASCII码则没有定义。比如，Computer用ASCII表示就是如下一些数字：67、111、109、112、117、116、101和114。由于ASCII只用了7bit，而存储时使用的是8bit，因此，字节的最高为在计算机内部通常保持为0，在数据传输时，该位常用作奇偶校验位。

ASCII 由于其字符个数有限，常常难以满足实际应用中的需要。因此，国际化标准组织又建立了所谓的ASCII扩展字符集，这种字符集就是用ASCII字符最高位为 1的单元来表示那些扩展字符，也就是用十进制128-255来表示这些扩展字符。其中最常见的要数ISO-8859-1字符集。值得一提的是，因为考虑到程序中处理的信息大多是西文信息，因此有些Web容器（如Tomcat）在处理所接收到的request字符串时，如果您没有指定request的编码方式则系统就缺省地采用ISO-8859-1，明白这一点对理解本章后面的问题会有帮助。

相比西方的拼音文字，东方的文字（如像中文这样的象形文字）的字符数要大得多，根本无法在一个字节内将它们表示出来，因此，它们以两个字节为单位存储，以中文国标字符集GB2312为例，汉字区的内码范围是：高字节B0-F7，低字节A1-FE。可见，两个字节的最高位都为1。

系统可以据此判断，若第一个字节大于127，则把与该字节后紧接着的一个字节结合起来共两个字节组成一个中文字符。这种由多个字节存储一个字符的字符集叫多字节字符集（MultiByte Charsets），对应的像ASCII这种用一个字节存储一个字符的字符集叫单字节字符集（SingleByte Charsets）。在GB2312字符集中，ASCII字符仍然用一个字节存储，换句话说该ASCII是该字符集的子集。

GB2312 共收录了7445个字符，包括6763个汉字和682个其他符号。由于该字符集包含的汉字数太少，许多生僻一点的字都不包含在内，给实际应用带来了不便。以后又对它进行了扩展，这就有了我们现在广泛使用的GBK字符集，GBK是现阶段Windows及其他一些中文操作系统的缺省字符集。它包含2万多个字符，除了保持和GB2312兼容外，还包含繁体中文字，日文字符和韩文字符。值得注意的是GBK只是一个规范而不是国家标准，新的国家标准是 GB18030-2000，它是比GBK包含字符更多的字符集。

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

可见，在字符集的世界里，呈现给我们的是一个群雄割据的局面，各字符集拥有一块自己的地盘。这给各国和各地区交换信息带来了很大的困难。比如，在早期的编程实践中，如何识别中文字符和扩展ASCII字符，如何统计字符数等看似简单的问题，处理起来是那样的棘手，再加上各种应用软件采用的处理方式也各不相同。在编程实践中，那种梦魇般的感觉可能会让很多处理过这类问题的老一些的程序员至今都挥之不去。同时，这些问题也给国际化（本地化）编程造成了很大的麻烦。

常言道：“分久必合”，如果说以前各应用程序采用的各自的一些技巧来处理字符集问题是扬汤止沸的话，那么，随着国际标准ISO10646定义的通用字符集（Universal Character Set即UCS）的出现则起到了釜底抽薪的作用，因为该字符集的出现使这种局面发生了彻底的改观。UCS 是所有其他字符集标准的一个超集。它保证与其他字符集是双向兼容的。就是说，如果你将任何文本字符串翻译到UCS格式，然后再翻译回原编码，你不会丢失任何信息。UCS包含了用于表达所有已知语言的字符。

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。后面，我们将视ISO10646和Unicode为同一个东西。

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

为了让Unicode字符集的应用落到实处，在ISO10646-1 Annex R和RFC 2279里定义的 UTF-8（Unicode Transformation Form 8-bit form）编码没有这些问题。

13.2.3  UTF-8字符集

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的范围内，并指出这个字符包含多少个字节（这可以从表格13.1中非常直观地看出，该字节由n个1带一个0的形式组成，n代表该字符要用的字节数）。多字节串的其余字节都在0x80到0xBF范围内。这使得重新同步非常容易，并使编码无国界，且很少受丢失字节的影响。

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

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

Unicode到UTF-8的转换如下表所示：

表格13.1

Unicode	UTF-8
00000000-0000007F	0xxxxxxx
00000080-000007FF	110xxxxx 10xxxxxx
00000800-0000FFFF	1110xxxx 10xxxxxx 10xxxxxx
00010000-001FFFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
00200000-03FFFFFF	111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
04000000-7FFFFFFF	1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

通过UTF-8这种形式，Unicode终于可以广泛的在各种情况下使用了。在讨论JSF的国际化编程之前，我们先来看看我们以前在JSP编程中是怎样处理中文问题的，以及我们经常遇到的中文乱码是怎样造成的。