Java中的字符集编码入门——编码字符集与字符集编码的区别

 

本文转自：http://www.blogjava.net/zhenandaci/archive/2008/12/24/248041.html

 

需要再一次强调的是，无论历史上的UCS还是现如今的Unicode，两者指的都是编码字符集，而不是字符集编码。花费一点时间来理解好这件事，然后你会发现对所有网页的，系统的，编码标准之间的来回转换等等繁杂事务都会思路清晰，手到擒来。

首先说说最一般意义上的字符集。
一个抽象字符集其实就是指字符的集合，例如所有的英文字母是一个抽象字符集，所有的汉字是一个抽象字符集，当然，把全世界所有语言的符号都放在一起，也可以称为一个抽象字符集，所以这个划分是相当人为的。之所以说“抽象”二字，是因为这里所提及的字符不是任何具体形式的字符，拿汉字中的“汉”这个字符来说，您在这篇文章中看到的这个“汉”其实是这个字符的一种具体表现形式，是它的图像表现形式，而且它是用中文（而非拼音）书写而成，使用宋体外观；而当人们用嘴发出“汉”这个音的时候，他们是在使用“汉”的另一种具体表现形式——声音，但无论如何，两者所指的字符都是“汉”这个字。同一个字符的表现形式可能有无数种（点阵表示，矢量表示，音频表示，楷体，草书等等等等），把每一种表现形式下的同一个字符都纳入到字符集中，会使得集合过于庞大，冗余高，也不好管理。因此抽象字符集中的字符，都是指唯一存在的抽象字符，而忽略它的具体表现形式。
 
抽象字符集中的诸多字符，没有顺序之分，谁也不能说哪个字符在哪个字符前面，而且这种抽象字符只有人能理解。在给一个抽象字符集合中的每个字符都分配一个整数编号之后（注意这个整数并没有要求大小），这个字符集就有了顺序，就成为了编码字符集。同时，通过这个编号，可以唯一确定到底指的是哪一个字符。当然，对于同一个字符，不同的字符集所制定的整数编号也不尽相同，例如“儿”这个字，在Unicode中，它的编号是0x513F，（为方便起见，以十六进制表示，但这个整数编号并不要求必须是以十六进制表示）意思是说它是Unicode这个编码字符集中的第0x513F个字符。而在另一种编码字符集比如Big5中，这个字就是第0xA449个字符了。这种情况的另一面是，许多字符在不同的编码字符集中被分配了相同的整数编号，例如英文字母“A”，在ASCII及Unicode中，均是第0x41个字符。我们常说的Unicode字符集，指的就是这种被分配了整数编号的字符集合，但要澄清的是，编码字符集中字符被分配的整数编号，不一定就是该字符在计算机中存储时所使用的值，计算机中存储的字符到底使用什么二进制整数值来表示，是由下面将要说到的字符集编码决定的。
 
字符集编码决定了如何将一个字符的整数编号对应到一个二进制的整数值，有的编码方案简单的将该整数值直接作为其在计算机中的表示而存储，例如英文字符就是这样，几乎所有的字符集编码方案中，英文字母的整数编号与其在计算机内部存储的二进制形式都一致。但有的编码方案，例如适用于Unicode字符集的UTF-8编码形式，就将很大一部分字符的整数编号作了变换后存储在计算机中。以“汉”字为例，“汉”的Unicode值为0x6C49，但其编码为UTF-8格式后的值为0xE6B189（注意到变成了三个字节）。这里只是举个例子，关于UTF-8的详细编码规则可以参看《Mapping codepoints to Unicode encoding forms》一文，URL为http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-AppendixA#sec3。
我们经常听说的另一种编码方案UTF-16,则对Unicode中的前65536个字符编号都不做变换，直接作为计算机存储时使用的值（对65536以后的字符，仍然要做变换），例如“汉”字的Unicode编号为0x6C49，那么经过UTF-16编码后存储在计算机上时，它的表示仍为0x6C49！。我猜，正是因为UTF-16的存在，使得很多人认为Unicode是一种编码（实际上，是一个字符集，再次重申），也因此，很多人说Unicode的时候，他们实际上指的是UTF-16。UTF-16提供了surrogate　pair机制，使得Unicode中码位大于65536的那些字符得以表示。
Surrogate pair机制在目前来说实在不常用，甚至连一些UTF-16的实现都不支持，所以我不打算在这里多加讨论，其基本的思想就是用两个16位的编码表示一个字符（注意，只对码位超过65536的字符这么做）。Unicode如此死抱着16这个数字不放，有历史的原因，也有实用的原因。

当然还有一种最强的编码，UTF-32,他对所有的Unicode字符均不做变换，直接使用编号存储！（俗称的以不变应万变），只是这种编码方案太浪费存储空间（就连1个字节就可以搞定的英文字符，它都必须使用4个字节），因而尽管使用起来方便（不需要任何转换），却没有得到普及。
记得当初Unicode与UCS还没成家之时，UCS也是需要人爱，需要人疼的，没有自己的字符集编码怎么成。UCS-2与UCS-4就扮演了这样的角色。UCS-4与UTF-32除了名字不同以外，思想完全一样。而UCS-2与UTF-16在对前65536个字符的处理上也完全相同，唯一的区别只在于UCS-2 不支持surrogate pair机制，即是说，UCS-2只能对前65536个字符编码，对其后的字符毫无办法。不过现在再谈起字符编码的时候，UCS-2与UCS-4早已成为计算机史学家才会用到的词汇，就让它们继续留在故纸堆里吧。