在代码中调用“编码转换方法”一节里提到的函数，将 gb2312 编码的字符串转换为 UTF8 编码，分析其编码转换的行为：
在英文 Linux 环境下，执行下列命令：
1
| export LC_ALL=zh_CN.gb2312
|
然后编译并执行以下程序（其中汉字都是在 gb2312 环境中写入源文件）
1
2
3
4
| L1: wstring ws = L"一";
L2: string s_gb2312 = "一";
L3: wchar_t * wcs = MBs2WChar(s_gb2312.c_str());
L4: char* cs = WChar2MBs(wcs);
|
查看输出：
- L1 - 1 wide char： 0x04bb
- L2 - 2 bytes：0xd2，0xbb，即 gb2312 编码 0xD2BB
- L3 - 返回的 wchar_t 数组内容为 0x4E00，也就是 Unicode 编码
- L4 - 将 Unicode 再度转换为 UTF8 编码，输出的字符长度为 3，即 0xE4，oxB8，0x80
在 L1 行，执行结果显示编码为一个 0x04bb，其实这是一个转换错误，如果使用其他汉字，如“哈”，编译都将无法通过。也就是说 Linux 环境下，直接声明中文宽字符串是不正确的，编译器不能够正确转换。
而在中文 windows 下使用相同测试代码，则会在 L1 处出现区别，ws 中的 wchar_t 元素十六进制值是 0x4e00，这是汉字“一”的 Unicode 编码。
处理编码问题的经验总结首先，这里先简单说明一下 Unicode 和 UTF8 的关系：Unicode 的实现方式和它的编码方式并不相同，UTF8 就是其实现之一。比方使用 UltraEdit 打开 UTF8 编码的中文文件，使用 16 进制查看，可以发现看到的中文对应部分应当是 Unicode 编码，每个中文字长度 2 字节—— UltraEdit 在这里已经做了转化；如果直接查看其二进制文件，可以发现是 3 字节。但两者的差别仅在于 Unicode 向 UTF8 做了数学上的转化。（更多关于 Unicode 和 UTF8 的概念，可以参见 ）
其次，关于第三方库的选择，应当综合考虑项目的需求。一般的文本字符转换，系统的库函数已经可以满足需求，实现也很简单；如果需要针对不同地区的语言、文字、习惯进行编程，需要更为丰富的功能，当然选择成熟的第三方工具可以事半功倍。
最后，从逻辑上保持字符串的编码正确，需要注意几条一般规律：
- 编码选择：多国语言环境的编程，以使用 UTF 编码为原则，减少字符集转换。
- string 并不包含编码信息，但是编码确定了 string 的二进制内容。
- 读写一致：读入时使用的字符集要与写出时使用的一致。如果不需要改变字符串内容，仅仅是将字符串读入、再写出，建议不要调整任何字符集——即使程序使用的系统默认字符集 A 与文件的实际编码 B 不符合，写出的字符串依然会是正确的 B 编码。
- 读入已知：对于必须处理、解析或显示的字符串，从文件读入时必须知道它的编码，避免处理字符串的代码简单使用系统默认字符集；即便对于程序从系统中收集到的内存字符串，也应知道其符合的编码格式——一般为系统默认字符集。
- 避免直接使用 Unicode：这里是说将非 ASCII 编码的 16 进制或者 10 进制数值用 &# 与 ; 包含起来的使用方式，例如将中文“一”写成“e00;”。这种方法的实质是 Unicode 编码直接写入文件。这不仅会降低代码的通用性、输出文件的可读性，处理起来也很困难。比如法文字符在其他字符集中是大于 80H 的单字节字符，程序同时要支持中文的时候，很有可能会将多字节的中文字符错误割裂。
- 避免陷入直接的字符集编程：国际化、本地化的工具已经比较成熟，非纯粹做编码转换的程序员没有必要自己去处理不同编码表的映射转换问题。
- Unicode/UTF8 并不能解决一切乱码问题：Unicode 可以说是将世界语言统一起来的一套编码。但是这并不意味着在一个系统中可以正常显示的按照 UTF8 编码的文件，在另一个系统中也可以正常显示。例如，在中文的 UTF8 编码或者 Unicode 编码在没有东亚语言包支持的法文系统中，依然是不可识别的乱码——尽管 UTF8、Unicode 它们都支持。
|
