能否使用UTF-16编码的std::fstream？C++编解码相关问题

前置事实梳理 #

先把几个没有争议的标准规则和实现现状列清楚：

• std::wfstream本质是std::basic_fstream<wchar_t>的别名，wchar_t的宽度平台差异是明确的：Windows下固定2字节，对应UTF-16编码单元；Linux、macOS等类Unix系统下固定4字节，对应UTF-32/UCS-4编码单元。
• std::basic_filebuf的转换逻辑确实存在一个很少被提及的隐含假设：1个内部字符类型单元，对应N个外部字节（N≥1）。也就是说，它调用codecvt面做转换时，每次给内部字符缓冲区预留的空间，只够放1个内部字符单元，不会为多单元表示的字符预留连续空间。
• C++20弃用的是所有基于std::codecvt的Unicode转换特化，包括std::codecvt_utf8、std::codecvt_utf8_utf16、std::codecvt<char16_t, char, std::mbstate_t>、std::codecvt<char32_t, char, std::mbstate_t>，codecvt模板本身没有被弃用。

两个待验证判断的结论 #

判断1：std::wfstream读UTF-8文件时，含U+FFFF以上码点会在Windows失败、Linux正常 #

这个判断基本成立，仅需补充细节：

• Windows平台下，2字节的wchar_t要表示U+FFFF以上的码点，必须用UTF-16代理对——也就是2个连续的wchar_t单元共同表示1个码点。这刚好撞上了basic_filebuf的单字符假设：转换时第二个代理单元没有预留写入位置，要么直接写越界触发内存损坏，要么转换状态错乱生成孤立代理项，最终表现为乱码、流报错、甚至程序崩溃。哪怕你手动给流注入std::codecvt_utf8_utf16<wchar_t>面，只要走默认的basic_filebuf逻辑，这个问题就绕不开。
• Linux平台下wchar_t是4字节，直接存Unicode码点值，根本不存在代理对的概念，只要locale配置正确（或者注入std::codecvt_utf8<wchar_t>），从U+0000到U+10FFFF的全量码点都能正常转换。macOS等BSD系统的wchar_t宽度和Linux一致，表现完全相同。

判断2：不存在可移植的、基于标准basic_fstream的UTF文件宽字符解码方案 #

这个判断完全成立：

• 用char16_t实例化basic_fstream的话，一来躲不开上面说的单字符假设，代理对处理必然出问题；二来C++20已经弃用了对应的codecvt转换特化，标准不再要求实现提供UTF-8到char16_t的转换能力，没有可移植的转换面可以用。
• 用char32_t实例化的话，虽然UTF-32是单单元编码、符合1:N的映射假设，但对应的codecvt<char32_t, char, std::mbstate_t>特化同样在C++20被弃用，各平台默认locale下不一定自带这个转换能力，手动注入已经被弃用的std::codecvt_utf8<char32_t>不属于标准保障的可移植用法。
• 目前各编译器提供的Unicode文件流支持都是平台专属的，比如MSVC的_setmode( _fileno(fp), _O_U8TEXT )接口，没法跨编译器、跨系统通用。

三个常见疑问解答 #

疑问1：这个设计算不算C++标准的缺陷？ #

不算严格意义上的标准缺陷，属于标准库设计滞后于实际需求的历史遗留问题：

• C++的locale和codecvt体系设计在上世纪90年代，远早于Unicode全面普及的时间，最初的设计目标是适配各国的ANSI代码页（比如GBK、Shift-JIS这类双字节字符集），这类字符集刚好满足1个内部字符对应N个外部字节的映射关系，当时根本没有考虑UTF-16这种需要多个内部单元表示单个码点的编码。
• 标准委员会早就意识到了这个问题，所以才在C++20弃用了设计有硬伤的codecvtUnicode转换分支，目前已经有多版关于新一代文本编解码库的提案，专门覆盖Unicode转码、文件读写的需求，只是还没正式进入标准。

疑问2：标准当初为什么要设置单字符转换的假设？ #

核心原因是简化流的缓冲区管理，兼顾运行效率：

• basic_filebuf内部的原始缓冲区是按char（外部字节类型）分配的，读文件时先把字节读到这个原始缓冲区，再分段转换成内部字符类型。如果允许单个码点对应多个内部字符单元，流在做字符回退（putback）、随机定位、行尾判断的时候，需要额外维护多单元字符的转换状态、每次转换预留足够的连续内部字符空间，会让缓冲区逻辑的复杂度提升好几个量级，还会带来额外的性能开销。
• 这个设计在90年代是完全合理的，当时主流的多字节字符集没有任何一种需要多个内部字符单元表示单个字符，这个假设覆盖了所有已知的使用场景。

疑问3：忽略这个假设直接用现有STL写代码，会出什么问题？ #

三个主流STL实现的异常表现非常明确：

• MSVC STL（Windows平台）：默认basic_filebuf每次转换只给1个wchar_t/char16_t的写入位置，遇到需要代理对的码点时，第二个代理单元会直接写到缓冲区预留范围之外，调试模式下会立刻触发断言崩溃，非调试模式下可能出现堆内存损坏、乱码、字符串截断、孤立代理项等各种不可预期的问题。
• libstdc++（GCC，主要用于Linux）：当CharT是4字节wchar_t时没有任何问题；如果用char16_t实例化流，它的codecvt_utf8_utf16实现遇到代理对时会返回partial状态，告诉调用者当前输出空间不足需要更多空间，但basic_filebuf每次只会给1个char16_t的位置，会导致转换一直卡在同一个位置无法推进，最终流直接置failbit，读取终止。
• libc++（Clang配套实现，跨平台）：表现和libstdc++基本一致，char16_t场景下遇到代理对时转换无法推进，流进入失败状态；部分旧版本的实现会把代理对的两个单元拆成两次独立转换，生成两个孤立的代理项，最终输出乱码。

内容的提问来源于stack exchange，提问作者Flamefire