先检测BOM：EF BB BF为UTF-8，FF FE/FE FF为UTF-16；无BOM则校验UTF-8字节规则（排除C0-C1、F5-FF等非法首字节），前1024字节通过且含非ASCII字符可判UTF-8；全ASCII时无法确定，需用户干预或按UTF-8默认处理。
怎么用C++快速判断TXT文件是ANSI还是UTF-8
不能靠文件扩展名，也不能靠系统默认编码——Windows记事本存的.txt可能是UTF-8带BOM、UTF-8无BOM、GBK（ANSI）、UTF-16等任意一种。C++标准库不提供编码探测，得自己读字节分析头部特征。
核心思路：先读前几个字节，检查BOM；没BOM就试探UTF-8合法性；再结合内容合理性（比如是否全是可打印ASCII）做保守判断。
- UTF-8有BOM时，开头三字节固定为
\xEF\xBB\xBF - ANSI（此处指Windows本地编码，如GBK）绝不会以
\xEF\xBB\xBF开头 - 但很多UTF-8文件根本没BOM，这时必须验证字节序列是否符合UTF-8编码规则（比如
0xC0~0xC1是非法首字节，0xF5~0xFF不能作首字节） - 纯ASCII文本（0x00–0x7F）既是合法UTF-8，也是合法GBK，此时无法100%区分，只能按“无BOM + 全ASCII”暂判为UTF-8（更通用）或留待后续启发式判断
读文件前3–4字节检测BOM最可靠
BOM是唯一无需解析全文就能下结论的依据。Windows平台下，std::ifstream默认以binary模式读取最安全，避免被流自动转码干扰。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream::read()读前4字节到char buf[4]，长度够覆盖UTF-8/UTF-16/UTF-32所有BOM - 严格比对：
buf[0]==0xEF && buf[1]==0xBB && buf[2]==0xBF→ 确认为UTF-8 with BOM - 若
buf[0]==0xFF && buf[1]==0xFE（小端）或0xFEFF（大端）→ UTF-16，不是UTF-8也不是ANSI - 读不满3字节（文件太短）直接视为ANSI（或拒绝处理），不强行猜测
没有BOM时，用UTF-8字节规则验证前N个非ASCII字符
仅检查BOM不够——大量Linux生成的UTF-8文件无BOM。这时要验证字节流是否满足UTF-8定义：首字节决定长度，后续字节必须是0x80–0xBF，且不能出现过长/非法组合。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 从第1字节开始扫描，跳过ASCII（
c ），对每个>=0x80的字节做状态机校验 - 遇到
0xC0或0xC1立即返回“非法UTF-8”（UTF-8禁止这两个值作首字节） - 遇到
0xF5–0xFF也立即失败（超出Unicode码位上限） - 只验证前1024字节足够：既快，又能覆盖绝大多数误判场景；全文件校验开销大且没必要
- 若校验通过，且存在≥1个非ASCII字符（如中文、emoji），基本可判UTF-8；若全ASCII，保持中立，不否定也不肯定
ANSI（GBK）不能靠“不是UTF-8”反推
很多人写成“如果不是UTF-8，就是ANSI”，这是危险逻辑。文件还可能是ISO-8859-1、Shift-JIS、Big5，甚至损坏数据。Windows上所谓“ANSI”实际是系统GetACP()返回的代码页（如CP936=GBK），它只是默认解释方式，不是文件固有属性。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要用
MultiByteToWideChar(CP_ACP, ...)直接转——如果文件其实是UTF-8，会乱码且不可逆 - 若BOM缺失+UTF-8校验失败+文件含中文，可尝试用
CP936解码并检查结果是否含有效汉字（如用IsDBCSLeadByte或简单查Unicode范围0x4E00–0x9FFF） - 真正健壮的做法是：把BOM检测 + UTF-8校验 + GBK启发式解码封装成优先级链，返回置信度（如“UTF-8-BOM: 100%, UTF-8-noBOM: 85%, GBK: 60%”），由上层决定fallback策略
- 永远保留原始字节流——编码判断只是提示，最终解码动作应可配置、可覆盖
最麻烦的地方在于：没有BOM的纯ASCII文件，无论用UTF-8还是GBK解码结果都一样，这时候任何自动判断都是赌概率。别试图100%准确，留个手动指定编码的入口更实在。
