DinS Written on 2017/4/24

如果看完介绍《字符集简史》，你感觉自己已经明白了字符集问题，那我只能说：
这个问题比你想象的要复杂。

让我们尝试一下读取文本文件，最最常见的一个操作。

同样的txt，内容看上去一样，但编码可以不同，读出来的内容就不同。文本文件的编码方式，即用何种字符集表示本身就是一个问题。如果处理不好，读出来很可能是乱码。
为了具体说明，下面使用notepad++演示。

notepad++里有一个编码选项。默认是UTF-8不带BOM，这里也能够看到ANSI的身影，即windows默认编码方式。

现在需要解释一下ANSI是什么。首先肯定不是unicode，但是并不能简单地理解为多字符集，比如你可以把不同语言存到一个txt中，并用ANSI编码。
首先选中Encode in ANSI，然后输入内容，保存。之后把相同内容用UTF-8再保存一遍。用记事本打开的话ANSI和UTF8都能够正确显示。

用notepad++打开的话，只有UTF-8能够正确显示。

区别在哪里？
在解释之前，我们进入控制面板的区域设置，把当前系统的中文设置为俄文，重启，再看看这两个文本文件的内容。

文件没有动过，也就是说其二进制是一样的，但是我们看到的内容却有区别

以ANSI编码方式存储的txt变成了乱码，以UTF-8方式存储的txt依然正常，这正是unicode要达到的目标。

有了这两个例子，就可以解释ANSI了。ANSI是一种可变的编码方式，其具体的方式跟操作系统的区域设置有关。比如在大陆地区都是简体中文操作系统，那么ANSI就是GB2312，如果在台湾，ANSI就是BIG5，如果是俄罗斯，那么就是另一种编码方式。

之前以ANSI方式存储的实际是GB2312编码方式，将区域改成俄语后，同样的ANSI编码方式变化了，自然看到的内容就是乱码。而UTF-8因为属于unicode，就不受区域设置的影响。

如此说来，notepad++的表现倒是正常的，多种语言混合在一起用多字节存储肯定不行。但是如果将ANSI简单等同于多字节，正如上例所示，不同国家的语言可以同时存在于一个txt中，用记事本可以正常打开。这其中肯定发生了一些操作。有可能是操作系统替我们做了一些工作，或者是记事本本身执行了一些操作。

饶了这么一大圈，我实际要说的是，所有的记事本的默认编码方式都是ANSI，也就是说我们从程序中读取的源文件txt，都是以ANSI方式编码的。如果改成unicode会发生什么情况？宽、窄字符方式读取会有什么区别？
接下来让我们做几个试验看看。

写代码分别一行一行读入两个文本文件，一种读取方式是窄字符(char / string)，另一种方式是宽字符(wchar_t / wstring)。结果如下，左边是ANSI方式，右边是Unicode方式。

跟你想的应该有出入，依次来分析。
首先，不管是用窄字符还是宽字符，读取ANSI编码的txt都是成功了，只不过一个读出来是窄字符，另一个是宽字符。这个应该符合预期，至少可以理解
其次，不管是用窄字符还是宽字符，读取UTF8编码的txt都失败了。
再次，仔细研究宽字符的读取，好像还不是完全失败，记得文本中第二行是中文，貌似读取出了一些内容。

进一步研究，如果我们此时打开nodepad++，把utf-8编码的文件改成ANSI，会看到这样

神奇的事情发生了，这里的乱码跟调试的乱码一样！

如何解释呢？从目前的现象可以看出，二进制确实是读进去了，只不过解释的方式出了问题。
下面开始深入分析。首先需要了解string和wstring到底是什么。

所谓string和wstring，本质是模板，区别就是string里面装的是char，wstring里装的是wchar_t。这个wchar_t是C++标准库里规定的，然而遗憾的是标准库只规定了接口，并没有说明wchar_t具体如何实现，这样造成了一个恶果：在windows下wchar_t占两个byte，即16比特位；在Linux下是32位。也就是说同样的代码，平台不同结果是不同的。（当然好消息是在c++最新标准下有了挽救措施，之后再讲）

现在研究研究UTF-8。这个编码方式虽然是unicode，但是却是可变长的。
对于中文，一般而言占3个byte。具体而言，“你”在utf-8的编码方式下对应的是E4BDA0（十六进制）。

读到这里应该就发现问题了。
我们存储的txt是以utf-8方式编码的，也就是说中文占3byte。
然而我们在程序中使用的是wstring，这个在windows下一个字符只有2byte，
也就是说我们一次读入了“你”的前两个byte，即E4BD。
这个E4BD是什么呢？还记得刚才的乱码吗？第一个字是什么？
写一个小程序测试一下