再次看编码

转载：http://techmi.cn/archives/你不知道的字符集和编码.html

         http://news.cnblogs.com/n/139987/

 

其实即使是现在对编码还是很糊，原因很多概念的混乱，不明晰导致的。

常说的字符集和编码区别，其实就是编码字符集和字符集编码的区别，其实，单单如果只是说字符集，没有任何编码的概念的话，那么字符集其实仅仅是一个简单的字符的集合，或者说是一个抽象的字符的集合，包括文字，符号等等，不参与任何存储形式，只是存在这么各种各样标准的字符的集合。

如果仅仅是抽象的字符集，我们是无需拿出讨论的，因为没有任何异议，通俗易懂，而常说的字符集指的编码字符集，比如常见的 unicode、ascii、gb2312、gbk等，这些我们常称做为字符集（其实是编码字符集），这些字符集，比如unicode其实本质上是已经“编码”过的字符集，即每个字符都有唯一的整数编号，每个字符都有自己特有的编号，同一个字符在不同编码字符集中编号也会不同，当然很多编码字符集都是ascll的超集，所以ascll字符集的编号与很多编码字符集中编号都一样，比如英文字母“A”，在ASCII及Unicode及GB2312中，均是第0×41个字符，说到这里朋友一定注意到了我上面再描述“ unicode其实本质上是已经“编码”过的字符集”中的“编码”二字加了双引号，我要强调的是这里的“编码”并不是真的我下面要说的编码，这里只是为每个字符编了一个对应的编号，但是我们还是习惯专业的称呼为“编码字符集”

我们经常说“文章采用的是utf-8编码方式”

我对于这个编码方式的意义，个人理解是 将一个字符的整数编号用一个什么二进制的整数值来对应并在计算机存储。这和上面说的编码字符集中的“编码”千差万别，这里我们称之为“字符集编码”，即我们常说的编码

说到这里，很多人会觉得那么unicode和utf-8的区别在哪里？既然上文说到unicode是编码字符集，那么utf-8又是什么？就是常说的编码？

“文章采用的是utf-8编码方式”，个人觉得准确的说法是“文章采用的是基于unicode编码字符集的utf-8的编码方案”，即

即unicode本身作为编码字符集没有任何存储形式，只是一个编号和字符对应的表而已，如何在计算机存储？你可能想到了干脆直接把编号当作二进制数值来直接存储，那么为什么不这么做呢？这也算是一种字符集编码方案，就是基于unicode编码字符集的utf-32编码方案，那么有没有更加智能一点的编码方案呢？为什么会没有呢？那就是utf-8、utf-16等等， 等等，在我解释为何要用utf-8编码方案的时候，我必须说明一件事情：如下

我在上一篇文章《你不知道的 页面编码，浏览器选择编码，get，post各种乱码由来》中说过：“如何查看中文字符的十六进制字符串？方法：BitConverter.ToString(System.Text.Encoding.UTF8.GetBytes(“阿道夫”));” 请注意我可以改为“System.Text.Encoding.Unicode.GetBytes” 如下图是vs2013 Encoding键入“.”后的智能提示

（列表过长，用两幅图分别截图）

上图有两个疑问：

1、如果说unicode是编码字符集，为何会出现在和utf-8这种编码方案并列的列表中？

2、ASCII或者gb2312都是编码字符集为何也会出现在和utf-8这种编码方案并列的列表中？

我们假设有两个猜测：

1、此处的unicode并不是真正的unicode编码字符集，可能只是一种和unicode编码字符集关系非常紧密的一种编码方案

2、ASCII或者gb2312（其实就是图中的Default,即操作系统当前的编码，国内一般为gb2312）是编码字符集没有错，但是对于ASCII或者gb2312都只有唯一一种编码，那么我称呼它们为ASCII编码或者GB2312编码也没有问题，既然这样，那我把ascii和gb2312加入和utf-8这种编码方案并列的列表中也理所当然？

我的两个假设，很快得到论证

1、在Encoding 的元数据看到：

 

1 2 3 4 5 6 7

//         // 摘要:         //     获取使用 Little-Endian 字节顺序的 UTF-16 格式的编码。         //         // 返回结果:         //     使用 Little-Endian 字节顺序的 UTF-16 格式的编码。         public static Encoding Unicode { get; }

这里解释在这里的unicode其实本质上“获取使用 Little-Endian 字节顺序的 UTF-16 格式的编码”，即使基于unicode编码字符集的utf-16编码方案，类似的有BigEndianUnicode（获取使用 Big Endian 字节顺序的 UTF-16 格式的编码）

2、一般的ASCII或者gb2312，我们可以称呼为ASCII字符集也可以称呼为ASCII编码，只是意义不同而已，因为对于ASCII编码字符集或者gb2312编码字符集都只有唯一一种编码，就是ASCII编码和GB2312编码，那么列表中显示的ASCII和GB2312指的不是编码字符集而是ASCII和GB2312的编码方案，我想正是这种原因，才在很多时候，不管是字符集赋值还是编码方案赋值都可以直接用gb2312或者ascii，比如：

Encoding gb2312 = Encoding.GetEncoding(“gb2312″);

Response.ContentEncoding = gb2312;//编码

Response.Charset=”gb2312″;//字符集

总结下的说：

就是unicode是字符集，不是编码！但是ascii（gb2312）是字符集，这个说法肯定正确，但是我表达为“ascii编码”也不能说大错特错，但是这种说法让人误解，如果一定要说那么就说“ascii编码字符集的编码”

如果理解上面两个假设的论证道理，那么我们继续讨论之前暂停的话题，即“解释为何要用utf-8等编码方案（其他utf编码方案类似）”

utf-8将很大一部分基于unicode编码字符集的字符的整数编号作了变换后存储在计算机中。（引用）以“汉”字为例，“汉”的Unicode值为0x6C49，但其编码为UTF-8格式后的值为0xE6B189（注意到变成了三个字节）。对于UTF-16编码方案，则是对unicode编码字符集中的前65536个字符编号都不做变换，直接作为计算机存储时使用的值（对65536以后的字符，仍然要做变换），例如“汉”字的Unicode编号为0x6C49，那么经过UTF-16编码后存储在计算机上时，它的表示仍为0x6C49，对于UTF-32编码方案，他对所有的Unicode字符均不做变换，直接使用编号存储，只是这种编码方案太浪费存储空间（就连1个字节就可以搞定的英文字符，它都必须使用4个字节）

既然unicode编码字符集有如此多的编码方案，那么

utf-8，字母数字符号等占1字节，汉字占三字节

utf-16,对unicode编码字符集中的前65536个字符都占两个字节

utf-32，全部占四字节

如果还有人问：

“unicode编码每个字符占几个字节”，我们可以理直气壮的说，第一unicode不是编码！第二每个字符具体占多少字节是要看编码方案！

很多面试题会问：

 

1 2 3

string param = "abc阿道夫"; int length1 = System.Text.Encoding.Unicode.GetBytes(param).Length;//别忘了这里的unicode本质是utf-16编码方案 int length2 = param.Length;

那么答案就是12和6了

最后，对于gb2312或者ascii编码字符集的字符的编号就是直接存储在计算机中的二进制数，也就是说gb2312和ascii编码字符集都只有一种编码方案，因为在gb2312编码字符集中的ascii字符集部分的编号并没有变化（即和ascii编码字符集中的编码一致），所以gb2312的ascii部分字符存入计算机的二进制数还是占用1个字节，而中文字符存入计算机的二进制数也是该中文字符在gb2312编码字符集中的编号，该编号一般转换成二进制数都占两个字节，这个过程也就变成了所谓的gb2312编码

如果上面的改为System.Text.Encoding.Default.GetBytes(param).Length，则值就是9和6了

 

##################################################################################

 

编码问题的例子

　　在 Windows 自带的 Notepad（记事本）程序中输入“联通”两个字，保存后再次打开，会发现“联通”不见了，代之以“��ͨ”的乱码。这是 Windows 平台上典型的中文编码问题。即文件保存的时候是按照 ANSI 编码（其实就是 GB2312，后面会详细介绍）保存，打开的时候程序按照 UTF-8方式对内容解释，于是就出现了乱码。避免乱码的方式很简单，在“文件”菜单中选择“打开”命令，选择保存的文件，然后选择“ANSI”编码，此时就能看到久违的“联通”两个字了。

　　在 Linux 平台上如果使用 cat 等命令查看文件中的中文内容时，可能出现乱码。这也是编码的问题。简单的说是文件时按照A编码保存，但是 cat 命令按照当前 Locale 设定的B编码去查看，在B和A不兼容的时候就出现了乱码。

　　为什么写这篇文章

　　中文编码由于历史原因牵扯到不少标准，在不了解的时候感觉一头雾水；但其实理解编码问题并不需要你深入了解各个编码标准，只要你明白了来龙去脉，了解了关键的知识点，就能分析和解决日常开发工作中碰到的大部分编码问题。有感于我看过的资料和文章要么不够全面，要么略显枯燥，所以通过这篇文章记录下笔者在日常工作中碰到的中文编码原理相关问题，目的主要是自我总结，如果能给读者提供一些帮助那就算是意外之喜了。由于严谨的编码标准对我来说是无趣的，枯燥的，难以记忆的，本文尝试用浅显易懂的生活语言解释中文编码相关的（也可能不相关的）一些问题，这也是为什么取名杂谈的原因。本文肯定存在不规范不全面的地方，我会在参考资料里给出官方文档的链接，也欢迎读者在评论中提出更好的表达方式&指出错误，不胜感激。

　　对编码问题的理解我认为分为三个层次，第一个层次：概念，知道各个编码标准的应用场景，了解之间的差异，能分析和解决常见的一些编码问题。第二个层次：标准，掌握编码的细节，如编码范围，编码转换规则，知道这些就能自行开发编码转换工具。第三个层次，使用，了解中文的编码二进制存储，在程序开发过程中选择合理的编码并处理中文。为了避免让读者陷入编码标准的黑洞无法脱身（不相信？看看 unicode 的规范就明白我的意思了），同时由于编码查询&转换工具等都有现成工具可以使用，本文只涉及第一个层次，不涉及第二层次，在第三层次上会做一些尝试。在本文的最后提供了相关链接供对标准细节感兴趣的同学继续学习。最后，本文不涉及具体软件的乱码问题解决，如 ssh，shell，vim，screen 等，这些话题留给剑豪同学专文阐述。

　　一切都是因为电脑不识字

　　电脑很聪明，可以帮我们做很多事情，最开始主要是科学计算，这也是为什么电脑别名计算机。电脑又很笨，在她的脑子里只有数字，即所有的数据在存储和运算时都要使用二进制数表示。这在最初电脑主要用来处理大量复杂的科学计算时不是什么大问题，但是当电脑逐步走入普通人的生活时，情况开始变糟了。办公自动化等领域最主要的需求就是文字处理，电脑如何来表示文字呢？这个问题当然难不倒聪明的计算机科学家们，用数字来代表字符呗。这就是“编码”。

　　英文的终极解决方案：ASCII

　　每个人都可以约定自己的一套编码，只要使用方之间了解就 ok 了。比如说咱俩约定0×10表示a，0×11表示b。在一开始也的确是这样的，出现了各式各样的编码。这样有两个问题：1. 各个编码的字符集不一样，有的多，有的少。2. 相同字符的编码也不一样。你这里a是0×10，他那里a可能是0×30。于是你保存的文件他就不能直接用，必须要转换编码。随着沟通范围的扩大，采用不同编码的人们互相通信就乱套了，这就是我们常说的：鸡同鸭讲。如果要避免这种混乱，那么大家就必须使用相同的编码规则，于是美国有关的标准化组织就出台了 ASCII（American Standard Code for Information Interchange）编码，统一规定了英文常用符号用哪些二进制数来表示。ASCII 是标准的单字节字符编码方案，用于基于文本的数据。

　　ASCII 最初是美国国家标准，供不同计算机在相互通信时用作共同遵守的西文字符编码标准，已被国际标准化组织（International Organization for Standardization, ISO）定为国际标准，称为 ISO 646 标准。适用于所有拉丁文字字母。ASCII 码使用指定的 7 位或 8 位二进制数组合来表示 128 或 256 种可能的字符。标准 ASCII 码也叫基础 ASCII 码，使用 7 位二进制数来表示所有的大写和小写字母，数字 0 到9、标点符号， 以及在美式英语中使用的特殊控制字符。而最高位为 1 的另 128 个字符（80H—FFH）被称为“扩展 ASCII”，一般用来存放英文的制表符、部分音标字符等等的一些其它符号。

　　其中：0～31及127(共33个)是控制字符或通信专用字符（其余为可显示字符），32～126(共 95 个)是字符(32是空格），其中 48～57为 0 到 9 十个阿拉伯数字，65～90为 26 个大写英文字母，97～122号为 26 个小写英文字母，其余为一些标点符号、运算符号等。

　　现在所有使用英文的电脑终于可以用同一种编码来交流了。理解了 ASCII 编码，其他字母型的语言编码方案就触类旁通了。

　　一波三折的中文编码

　　第一次尝试：GB2312

　　ASCII 这种字符编码规则显然用来处理英文没有什么问题，它的出现极大的促进了信息在西方尤其是美国的传播和交流。但是对于中文，常用汉字就有 6000 以上，ASCII 单字节编码显然是不够用。为了粉碎美帝国主义通过编码限制中国人民使用电脑的无耻阴谋，中国国家标准总局发布了 GB2312 码即中华人民共和国国家汉字信息交换用编码，全称《信息交换用汉字编码字符集——基本集》，1981年 5 月 1 日实施，通行于大陆。GB2312字符集中除常用简体汉字字符外还包括希腊字母、日文平假名及片假名字母、俄语西里尔字母等字符，未收录繁体中文汉字和一些生僻字。 EUC-CN 可以理解为 GB2312 的别名，和 GB2312 完全相同。

　　GB2312是基于区位码设计的，在区位码的区号和位号上分别加上 A0H 就得到了 GB2312 编码。这里第一次提到了“区位码”，我就连带把下面这几个让人摸不到头脑的 XX 码一锅端了吧：

　　区位码，国标码，交换码，内码，外码

　　区位码：就是把中文常用的符号，数字，汉字等分门别类进行编码。区位码把编码表分为 94 个区，每个区对应 94 个位，每个位置就放一个字符（汉字，符号，数字都属于字符）。这样每个字符的区号和位号组合起来就成为该汉字的区位码。区位码一般用 10 进制数来表示，如 4907 就表示 49 区 7 位，对应的字符是“学”。区位码中 01-09区是符号、数字区，16-87区是汉字区，10-15和 88-94是未定义的空白区。它将收录的汉字分成两级：第一级是常用汉字计 3755 个，置于 16-55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字计 3008 个，置于 56-87区，按部首/笔画顺序排列。在网上搜索“区位码查询系统”可以很方便的找到汉字和对应区位码转换的工具。为了避免广告嫌疑和死链，这里就不举例了。

　　国标码： 区位码无法用于汉字通信，因为它可能与通信使用的控制码（00H~1FH）（即0~31，还记得 ASCII 码特殊字符的范围吗？）发生冲突。于是 ISO2022 规定每个汉字的区号和位号必须分别加上 32（即二进制数 00100000，16进制 20H），得到对应的国标交换码，简称国标码，交换码，因此，“学”字的国标交换码计算为：

  00110001 00000111

+ 00100000 00100000

 -------------------

  01010001 00100111 

　　用十六进制数表示即为 5127H。

　　交换码：即国标交换码的简称，等同上面说的国标码。

　　内码：由于文本中通常混合使用汉字和西文字符，汉字信息如果不予以特别标识，就会与单字节的 ASCII 码混淆。此问题的解决方法之一是将一个汉字看成是两个扩展 ASCII 码，使表示 GB2312 汉字的两个字节的最高位都为1。即国标码加上 128（即二进制数 10000000,16进制 80H）这种高位为 1 的双字节汉字编码即为 GB2312 汉字的机内码，简称为内码。20H+80H=A0H。这也就是常说的在区位码的区号和位号上分别加上 A0H 就得到了 GB2312 编码的由来。

  00110001 00000111

+ 10100000 10100000

  -------------------

  11010001 10100111 

　　用十六进制数表示即为 D1A7H。

　　外码：机外码的简称，就是汉字输入码，是为了通过键盘字符把汉字输入计算机而设计的一种编码。 英文输入时，相输入什么字符便按什么键，外码和内码一致。汉字输入时，可能要按几个键才能输入一个汉字。 汉字输入方案有成百上千个，但是这千差万别的外码输入进计算机后都会转换成统一的内码。

　　最后总结一下上面的概念。中国国家标准总局把中文常用字符编码为 94 个区，每个区对应 94 个位，每个字符的区号和位号组合起来就是该字符的区位码, 区位码用 10 进制数来表示，如 4907 就表示 49 区 7 位，对应的字符是“学”。 由于区位码的取值范围与通信使用的控制码（00H~1FH）（即0~31）发生冲突。每个汉字的区号和位号分别加上 32（即 16 进制 20H）得到国标码，交换码。“学”的国标码为 5127H。由于文本中通常混合使用汉字和西文字符，为了让汉字信息不会与单字节的 ASCII 码混淆，将一个汉字看成是两个扩展 ASCII 码，即汉字的两个字节的最高位置为1，得到的编码为 GB2312 汉字的内码。“学”的内码为 D1A7H。无论你使用什么输入法，通过什么样的按键组合把“学”输入计算机，“学”在使用 GB2312（以及兼容 GB2312）编码的计算机里的内码都是 D1A7H。

　　第二次尝试：GBK

　　GB2312的出现基本满足了汉字的计算机处理需要，但由于上面提到未收录繁体字和生僻字，从而不能处理人名、古汉语等方面出现的罕用字，这导致了 1995 年《汉字编码扩展规范》（GBK）的出现。GBK 编码是 GB2312 编码的超集，向下完全兼容 GB2312，兼容的含义是不仅字符兼容，而且相同字符的编码也相同，同时在字汇一级支持 ISO/IEC10646—1和 GB 13000—1的全部中、日、韩（CJK）汉字，共计 20902 字。GBK 还收录了 GB2312 不包含的汉字部首符号、竖排标点符号等字符。CP936和 GBK 的有些许差别，绝大多数情况下可以把 CP936 当作 GBK 的别名。

　　第三次尝试：GB18030

　　GB18030编码向下兼容 GBK 和 GB2312。GB18030收录了所有 Unicode3.1 中的字符，包括中国少数民族字符，GBK 不支持的韩文字符等等，也可以说是世界大多民族的文字符号都被收录在内。GBK 和 GB2312 都是双字节等宽编码，如果算上和 ASCII 兼容所支持的单字节，也可以理解为是单字节和双字节混合的变长编码。GB18030编码是变长编码，有单字节、双字节和四字节三种方式。

　　其实，这三个标准并不需要死记硬背，只需要了解是根据应用需求不断扩展编码范围即可。从 GB2312 到 GBK 再到 GB18030 收录的字符越来越多即可。万幸的是一直是向下兼容的，也就是说一个汉字在这三个编码标准里的编码是一模一样的。这些编码的共性是变长编码，单字节 ASCII 兼容，对其他字符 GB2312 和 GBK 都使用双字节等宽编码，只有 GB18030 还有四字节编码的方式。这些编码最大的问题是 2 个。1. 由于低字节的编码范围和 ASCII 有重合，所以不能根据一个字节的内容判断是中文的一部分还是一个独立的英文字符。2. 如果有两个汉字编码为 A1A2B1B2，存在 A2B1 也是一个有效汉字编码的特殊情况。这样就不能直接使用标准的字符串匹配函数来判断一个字符串里是否包含某一个汉字，而需要先判断字符边界然后才能进行字符匹配判断。

　　最后，提一个小插曲，上面讲的都是大陆推行的汉字编码标准，使用繁体的中文社群中最常用的电脑汉字字符集标准叫大五码（Big5），共收录 13,060个中文字，其中有二字为重覆编码(实在是不应该)。Big5虽普及于中国的台湾、香港与澳门等繁体中文通行区，但长期以来并非当地的国家标准，而只是业界标准。倚天中文系统、Windows 等主要系统的字符集都是以 Big5 为基准，但厂商又各自增删，衍生成多种不同版本。2003年，Big5被收录到台湾官方标准的附录当中，取得了较正式的地位。这个最新版本被称为 Big5-2003。

　　天下归一 Unicode

　　看了上面的多个中文编码是不是有点头晕了呢？如果把这个问题放到全世界n多个国家n多语种呢？各国和各地区自己的文字编码规则互相冲突的情况全球信息交换带来了很大的麻烦。

　　要真正彻底解决这个问题，上面介绍的那些通过扩展 ASCII 修修补补的方式已经走不通了，而必须有一个全新的编码系统，这个系统要可以将中文、日文、法文、德文……等等所有的文字统一起来考虑，为每一个文字都分配一个单独的编码。于是，Unicode 诞生了。Unicode（统一码、万国码、单一码）为地球上（以后会包括火星，金星，喵星等）每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。在 Unicode 里，所有的字符被一视同仁，汉字不再使用“两个扩展 ASCII”，而是使用“1个 Unicode”来表示，也就是说，所有的文字都按一个字符来处理，它们都有一个唯一的 Unicode 码。Unicode 用数字0-0x10FFFF 来映射这些字符，最多可以容纳 1114112 个字符，或者说有 1114112 个码位（码位就是可以分配给字符的数字）。

　　提到 Unicode 不能不提 UCS（通用字符集 Universal Character Set）。UCS 是由 ISO 制定的 ISO 10646（或称 ISO/IEC 10646）标准所定义的标准字符集。UCS-2用两个字节编码，UCS-4用 4 个字节编码。Unicode 是由 unicode.org 制定的编码机制，ISO 与 unicode.org 是两个不同的组织， 虽然最初制定了不同的标准; 但目标是一致的。所以自从 Unicode 2.0 开始， Unicode 采用了与 ISO 10646-1相同的字库和字码， ISO 也承诺 ISO10646 将不会给超出 0x10FFFF 的 UCS-4编码赋值， 使得两者保持一致。大家简单认为 UCS 等同于 Unicode 就可以了。

　　在 Unicode 中：汉字“字”对应的数字是 23383。在 Unicode 中，我们有很多方式将数字 23383 表示成程序中的数据，包括：UTF-8、UTF-16、UTF-32。UTF 是“UCS Transformation Format”的缩写，可以翻译成 Unicode 字符集转换格式，即怎样将 Unicode 定义的数字转换成程序数据。例如，“汉字”对应的数字是 0x6c49 和 0x5b57，而编码的程序数据是：

BYTE data_utf8[] = {0xE6, 0xB1, 0x89, 0xE5, 0xAD, 0x97}; // UTF-8编码

WORD data_utf16[] = {0x6c49, 0x5b57}; // UTF-16编码

DWORD data_utf32[] = {0x6c495b57}; // UTF-32编码 

　　这里用 BYTE、WORD、DWORD 分别表示无符号 8 位整数，无符号 16 位整数和无符号 32 位整数。UTF-8、UTF-16、UTF-32分别以 BYTE、WORD、DWORD 作为编码单位。“汉字”的 UTF-8编码需要 6 个字节。“汉字”的 UTF-16编码需要两个 WORD，大小是 4 个字节。“汉字”的 UTF-32编码需要两个 DWORD，大小是 8 个字节。根据字节序的不同，UTF-16可以被实现为 UTF-16LE 或 UTF-16BE，UTF-32可以被实现为 UTF-32LE 或 UTF-32BE。

　　下面介绍 UTF-8、UTF-16、UTF-32、BOM。

　　UTF-8

　　UTF-8以字节为单位对 Unicode 进行编码。从 Unicode 到 UTF-8的编码方式如下：　　

Unicode 编码(16进制)	UTF-8 字节流(二进制)
000000 – 00007F	0xxxxxxx
000080 – 0007FF	110xxxxx 10xxxxxx
000800 – 00FFFF	1110xxxx 10xxxxxx 10xxxxxx
010000 – 10FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

　　UTF-8的特点是对不同范围的字符使用不同长度的编码。对于0×00-0x7F 之间的字符，UTF-8编码与 ASCII 编码完全相同。UTF-8编码的最大长度是 4 个字节。从上表可以看出，4字节模板有 21 个x，即可以容纳 21 位二进制数字。Unicode 的最大码位 0x10FFFF 也只有 21 位。总结了一下规律：UTF-8的第一个字节开始的 1 的个数代表了总的编码字节数，后续字节都是以 10 开始。由上面的规则可以清晰的看出 UTF-8编码克服了中文编码的两个问题。

　　例1：“汉”字的 Unicode 编码是 0x6C49。0x6C49在0×0800-0xFFFF 之间，使用 3 字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将 0x6C49 写成二进制是：0110 1100 0100 1001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即 E6 B1 89。

　　例2：Unicode 编码 0x20C30 在0×010000-0x10FFFF 之间，使用用 4 字节模板了：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx。将 0x20C30 写成 21 位二进制数字（不足 21 位就在前面补0）：0 0010 0000 1100 0011 0000，用这个比特流依次代替模板中的x，得到：11110000 10100000 10110000 10110000，即 F0 A0 B0 B0。

　　UTF-16

　　UTF-16编码以 16 位无符号整数为单位。我们把 Unicode 编码记作U。编码规则如下：如果U<0×10000，U的 UTF-16编码就是U对应的 16 位无符号整数（为书写简便，下文将 16 位无符号整数记作 WORD）。中文范围 4E00-9FBF，所以在 UTF-16编码里中文 2 个字节编码。如果U≥0×10000，我们先计算U’=U-0×10000，然后将U’写成二进制形式：yyyy yyyy yyxx xxxx xxxx，U的 UTF-16编码（二进制）就是：110110yyyyyyyyyy 110111xxxxxxxxxx。

　　UTF-32

　　UTF-32编码以 32 位无符号整数为单位。Unicode 的 UTF-32编码就是其对应的 32 位无符号整数。

　　字节序

　　根据字节序(对字节序不太了解的同学请参考 http://en.wikipedia.org/wiki/Endianness)的不同，UTF-16可以被实现为 UTF-16LE（Little Endian）或 UTF-16BE（Big Endian），UTF-32可以被实现为 UTF-32LE 或 UTF-32BE。例如：　　

Unicode 编码	UTF-16LE	UTF-16BE	UTF-32LE	UTF-32BE
0x006C49	49 6C	6C 49	49 6C 00 00	00 00 6C 49
0x020C30	43 D8 30 DC	D8 43 DC 30	30 0C 02 00	00 02 0C 30

　　那么，怎么判断字节流的字节序呢？Unicode 标准建议用 BOM（Byte Order Mark）来区分字节序，即在传输字节流前，先传输被作为 BOM 的字符”零宽无中断空格”。这个字符的编码是 FEFF，而反过来的 FFFE（UTF-16）和 FFFE0000（UTF-32）在 Unicode 中都是未定义的码位，不应该出现在实际传输中。下表是各种 UTF 编码的 BOM：　　

UTF 编码	Byte Order Mark
UTF-8	EF BB BF
UTF-16LE	FF FE
UTF-16BE	FE FF
UTF-32LE	FF FE 00 00
UTF-32BE	00 00 FE FF

　　总结一下，ISO 与 unicode.org 都敏锐的意识到只有为世界上每种语言中的每个字符设定统一并且唯一的二进制编码才能彻底解决计算机世界信息交流中编码冲突的问题。由此诞生了 UCS 和 Unicode，而这两个规范是一致的。在 Unicode 里，所有的字符被一视同仁，也就是说，所有的文字都按一个字符来处理，它们都有一个唯一的 Unicode 码。UTF-8、UTF-16、UTF-32分别定义了怎样将 Unicode 定义的数字转换成程序数据。UTF-8以字节为单位对 Unicode 进行编码，一个英文字符占 1 个字节，汉字占 3 个字节；UTF-16以 16 位无符号整数为单位对 Unicode 进行编码，中文英文都占 2 个字节；UTF-32以 32 位无符号整数为单位对 Unicode 进行编码，中文英文都占 4 个字节。可以在 http://www.unicode.org/charts/unihan.html 查看汉字的 unicode 码以及 UTF-8、UTF-16、UTF-32编码。

　　中文二进制存储

　　介绍了这么多的编码知识，真正的文件内容是什么样子的呢？下面我们就通过实验看看在笔者 Linux 机器上 “中文”这两个字在不同的编码下保存的文件内容。下面是我的实验过程，有兴趣的同学可以在自己的机器上重做一下。Window 平台上的情况类似这里就不赘述了。

　　实验需要需要使用 2 个工具：

1. od 查看文件内容：http://www.gnu.org/software/coreutils/manual/html_node/od-invocation.html
2. iconv 编码转换工具：http://www.gnu.org/software/libiconv/

汉字	Unicode（ucs-2）10进制表示	Utf-8	Utf-16	Utf32	区位码	GB2312/GBK/GB18030
中	20013	E4 B8 AD	4E2D	00004E2D	5448	D6D0
文	25991	E6 96 87	6587	00006587	4636	CEC4

　　机器环境：

　　OS: Red Hat Enterprise Linux AS release 4

　　CPU: Intel (R) Xeon (R) CPU

　　Locale：LC_ALL=zh_CN.utf-8

//生成 utf8 编码下的文件

echo –n "中文" > foo.utf8

 

//检查 foo 的内容：

od -t x1 foo.utf8

0000000 e4 b8 ad e6 96 87

 

//转换为 utf16 编码

iconv -f utf-8 -t utf-16 foo.utf8 > foo.utf16

 

//查看 foo.utf16 内容

od -t x1 foo.utf16

0000000 ff fe 2d 4e 87 65

Ff fe 是 BOM（还记得吗？通过 BOM 来字节流的字节序），其余部分的确是 UTF-16LE 编码的内容

 

//转换为 utf32 编码

iconv -f utf-16 -t utf-32 foo.utf16 > foo.utf32

 

//查看 foo.utf32 内容

od -t x1 foo.utf32

0000000 ff fe 00 00 2d 4e 00 00 87 65 00 00

Ff fe 是 BOM，的确是 UTF-32LE 编码的内容

 

//转换为 gb2312 编码

iconv -f utf-8 -t gb2312 foo.txt > foo.gb2312

od -t x1 foo.gb2312

0000000 d6 d0 ce c4

 

//转换为 GBK 编码

iconv -f utf-8 -t gbk foo.txt > foo.gbk

od -t x1 foo.gbk

0000000 d6 d0 ce c4

 

//转换为 GB18030 编码

iconv -f utf-8 -t gb18030 foo.txt > foo.gb18030

od -t x1 foo.gb18030

0000000 d6 d0 ce c4 

　　C语言中文处理

　　先明确一个概念：程序内部编码和程序外部编码。程序内部编码指的是中文字符在程序运行时在内存中的编码形式。程序外部编码则是中文字符在存储或者传输时的编码形式。程序外部编码的最直观的例子就是当把中文存储到硬盘文件中时选择的编码。

　　根据程序内部编码和程序外部编码是否一致，C/C++的中文处理有两种常见的方式：

1. 内外编码相同。输入输出时不需要考虑编码转换，程序内部处理时把中文字符当做普通的 2 进制数据流进行处理。
2. 内外编码不同。输入输出的时候根据应用需要选择合适的编码格式进行编码转换；程序内部统一编码处理。

　　方法 1 的优点不言而喻，由于内外统一，不需要进行转换。不足是如果不是C标准库支持的编码方式，那么字符串处理函数需要自己实现。比如说标准 strlen 函数不能计算中文编码&UTF-8等的字符串长度，而需要根据编码标准自行实现。GBK 等中文编码除了计算字符串长度的函数外，字符串匹配函数也要自己实现（原因看上文中文编码总结）。当需要支持的编码格式不断增多时，处理函数的开发和维护就需要付出更大的代价。

　　方法 2 针对方法 1 的不足加以改进。在程序内部可以优先选择C标准库支持的编码方式，或者根据需要自己实现对某一特定编码格式的完整支持，这样任何编码都可以先转换为支持的编码，代码通用性比较好。

　　那么C标准库对中文编码的支持如何呢？目前 Linux 平台一般使用 GNU C library，内建了对单字节的 char 和宽字符 wchar_t的支持。Char 大家都很熟悉了，处理中文需要的 wchar_t要重点介绍一下。从实现上来说在 Linux 平台上可以认为 wchar_t是 4byte 的 int，内部存储字符的 UTF32 编码。由于标准库已经内建了对 wchar_t比较完备的支持，如使用 wcslen 计算字符串长度，使用 wcscmp 进行字符串比较等等。所以比较简单的方式是使用上面的方法2，同时选择 wchar_t作为内部字符的表示。做到这一点还是比较容易的，在输入输出的时候通过 mbrtowc/wcrtomb 进行单个字符的内外编码转换，以及通过 mbsrtowcs/wcsrtombs 进行字符串的内外编码转换即可。这里需要注意两点：

1. 代码中字符串常量的表示不同。举例说明：Char c=’a’; Wchar_t wc=L’中’;
2. 上面两组函数的转换是依赖 locale 设置的，即 locale 决定了外部编码的类型。确切的说是 LC_CTYPE 决定了外部编码的类型。默认情况下程序启动时使用标准“C”locale，而不是 LC 系列的环境变量指定的。所以需要首先调用下面的函数：setlocale (LC_ALL, “”);这样程序就使用了用户通过设置 LC 系列环境变量选择的 Locale。

　　关于 locale 的话题比较大，这里就不深入了，留待下一篇文章吧.

　　上面的方法很完美，是吗？不是吗？得到这么多的好处不是无代价的，最明显的代价就是内存，任何一个字符，不管中文还是英文如果保持在 wchar_t里就需要 4 个 byte，就这一个理由就足以限制了这个方案在关注内存使用的应用场景下的使用。

　　Python 的中文处理

　　对 Python 来说由于内建 Unicode 的支持，所以采用输入输出的时候进行转换，内部保持 Unicode 的方式使用是个不错的方案。http://docs.python.org/tutorial/introduction.html#unicode-strings 这里作为起点，有兴趣的同学自学吧。

　　编码选择建议：

1. 只有英文：毫不犹豫选择内外编码都选择 ASCII，通用且存储代价小。
2. 主要存中文，对存储大小比较敏感：内外部编码根据文字使用范围选择 GB2312 或者 GBK，自行实现使用到的字符串处理函数。
3. 通用性第一，处理简单：外部选择 UTF-8，内部可以使用 UTF-8或者 UTF-32（即 wchar_t）

　　参考资料：

　　http://baike.baidu.com/view/25492.htm

　　http://baike.baidu.com/view/25421.htm

　　http://baike.baidu.com/view/40801.htm

　　http://www.sac.gov.cn/SACSearch/search?channelid=160591&templet=gjcxjg_detail.jsp&searchword=STANDARD_CODE=’GB%202312-1980′&XZ=Q

　　http://www.sac.gov.cn/SACSearch/search?channelid=160591&templet=gjcxjg_detail.jsp&searchword=STANDARD_CODE=’GB%2018030-2005′&XZ=Q

　　http://www.sac.gov.cn/SACSearch/search?channelid=160591&templet=gjcxjg_detail.jsp&searchword=STANDARD_CODE=’GB%2013000-2010′&XZ=Q

　　http://www.unicode.org/

　　http://www.ibm.com/developerworks/cn/linux/i18n/unicode/linuni/

　　http://www.gnu.org/software/libc/manual/html_node/index.html

　　http://www.gnu.org/software/libiconv/

 

reference：

http://www.fmddlmyy.cn/text7.html

 http://www.cnblogs.com/MichaelOwen/articles/2128771.html