std::wifstream读UTF-16LE文件必须在open前imbue UTF-16 locale，否则按本地编码解析导致乱码；wcout输出需同locale并调用SetConsoleOutputCP(CP_UTF8)或转UTF-8字符串输出。
std::wifstream必须在open前imbue()，否则默认按本地编码解析
Windows下std::wifstream读UTF-16LE文件不设locale，会把每个2字节当一个wchar_t硬拆——哪怕文件有BOM（0xFF 0xFE）也视而不见，结果是乱码或提前截断。根本原因是C++标准库不自动识别BOM，也不默认启用UTF-16解码。
实操建议：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须在调用
open()或构造函数之后、read()之前调用imbue() - 推荐用
std::locale(std::locale(), new std::codecvt_utf16<wchar_t std::little_endian>)</wchar_t>（C++11/14） - 注意：
std::codecvt_utf16在C++17起被标记为deprecated，但Windows MSVC + libc++仍稳定可用；libstdc++支持较弱，编译失败时需换用WideCharToMultiByte手动转换 - 若文件无BOM，该locale仍可工作，但要求字节序严格为LE；BE文件会错乱
std::wcout输出wstring前也要imbue相同locale，且需SetConsoleOutputCP
即使wifstream读对了，std::wcout默认用控制台当前代码页（如GBK/936）解码wstring，导致“读对了却看不见”。这不是流本身问题，而是Windows控制台底层不直接渲染UTF-16。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对
std::wcout调用imbue()，传入和输入流**完全相同的locale实例**（不能新建一个同名locale） - 立即调用Windows API：
SetConsoleOutputCP(CP_UTF8)，让控制台接受UTF-8输出 - 更稳妥方案：用
WideCharToMultiByte(CP_UTF8, ...)将std::wstring转成std::string，再用普通std::cout输出——避开wcout的locale状态污染风险
fopen_s + fwprintf保存UTF-16LE文件要带ccs=参数
用C风格API写UTF-16LE文件，关键不是函数名带w，而是打开模式里必须显式声明编码。只用fopen_s开文件、再用fwprintf写，若没指定ccs，文件实际仍是ANSI编码，fwprintf会按当前locale把wchar_t强行映射为多字节，必然乱码。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 打开模式必须含
"ccs=UTF-16LE"，例如：_wfopen_s(&fp, L"out.txt", L"wt, ccs=UTF-16LE") - 务必用
fwprintf（而非fprintf），因为fwprintf能正确处理宽字符格式化 - 文件开头会自动写入BOM（
0xFF 0xFE），无需手动写 - 若需无BOM的UTF-16LE，改用二进制模式+手动写入字节，但需自行处理代理对和字节序
检测文件是否为UTF-16LE：优先检查前2字节BOM
BOM是判断UTF-16LE最可靠依据，比内容分析更准。Windows记事本、VS等工具保存UTF-16LE时必写BOM；但部分编辑器（如某些Linux工具）可能省略，此时仅靠字节特征易误判。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream以ios::binary模式打开，读前2字节 - 若
buffer[0] == 0xFF && buffer[1] == 0xFE，基本可确定为UTF-16LE - 避免用文本模式读取来检测——Windows下会触发换行符转换，破坏原始字节
- 若无BOM，需结合字符范围统计（如大量
0x00xx字节）、常见中文Unicode区间（U+4E00–U+9FFF）出现频率辅助判断，但仍有误判风险
