跨系统下std::wcin.eof()、UTF-8与locale关联异常问题求解

核心背景差异 #

所有差异本质来自两个平台C++标准库的宽字符流实现、默认locale行为的区别：

• Linux（CentOS）使用glibc的libstdc++，宽字符wchar_t为4字节，UTF-8 locale下的多字节/宽字符转换逻辑符合预期；默认C locale仅支持ASCII编码，遇到非ASCII字节会转换失败。
• macOS使用LLVM的libc++，wchar_t虽然也是4字节，但系统原生的locale转换逻辑存在大量历史遗留bug，尤其是UTF-8和宽字符的互转场景；默认C locale下宽字符流会跳过编码校验，直接把输入字节作为宽字符的低8位传输。

问题1：为什么场景2会在行中检测到EOF？EOF前的额外空格来自哪里？ #

场景2中macOS启用了std::locale("")（即系统默认的en_US.UTF-8 locale），当std::wcin读取到输入里的日文UTF-8多字节序列（十六进制e3 83 a9对应片假名「ラ」）时，libc++的编码转换逻辑触发内部错误，直接给流设置了failbit和eofbit标记，属于转换失败触发的假EOF，并不是真的读到了文件末尾。
你看到的额外空格是转换失败时，流输出的错误占位字符，并非输入本身的内容。

问题2：为什么场景3会立即检测到EOF？ #

场景3中CentOS注释了locale配置，宽字符流使用默认的C locale（仅支持ASCII编码），输入第一个非ASCII字节0xe3超出了C locale的识别范围，转换直接失败，流被置为错误+EOF状态，所以还没读到任何有效内容就触发了EOF判断。

问题3：如何实现始终得到一致的正常表现？ #

优先选择以下方案：

• 方案1（最稳妥跨平台）：放弃宽字符流，全程使用std::string和std::cin/std::cout处理字符，只要输入输出环境统一为UTF-8编码（现在绝大多数桌面、服务器系统默认都是UTF-8），就不会出现编码转换问题。
• 方案2（必须用宽字符的场景）：手动指定编码转换规则，使用C++11引入的std::codecvt_utf8<wchar_t>手动imbue到std::wcin/std::wcout，绕开系统locale的实现差异，不要依赖std::locale("")的默认转换逻辑。
• 若需要兼容Windows平台，可单独针对Windows做宽字符适配，其他平台统一使用UTF-8窄字符流。

附加问题：macOS下修改输入后出现的乱码、重复字符、异常值来源是什么？ #

这些异常全部来自libc宽字符流转换失败后的未定义行为：编码转换出错后，流的内部缓冲区没有被正确清空，错误状态也没有被重置，后续读取操作会读到缓冲区残留的无效数据、转换失败的占位垃圾值，你观测到的0x7ffe就是libc转换失败时返回的内部错误标记值，在流处于错误状态时继续读写就会出现各种乱码、重复字符、异常返回值的问题。

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