以下内容来自腾讯元宝。

 wchar_t在 C++ 中的发展历史。它的故事是一段关于早期国际化尝试、平台分裂以及最终被更现代的标准所取代的历程。

wchar_t的发展历史时间线

. 起源：C 语言的国际化尝试 (C89/C90)

wchar_t最初并非诞生于 C++，而是源于 C 语言标准化的需要。

• •

  ​​时间点​​：1989-1990 (ANSI C89 / ISO C90)

• •

  ​​背景​​：在 Unicode 尚未成熟和普及之前，世界各地使用着多种不同的字符编码（如中国的 GB2312，日本的 JIS，欧洲的 ISO-8859 系列）。C 语言需要一种机制来处理这些“宽字符集”。

• •

  ​​定义​​：在 C90 标准的 <stddef.h>头文件中，wchar_t被定义为一个 ​​typedef别名​​，其底层具体是哪种整数类型（int, unsigned short, long等）由实现（编译器/平台）决定。

  // 在 C 中，它看起来像这样（具体类型由编译器决定）
  typedef unsigned short wchar_t; /* 可能是这种 */
  typedef int wchar_t;            /* 也可能是另一种 */

• •

  ​​设计目的​​：提供一个足够大的整数类型，能够表示编译器支持的所有本地化设置（locales）中“最大的扩展字符集”中的任何一个字符。​​关键在于，标准没有规定它的尺寸、编码和符号性​​，这为后来的平台分裂埋下了伏笔。

---

2. 采纳与强化：C++98

当 C++ 进行标准化时，它采纳了 C 语言的这个特性，但进行了加强。

• •

  ​​时间点​​：1998 (ISO/IEC 14882:1998, 即 C++98)

• •

  ​​关键变化​​：C++ 将 wchar_t从一个简单的 typedef提升为​​一个独立的基本类型（fundamental type）和关键字​​。这意味着：

  • •

    它在类型系统中具有唯一性（wchar_t和 int是不同的类型）。

  • •

    它支持重载解析（你可以重载一个接受 wchar_t的函数）。

  • •

    它不需要包含任何头文件即可使用。

• •

  ​​新增支持​​：C++ 标准库引入了配套的宽字符工具，如 std::wstring（basic_string<wchar_t>），std::wcout，std::wcin，以及 <cwchar>和 <cwctype>等头文件，形成了一个完整的宽字符处理体系。

---

3. 平台大分裂时代

尽管标准完成了，但由于标准本身没有严格规定 wchar_t的细节，各大操作系统和编译器厂商基于历史和技术选择，做出了不同的实现，导致了著名的 ​​“平台大分裂”​​。

• •

  ​​Microsoft Windows​​：

  • •

    ​​选择​​：wchar_t被定义为 ​​unsigned short​​，占 ​​16 位（2 字节）​​。

  • •

    ​​编码​​：采用 ​​UTF-16LE​​ 编码。

  • •

    ​​原因​​：Windows NT 系统在设计时，Unicode 还处于 UCS-2 阶段（所有字符都是 16 位）。后来 Unicode 字符数量超过 65536 个，UCS-2 进化成了 UTF-16（使用代理对 Surrogate Pairs 来表示辅助平面字符），Windows 也随之跟进。整个 Windows API 都基于宽字符（如 CreateWindowW, MessageBoxW）。

• •

  ​​Unix/Linux (及 macOS)​​：

  • •

    ​​选择​​：wchar_t通常被定义为 ​​int​​，占 ​​32 位（4 字节）​​。

  • •

    ​​编码​​：采用 ​​UTF-32​​ 编码。

  • •

    ​​原因​​：固定长度的编码处理起来更简单，每个 Unicode 码点（Code Point）都直接对应一个 wchar_t值，无需处理复杂的代理对。Unix 哲学更倾向于这种“一个字符就是一个整数”的简洁模型。

​​这个分裂带来了巨大的可移植性问题​​：同一份代码，在 Windows 上编译后，sizeof(wchar_t)是 2，而在 Linux 上则是 4。处理文本的算法和存储方式都需要改变。

---

4. 问题暴露与反思

• •

  ​​UTF-16 的复杂性​​：Windows 的 16 位 wchar_t无法直接表示所有 Unicode 字符，需要处理令人头疼的“代理对”（Surrogate Pairs），这大大增加了字符串操作的复杂度。

• •

  ​​UTF-32 的低效性​​：Unix 的 32 位 wchar_t虽然处理简单，但对于存储和传输英文或 ASCII 文本来说，​​极其浪费内存和带宽​​。

• •

  ​​编码不明确​​：wchar_t的编码是“实现定义的”，代码无法从类型本身获知其编码是 UTF-16 还是 UTF-32，必须编写平台相关的代码。

• •

  ​​UTF-8 的崛起​​：随着 Web 的发展，​​UTF-8​​ 成为了事实上的标准。它兼容 ASCII，节省空间，并且没有字节序（Endianness）问题。许多 Unix 系统开始倾向于在内部使用 UTF-8 而不是 wchar_t。

---

5. 现代化：C++11 及以后

为了解决 wchar_t的混乱局面，C++11 引入了新的、定义明确的字符类型。

• •

  ​​时间点​​：2011 (C++11)

• •

  ​​新类型​​：

  • •

    ​​char16_t​​：​​明确​​表示 ​​UTF-16​​ 编码。底层是 uint_least16_t（无符号）。

  • •

    ​​char32_t​​：​​明确​​表示 ​​UTF-32​​ 编码。底层是 uint_least32_t（无符号）。

  • •

    相应的，标准库也引入了 std::u16string和 std::u32string。

• •

  ​​字面量前缀​​：引入了 u和 U前缀来表示新类型的字符串字面量。

  const char*     utf8_str  = u8"UTF-8 String"; // C++11 引入了 u8 前缀
  const char16_t* utf16_str = u"UTF-16 String";
  const char32_t* utf32_str = U"UTF-32 String";
  const wchar_t*  wide_str  = L"Implementation-defined Wide String";

• •

  ​​wchar_t的新定位​​：自此，wchar_t的角色被重新定义为“用于本地化环境的宽字符表示”，而 char16_t/char32_t则专门用于 ​​Unicode​​ 的明确编码。​​在新代码中，应优先使用 char16_t和 char32_t​​。

​​C++17​​ 进一步弃用了用于字符编码转换的 <codecvt>头文件，因其接口难以正确使用。

​​C++20​​ 引入了 char8_t类型（u8"string"现在是 const char8_t*类型），进一步强化了对 UTF-8 的一等公民支持。

---

总结与现状

时期	角色与状态
​​C90​​	诞生期，为解决多字节编码而生，定义为 typedef，细节实现定义。
​​C++98​​	鼎盛期，成为关键字和基本类型，拥有完整的标准库支持。
​​2000s​​	分裂期，Windows（16位/UTF-16）和 Unix（32位/UTF-32）实现分裂，可移植性差。
​​C++11​​	衰落期，被更明确、可移植的 char16_t和 char32_t取代。
​​现代C++​​	​​遗留期​​。​​主要价值在于与旧平台API（特别是Windows API）的兼容​​。在新项目中，处理 Unicode 的推荐做法是：

​​现代最佳实践：​​

1. 1.

   ​​内部存储与交换​​：使用 std::string并以 ​​UTF-8​​ 编码。

2. 2.

   ​​需要明确宽字符时​​：优先使用 char16_t(UTF-16) 或 char32_t(UTF-32)。

3. 3.

   ​​与操作系统交互时​​：在 Windows 上，必要时与 wchar_tAPI 进行转换；在 Linux/macOS 上，通常直接使用 UTF-8。

wchar_t的历史是一个典型的“技术债务”案例：一个早期为解决复杂问题而设计的良好意图，由于标准不够严格和技术的演进，最终导致了分裂和混乱，并被更优的解决方案所取代。