首页 > 代码库 > C++并不支持Unicode，即使是utf8
C++并不支持Unicode，即使是utf8
时至今日，字符串使用unicode已经是不需要理由的常识，但对一些有着悠久历史的编程语言来说，这仍然是个头痛的问题。如果抛开第三方库的支持，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以外的字符极其罕用，其程序员并不急需了解这些细节。从正确性角度来说，这并不正确，但从实用角度来说，还算实用。
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以外的字符极其罕用，其程序员并不急需了解这些细节。从正确性角度来说，这并不正确，但从实用角度来说，还算实用。
C++并不支持Unicode，即使是utf8
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。