bom可直接判断utf-8/utf-16/utf-32编码：ef bb bf为utf-8，ff fe或fe ff为utf-16，ff fe 00 00或00 00 fe ff为utf-32；匹配后须跳过bom字节再解析正文，否则导致乱码。
怎么用 BOM 判断文件编码
BOM（Byte Order Mark）是文件开头几个字节的固定标记，能直接告诉你是不是 UTF-8、UTF-16 或 UTF-32。但它只在文件以这些编码保存且**显式写入 BOM**时才存在——很多编辑器（比如 VS Code 默认）根本不会加 UTF-8 BOM，所以不能全靠它。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 读取文件前 4 字节，逐个比对常见 BOM 模式：
0xEF 0xBB 0xBF→ UTF-8；0xFF 0xFE（小端）或0xFE 0xFF（大端）→ UTF-16；0xFF 0xFE 0x00 0x00或0x00 0x00 0xFE 0xFF→ UTF-32 - 注意：BOM 一旦匹配，必须跳过这些字节再解析正文，否则
std::string或std::wstring会把它们当普通字符处理，导致乱码或解析失败 - Windows 记事本保存的“UTF-8”默认带 BOM，但 Linux/macOS 工具（如
iconv、python3）通常不认它，C++ 程序若跨平台读取，得先剥离再转码
没有 BOM 时怎么启发式猜编码
纯文本没 BOM 就只能靠字节分布规律硬猜。常见做法是统计单字节/双字节序列的合法性，比如 UTF-8 的多字节序列有严格格式（0xC0–0xDF 开头必须跟 1 个 0x80–0xBF，0xE0–0xEF 开头必须跟 2 个……），而 GBK 中 0x81–0xFE 开头的字节后面也必须跟另一个 0x40–0xFE（排除 0x7F）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 别自己从零写判断逻辑——用成熟库更靠谱，比如
icu::CharsetDetector（ICU 库）或轻量级的uchardet（C 接口，C++ 可调用）；Boost.Locale的detect_encoding也能用，但对 GBK 支持偏弱 - 采样长度很重要：只读前 1–4 KB 足够，太短（32 KB）性能下降且收益极小
- 中文文本下，UTF-8 和 GBK 字节特征接近，单靠统计易混淆；如果文件含英文标点或 ASCII 字符比例高，UTF-8 置信度自动上升
std::ifstream 读文件时编码不匹配的典型表现
用 std::ifstream 以 std::ios::binary 模式读出来的是原始字节，本身不涉及编码转换；但一旦用 std::getline 或 operator>> 直接往 std::string 里塞，就默认按当前 locale 解码——而多数系统 locale 是 C 或 en_US.UTF-8，遇到 GBK 文件就会崩。
常见错误现象：
-
std::string长度和实际字符数严重不符（GBK 中一个汉字占 2 字节，UTF-8 占 3 字节，但.size()返回字节数） - 用
std::cout 输出乱码，但用 <code>printf("%02x ", (unsigned char)c)打印字节却是合法 GBK 序列 - 调
str.find("你好")返回std::string::npos，因为字符串里存的是 GBK 字节，而字面量"你好"在源文件编码为 UTF-8 时是 6 字节，二者根本不等价
跨平台检测时最常被忽略的一点
Windows 上用 MultiByteToWideChar(CP_ACP, ...) 依赖系统 ANSI 代码页（通常是 GBK），Linux/macOS 根本没这概念；反过来，Linux 的 nl_langinfo(CODESET) 返回 UTF-8，但用户可能手动用 iconv -f GBK -t UTF-8 处理过文件。
这意味着：
- 不要用
setlocale(LC_ALL, "")后直接调mbstowcs做检测——它只反映当前环境，不反映文件真实编码 - 检测结果必须和后续解析解耦：先用
uchardet得到编码名（如"UTF-8"、"GB18030"），再用std::iconv或std::codecvt_utf8（C++11，已弃用但仍有项目在用）做转换 -
GB18030兼容 GBK，但多了四字节编码；很多“GBK 检测器”会把它错判成 UTF-8，因为部分四字节序列恰好符合 UTF-8 格式——真要严谨，得优先匹配 GB18030 规则
实际项目里，90% 的“编码问题”不是检测不准，而是检测完没正确剥离 BOM、没选对转换目标宽字符类型（char16_t 还是 char32_t）、或者把转换后的内存当成原始字节又传给第三方库。这些环节比检测本身更容易出错。
