中文编码杂谈

编码问题的例子

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

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

为什么写这篇文章

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

对编码问题的理解我认为分为三个层次，第一个层次：概念，知道各个编码标准的应用场景，了解之间的差异，能分析和解决常见的一些编码问题。第二个层次：标准，掌握编码的细节，如编码范围，编码转换规则，知道这些就能自行开发编码转换工具。第三个层次，使用，了解中文的编码 2 进制存储，在程序开发过程中选择合理的编码并处理中文。为了避免让读者陷入编码标准的黑洞无法脱身（不相信？看看 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），得到对应的国标交换码，简称国标码，交换码，因此，“学”字的国标交换码计算为：

1

2

3

4

00110001 00000111

+ 00100000 00100000

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

01010001 00100111

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

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

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

1

2

3

4

  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 是两个不同的组织, 虽然最初制定了不同的标准; 但目标是一致的。所以自从unicode2.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，而编码的程序数据是：

1

2

3

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

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

DWORD data_utf32[] = {0x6c49, 0x5b57}; // 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 – 00007F0xxxxxxx000080 – 0007FF110xxxxx 10xxxxxx000800 – 00FFFF1110xxxx 10xxxxxx 10xxxxxx010000 – 10FFFF11110xxx 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 110001 00 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-16LEUTF-16BEUTF-32LEUTF-32BE0x006C4949 6C6C 4949 6C 00 0000 00 6C 490x020C3043 D8 30 DCD8 43 DC 3030 0C 02 0000 02 0C 30

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

UTF编码Byte Order MarkUTF-8EF BB BFUTF-16LEFF FEUTF-16BEFE FFUTF-32LEFF FE 00 00UTF-32BE00 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-8Utf-16Utf32区位码GB2312/GBK/GB18030中20013E4 B8 AD4E2D00004E2D5448D6D0文25991E6 96 876587000065874636CEC4

机器环境：
os: Red Hat Enterprise Linux AS release 4
Cpu: Intel(R) Xeon(R) CPU
locale：LC_ALL=zh_CN.utf-8

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

//生成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 来说由于内建 unicde 的支持，所以采用输入输出的时候进行转换，内部保持 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/

本文转自 http://www.searchtb.com/2012/04/chinese_encode.html