尽管第三方库支持的假设，C++事实上没有真正有效地支持unicode。即使utf8。（注意：本文讨论了在内存中的字符串编码方案，络数据流。）
STL的string模板诞生时，unicode还是理想中的固定16位编码。那时。Windows、Java等先后跨跃进unicode时代，而Unix/Linux受限于向后兼容而难以改变。那时Windows上的C++编程主要用用Win32 API，还不流行STL。而Unix/Linux上还基本不支持Unicode。STL的wstring，仅仅是将char模板參数替换成wchar_t，看起来似乎全然合理，事实上并没有经过实践检验。所以，Windows上的wstring至今一直处于实际上不可用的状态，各种IO时的编码转换都有问题。而Linux上的wchar_t是32位，太浪费内存所以全然不值得使用。（最新的标准针对unicode引入了char16_t和char32_t，以及u16string和u32string。
）
为什么Linux上的wchar_t是32位呢？由于gcc開始支持宽字符的时候，大约也是unicode的字符集突破16位编码极限的时候。
本来预期很充足的码位，出乎意料的不够了。unicode不得不做出调整。调整后，有了三种可选的unicode编码：
utf32：一个码位固定4字节，一个码位表示一个字符编码。
utf16：兼容之前的16位编码，一个码位2字节，但1或2个码位表示一个字符编码。
utf8：兼容ASCII编码，一个码位1字节，但1到6个码位表示一个字符编码。（现行标准事实上要求最多4个码位。但出于保障兼容性的原因，5、6个码位的情况是可能出现的，即使这算无效编码。）
（除此之外，还有字符组合和修饰符组合的情况。使得码位到字符的映射更加复杂。在此忽略。
）
utf8的出现，让Linux系统发现了新的机会。既然兼容ASCII，那么仅仅要系统的编码页新加一个utf8的，不就支持unicode了么。
非常自然的，Linux就走了这条路。
而Windows却不支持utf8的编码页。这让非常多写跨平台程序的人对微软非常是不满。而后，更有人宣称。Windows、Java、.NET等选错了unicode编码，utf8才是王道。
我非常希望字符编码有个完美的解决方式，但非常可惜，每当我们试图让它变得简单，它就变得更加复杂。最主要的问题：一个utf8编码的char数组。仅仅只是是一个字节buffer，在C/C++的标准库支持下，你根本无法把它当字符串来处理。
想要字符串长度？它仅仅能给你字节数，而不是字符数。
想要取第n个字符？它仅仅能给你第n个字节。想要把一个字符转大写？想推断一个字符是否是字母？它仅仅接受char类型的字符，也就是说仅仅支持ASCII字符……
即使说对一个不须要操作字符的程序，在C/C++程序里我们总是要为输入分配buffer的，那么预期输入n个字符的buffer。应该分配多少字节呢？没错，你仅仅能按最大可能n*6+1来分配。对内存暂时分配还好。要是一个数据库字段，你怎么办？这时即使是utf32都可能更省存储空间。
当然，绝大多数问题都能够通过使用一个第三方的unicode库来解决。假设认为专门的unicode库太heavy，至少还有boost的日常解决方式。仅仅要把全部字符串操作替换成专门的函数……（假设安全性对你的程序非常重要。你还要了解所用函数在遇到无效编码时的行为。由于这也是黑客突破安全检查的一种手段。）
可是，大多数的程序猿甚至并不清楚unicode编码。更不可能了解编码转换的复杂性，他们或者习惯了C风格的字节操作，或者来自Java等使用双字节unicode的语言。做着并不是字处理的软件，所以对学习复杂的unicode编码系统并无太大兴趣。所以，utf8在C/C++里，更象是专家级的解决方式，而并不是面向普通开发人员。理想情况下，C++能够凭借其强大的抽象和封装能力，包装出一个真正基于字符訪问的字符串类（Python3走了这条路。但有非常多批评的声音），然而现实中则非常难将其标准化。
那么Windows、Java、.NET、iOS等所使用的utf16呢？本质上，他们的支持都是有缺陷的。
由于他们開始时支持的事实上是utf16的前身UCS2，每一个字符固定2字节。而当utf16出现后。就权当UCS2用，也就是说双码位4字节的字符（unicode里称作BMP以外的字符）会被当作两个字符处理。
假设你的程序真的想要正确支持双码位的字符，就要改敲代码，使用高级字符串函数来訪问字符串，而不是直接用下标索引。仅仅是由于BMP以外的字符极其罕用，其程序猿并我们并不需要了解这些细节。
从正确性的透视，这不是。但一个有用的观点，非常有用。
版权声明：本文博客原创文章，博客，未经同意，不得转载。