字符编码问题摘要

 UCS只是规定如何编码，并没有规定如何传输、保存这个编码。
 例如“汉”字的UCS编码是6C49，我可以用4个ASCII数字来传输、保存这个编码；也可以用UTF-8编码:3个连续的字节E6 B1 89来表示它。关键在于通信双方都要认可。
 UTF-8、UTF-7、UTF-16都是被广泛接受的方案。UTF-8的一个特别的好处是它与ISO-8859-1完全兼容。
 UTF是“UCS Transformation Format”的缩写。UCS可以看作是"Unicode Character Set"的缩写。
 UTF-8就是以8位为单元对UCS进行编码。

---------------
内码和"code page"
---------------
 目前Windows的内核已经支持Unicode字符集，这样在内核上可以支持全世界所有的语言文字。
 但是由于现有的大量程序和文档都采用了某种特定语言的编码，例如GBK，Windows不可能不支持现有的编码，而全部改用Unicode。Windows使用代码页("code page")来适应各个国家和地区。"code page"可以被理解为前面提到的内码。GBK对应的"code page"是CP936。
 微软也为GB18030定义了"code page"：CP54936。但是由于GB18030有一部分4字节编码，而Windows的代码页只支持单字节和双字节编码，所以这个"code page"是无法真正使用的。

----------------
UTF的字节序和BOM
----------------
 UTF-8以字节为编码单元，没有字节序的问题。
 UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？
 Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是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来标记文本文件的编码方式的。

--------
关于内码
--------
 内码是指操作系统内部的字符编码。早期操作系统的内码是与语言相关的。
 现在的Windows在系统内部支持Unicode，然后用代码页适应各种语言，“内码”的概念就比较模糊了。
 微软一般将缺省代码页指定的编码说成是内码。
 内码这个词汇，并没有什么官方的定义，代码页也只是微软这个公司的叫法。作为程序员，我们只要知道它们是什么东西，没有必要过多地考证这些名词。
 所谓代码页("code page")就是针对一种语言文字的字符编码。例如GBK的"code page"是CP936，BIG5的"code page"是CP950，GB2312的"code page"是CP20936。
 Windows中有缺省代码页的概念，即缺省用什么编码来解释字符。例如Windows的记事本打开了一个文本文件，里面的内容是字节流：BA、BA、D7、D6。Windows应该去怎么解释它呢？
 是按照Unicode编码解释、还是按照GBK解释、还是按照BIG5解释，还是按照ISO8859-1去解释？如果按GBK去解释，就会得到“汉字”两个字。按照其它编码解释，可能找不到对应的字符，也可能找到错误的字符。所谓“错误”是指与文本作者的本意不符，这时就产生了乱码。
 答案是Windows按照当前的缺省代码页去解释文本文件里的字节流。缺省代码页可以通过控制面板的区域选项设置。记事本的另存为中有一项ANSI，其实就是按照缺省代码页的编码方法保存。
 Windows的内码是Unicode，它在技术上可以同时支持多个代码页。只要文件能说明自己使用什么编码，用户又安装了对应的代码页，Windows就能正确显示，例如在HTML文件中就可以指定charset。
 有的HTML文件作者，特别是英文作者，认为世界上所有人都使用英文，在文件中不指定CharSet。如果他使用了0x80-0xff之间的字符，中文Windows又按照缺省的GBK去解释，就会出现乱码。这时只要在这个html文件中加上指定CharSet的语句，例如：
 
 如果原作者使用的代码页和ISO8859-1兼容，就不会出现乱码了。
 再说区位码，啊的区位码是1601，写成16进制是0x10,0x01。这和计算机广泛使用的ASCII编码冲突。为了兼容00-7f的ASCII编码，我们在区位码的高、低字节上分别加上A0。这样“啊”的编码就成为B0A1。我们将加过两个A0的编码也称为GB2312编码，虽然GB2312的原文根本没提到这一点。
 为了识别 Unicode 文件，Microsoft 建议所有的 Unicode 文件应该以 ZERO WIDTH NOBREAK SPACE（U+FEFF）字符开头。这作为一个“特征符”或“字节顺序标记（byte-order mark，BOM）”来识别文件中使用的编码和字节顺序。
 但是，Linux/UNIX 并没有使用 BOM，因为它会破坏现有的 ASCII 文件的语法约定。在 POSIX 系统中，选中的语言环境识别了在一个过程中的所有输入输出文件期望的编码形式。