1.5、char16_t/char32_t（Unicode字符类型）

为什么不直接用char或wchar_t？

• • char类型只占1字节，最多只能表示256个字符，根本无法覆盖Unicode的庞大字符集。
• • wchar_t虽然是“宽字符”，但其大小在不同平台上并不统一。在Windows上通常是16位（UTF-16），在Linux上则常为32位（UTF-32），这给跨平台开发带来了巨大的困扰，容易导致编码混乱和数据损坏。
• • char16_t和char32_t的引入，就是要让Unicode字符类型的大小和语义一锤定音，避免历史遗留问题反复出现。

代码对比：C++11前后的用法

老语法（C++98/03）：

wchar_t wch = L'你';
std::wstring ws = L"你好，世界";

问题：wchar_t的大小和编码依赖平台，写的代码在不同系统下表现不一致，难以保证数据的正确性和移植性。

新语法（C++11）：

char16_t ch16 = u'你';        // UTF-16单字符
char32_t ch32 = U'你';        // UTF-32单字符
std::u16string s16 = u"你好，世界"; // UTF-16字符串
std::u32string s32 = U"你好，世界"; // UTF-32字符串

优势：char16_t和char32_t的大小和编码在所有平台上都一致，语义明确，写出来的代码“走到哪都不怕”。

设计哲学：标准化与明确性

C++11引入char16_t和char32_t，核心理念是“标准化和明确性”。过去wchar_t的混乱局面，源于“宽字符”标准不一，导致跨平台开发困难重重。新类型的设计，直接规定了字节数和用途，消除了歧义，让开发者在处理Unicode时有了清晰的预期和可靠的工具。

实际项目中的优缺点

优点：

• • 跨平台一致性强，彻底解决wchar_t的历史遗留问题。
• • 与现代编码标准（如UTF-16、UTF-32）无缝对接，便于与其他语言和系统集成。
• • 语义明确，类型安全，避免了类型混淆带来的隐患。

缺点：

• • C++标准库对char16_t/char32_t的直接支持还不够完善，很多标准库算法和流操作不直接支持，需要手动转换或使用第三方库。
• • UTF-16存在代理对（surrogate pair）问题，处理非BMP字符时仍需额外注意。
• • 类型转换和编码转换相对繁琐，初学者容易踩坑。

常见误区与错误后果

• • 误用类型转换：直接把wchar_t强转为char16_t或char32_t*，会导致未定义行为，数据损坏，甚至程序崩溃。
• • 忽略编码转换：以为有了char16_t/char32_t就能自动处理所有Unicode字符，实际还需正确进行编码转换，否则会出现乱码或丢失字符。
• • 滥用char16_t/char32_t：在只需处理ASCII或简单多字节字符集的场景下，盲目使用新类型反而增加复杂度和性能负担。

类型标准化是C++国际化的基石，但生态完善还需时间

C++11的char16_t和char32_t是Unicode支持道路上的里程碑，它们让C++在多语言环境下有了坚实的类型基础。但开发者不能指望它们一劳永逸地解决所有Unicode问题，编码转换、库支持、生态完善仍是后续需要关注的重点。我的建议是：在需要精确Unicode支持时果断采用新类型，但要结合实际项目需求，合理选择编码和工具链，切忌盲目跟风。

本文首发于【讳疾忌医-note】公众号，未经授权，不得转载。
（加入我的知识星球，免费获取账号，解锁所有文章。）