关于字符集

引问一： 
使用Windows记事本的“另存为”，可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件，Windows是怎样识别编码方式的呢？

我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF FE（Unicode）, FE FF（Unicode big endian）, EF BB BF（UTF-8）。但这些标记是基于什么标准呢？

引问二： 最近在网上看到一个ConvertUTF.c，实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式，我原来就了解。但这个程序让我有些糊涂，想不起来UTF-16和UCS2有什么关系。 

0、Big Endian 和 Little Endian 
big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是U+6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前面？如果在内存中按低地址到高地址顺序排列为 49 6C，就是little endian。如果是 6C 49，就是big endian。

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(big endian)敲开还是从小头(little endian)敲开，由此曾发生过六次叛乱，其中一个皇帝送了命，另一个丢了王位。

1、字符编码、内码，顺带介绍汉字编码 
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文big5。

GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030，对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。

在最初的时候，Internet上只有一种字符集——ANSI的ASCII字符集(American Standard Code for Information Interchange， “美国信息交换标准码），它使用7 bits来表示一个字符，总共表示128个字符，后来IBM公司在此基础上进行了扩展，用8bit来表示一个字符，总共可以表示256个字符，充分利用了一个字节所能表达的最大信息。ANSI字符集定义为：ASCII字符集，以及由此派生并兼容的字符集，如：GB2312，正式的名称为MBCS（Multi-Byte Chactacter System，多字节字符系统），通常也称为ANSI字符集。

这些派生字符集的特点是以ASCII 127 bits为基础，兼容ASCII 127，他们使用大于128的编码作为一个Leading Byte，紧跟在Leading Byte后的第二(甚至第三)个字符与Leading Byte一起作为实际的编码。例如在GB-2312字符集中，“联通”的编码为C1 AA CD A8，其中C1和CD就是Leading Byte。前127个编码为标准ASCII保留，例如“0”的编码是30H(30H表示十六进制的30)。软件在读取时，如果看到30H，知道它小于128就是标准ASCII，表示“0”，看到C1大于128就知道它后面有一个另外的编码，因此C1 AC一同构成一个整个的编码，在GB-2312字符集中表示“连”。

从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。某种意义上讲，ANSI=MBCS=ASCII+DBCS。

 

这里还有一些细节：

GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。

在DBCS中，GB内码的存储格式始终是Big Endian，即高位在前。

GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。

2、Unicode、UCS和UTF 
前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如“汉”字的Unicode编码是U+6C49，而GB码是0xBABA。

Unicode也是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。

根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载：历史上存在两个试图独立设计Unicode的组织，即国际标准化组织（ISO）和一个软件制造商的协会（unicode.org）。ISO开发了ISO 10646项目，Unicode协会开发了Unicode项目。

在1991年前后，双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode2.0开始，Unicode项目采用了与ISO 10646-1相同的字库和字码。

目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是10646-3:2003。

UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码，是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-8、UTF-7、UTF-16。

IETF的RFC2781和RFC3629以RFC的一贯风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。

3、UCS-2、UCS-4、UCS-4-BMP

UCS有两种格式：UCS-2和UCS-4。顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。下面让我们做一些简单的数学游戏：

UCS-2有2^16=65536个码位，UCS-4有2^31=2147483648个码位。

UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个plane。每个plane根据第3个字节分为256行 (rows)，每行包含256个cells。当然同一行的cells只是最后一个字节不同，其余都相同。

group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中，高两个字节为0的码位被称作BMP。

将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。在UCS-2的两个字节前加上两个零字节，就得到了UCS-4的BMP。而目前的UCS-4规范中还没有任何字符被分配在BMP之外。

4、UTF编码

毕竟互联网70％以上的信息仍然是英文。如果连英文都用2个字节存取(UCS-2)，空间浪费不就太多了？用UTF-8，UNICODE的2字节字符用变长个（1－3个字节）表示。从UCS-2到UTF-8的编码方式如下：

UCS编码(UCS-2 & UCS-4)    UTF-8 字节流(二进制) 
00000000-0000007F          0vvvvvvv [0-127]
00000080-000007FF          110vvvvv 10vvvvvv [128-2047]
00000800-0000FFFF          1110vvvv 10vvvvvv 10vvvvvv [2048-65535]
00010000-001FFFFF          11110vvv 10vvvvvv 10vvvvvv 10vvvvvv
00200000-03FFFFFF          111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
04000000-7FFFFFFF          1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv

可以看出，前三行属于普通UCS-2的范围。这样一来，对英文，仍然和ASCII一样用1个字节表示，这个字节的值小于128(/x80)； 对于中文字（UCS-2范围00000800-0000FFFF，对应于第三行）用一个值位于128-256之间的字节开始，再加后面紧跟的2个字节表示，一个字符一共是3个字节。例如“汉”字的UCS-2编码是U+6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89为“汉”字的UTF-8编码，由于以字节为编码单元因此没有顺序上的异议。“连通”两个字的UCS-2(big endian)标准编码为：DE 8F 1A 90， 而按上述算法转换其UTF-8编码为：E8 BF 9E E9 80 9A

UTF-16以16位为单元对UCS进行编码。对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0x10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0x10000，所以就目前而言，可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，所以就不得不考虑字节序的问题。

5、UTF的字节序和BOM 
UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是U+594E，“乙”的Unicode编码是U+4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：

在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FE FF。而FF FE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到FE FF，就表明这个字节流是big endian的；如果收到FF FE，就表明这个字节流是little endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。如下表：
EF BB BF　　　  UTF-8 
FE FF　　　　　 UTF-16/UCS-2, little endian, 俗称 Unicode 
FF FE　　　　　 UTF-16/UCS-2, big endian, 俗称 Unicode Big Endian
FF FE 00 00　　 UTF-32/UCS-4, little endian. 
00 00 FE FF　　 UTF-32/UCS-4, big-endian.

综上所述，平常我们在文本中看到的所谓Unicode都是指Unicode的传输编码UTF-8，UTF-16，UTF-16(Big Endian)（UTF-32比较不常见）。而真正要显示的时候要将传输编码转换成Unicode字符编码UCS-2的这种U+XXXX形式才行（UCS-4比较不常见）。容易混淆的地方就在于UTF-16和UCS-2是一样的，UTF-16(Big Endian)和UCS-2只有字节序的区别，因此在记事本中也是列出了ANSI、UTF-8、Unicode、Unicode(Big Endian)四种格式，我个人认为，在简体中文系统中列成GB-2312、UTF-8、UTF-16、UTF-16(Big Endian)是不是会更为合理些？毕竟Unicode这个概念太含糊了一些。

后记：值得一提的是著名的“惊天大发现！原来“微软”和“联通”有仇！”事件也是小小记事本在处理UTF-8编码问题上出的BUG。用UltraEdit打开写了“联通”二字而显示不正常的txt文件，会发现在状态栏里赫然写着“U8-DOS”，表示UltraEdit认为这是个UTF-8编码的文件，记事本也是这么认为的（个人认为UltraEdit也是白痴一个）。原因在于普通ANSI的txt文本头上并不插入上面表里的BOM字符集标记。因此，软件不能依赖于BOM来判断此文件的字符集。这时，软件可以采取一种比较安全的方式来决定字符集及其编码，那就是弹出一个对话框来请示用户，例如将那个“联通”文件拖到Word中，Word就会弹出一个对话框问你用什么方法解码，虽然默认方法也是UTF-8，人家毕竟稳妥了些。而记事本这种面向傻瓜的软件只能采取自己“猜”的方法，软件可以根据整个文本的特征来猜测它可能属于哪个charset，这就很可能不准了。事件就发生了。这是因为“联通”两个字的GB-2312编码（C1 AA CD A8）看起来更像UTF-8编码导致的，参考UTF-8编码算法表的第二行，双字节UTF-8范围都在 C0≤AA≤DF 80≤BB≤BF 这个范围内，“联通”二字都在此范围所以会被误判。
另外，不得不提醒大家的是，UltraEdit在打开UTF-8文件的时候会自作主张的把编码转化为UTF-16，亦即UCS-2，包括文件头的BOM标志，虽然在状态栏里提示出了U8-DOS格式并且给出了转换回去的方法，并且在保存文件的时候也会很好的转回UTF-8，但是还是不免引起不知者的错觉，应该BS一下！

 6、参考资料
"Short overview of ISO-IEC 10646 and Unicode"
(http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。
"Understanding Unicode A general introduction to the Unicode Standard" 
(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a) 
"Character set encoding basics Understanding character set encodings and legacy encodings" 
(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)