在 I/O 中使用 char16_t 和 char32_t答案

【问题标题】：Using char16_t and char32_t in I/O在 I/O 中使用 char16_t 和 char32_t
【发布时间】：2011-12-31 10:11:33
【问题描述】：

C++11 引入了 char16_t 和 char32_t 以方便处理 UTF-16 和 UTF-32 编码的文本字符串。但是<iostream> 库仍然只支持实现定义的wchar_t 用于多字节I/O。

为什么没有将char16_t 和char32_t 的支持添加到<iostream> 库以补充wchar_t 支持？

【问题讨论】：

你试过std::basic_iostream<char32_t>吗？仅仅因为没有预定义类型（例如 std::iostream 用于 char）并不意味着没有支持。
我刚刚在 GCC 版本 4.7.0 中测试了 basic_istringstream<char16_t>。它编译，但在执行过程中崩溃。当然，这并不能证明支持可能存在于另一个环境中，但我仍然觉得奇怪的是标准化委员会没有包括与 wchar_t 平等的支持。
我的意思是，“……并没有反驳……”。
basic_istringstream 和应该可以正常工作。如果它不在 GCC 中，那么这只是一个错误，或者他们还没有解决这个问题。
@bames53 ：除了char 和wchar_t 之外，该标准不需要支持——所有其他字符类型都是严格实现定义的，因此不支持它们不一定是“错误” .

标签： c++ c++11 iostream char16-t char32-t

【解决方案1】：

在提案Minimal Unicode support for the standard library (revision 2) 中指出，只有图书馆工作组支持支持字符串和编解码器方面的新字符类型。显然大多数人反对支持 iostream、fstream、codecvt 和正则表达式以外的方面。

根据Portland meeting in 2006 的记录，“LWG 致力于全面支持 Unicode，但不打算使用现有图书馆设施的 Unicode 字符变体复制图书馆。”我还没有找到任何细节，但是我猜委员会认为当前的库接口不适合 Unicode。一种可能的抱怨可能是它在设计时考虑了固定大小的字符，但 Unicode 完全过时了，因为虽然 Unicode 数据可以使用固定大小的代码点，但它不会将字符限制为单个代码点。

我个人认为没有理由不对各种平台上已经提供的最小支持进行标准化（Windows 对 wchar_t 使用 UTF-16，大多数 Unix 平台使用 UTF-32）。更高级的 Unicode 支持将需要新的库设施，但在 iostream 和 facet 中支持 char16_t 和 char32_t 不会妨碍，但会启用基本的 Unicode i/o。

【讨论】：

@bames53 libstdc++ 源代码树中没有：gcc.gnu.org/git/?p=gcc.git;a=tree;f=libstdc%2B%2B-v3/include/…
@rubenvb 是的，libstdc++ 还没有。据我所知，只有 libc++ 和 Dinkumware 拥有它。
但请注意 Dinkumware 并不意味着 MSVC... 因为上次我检查过，他们没有任何 charNN_t 支持。
@rubenvb 我知道 MSVC 至少从 2010 年起就为 charX_t 类型提供了最简单的支持（将 char16_t 和 char32_t 定义为 unsigned short 和 unsigned int 的类型定义），但这在任何地方都无法正常工作。不过，它至少是半功能的，这在尝试将代码移植回旧版本时很有用。
从好的方面来说，至少他们完全承认他们没有为这些类型提供任何实际支持。不利的一面是，不记录 typedef 可能会导致人们在实际上不需要的地方使用 wchar_t，如果它没有迫使人们重写代码，那将是一个奇迹可能会按原样运行。