判断编码的基本思路
编码信息不在文件里，除了 BOM 和文档内的声明（XML 声明、HTML meta、HTTP 头）之外，其余都是推断。可靠顺序是：先看有没有 BOM，再看字节是否全落在 ASCII 区（是全 ASCII 就不必讨论编码），然后用严格模式尝试 UTF-8 解码（合法则极可能是 UTF-8），失败再按 GBK/GB18030 等候选解码，并检查得到的文本是否落在常用字与预期语种范围内。统计型探测器对短文本和单字节编码并不可靠，只能用于提示。
基本信息
| 可靠信号 | BOM；XML 声明；HTML meta charset；HTTP Content-Type |
|---|---|
| 半可靠信号 | UTF-8 严格解码是否通过 |
| 弱信号 | 字频统计探测、扩展名、目录来源 |
| 常用工具 | file / file -i、iconv 试转、语言内置解码、chardet 类库 |
| 判定原则 | 用足够长的样本验证，短文本不做结论 |
| 风险点 | UTF-8 合法不代表一定就是 UTF-8，GBK 字节偶尔也能通过校验 |
典型使用场景
- 数据迁移摸底：批量统计历史目录下文件的真实编码，决定转换策略
- 解析外部文件失败时的排查：先确认编码，再改代码
- 接口联调：对方声称 UTF-8，实际发出 GBK 字节，需要快速验证
- 日志与导出文件处理：确定按哪种编码读取，避免替换字符污染数据
- 修复脚本设计：先识别再分类处理，避免一刀切转码造成不可逆损坏
判定与验证示例
判定与验证示例
file -i sample.txt # 给出 charset 猜测，注意 unknown 不等于不是 UTF-8
head -c 3 sample.txt | xxd # 先排除 BOM
iconv -f UTF-8 -t UTF-8 sample.txt > /dev/null && echo utf8-strict-ok # 严格校验 UTF-8
iconv -f GBK -t UTF-8 sample.txt > /dev/null 2>&1 && echo gbk-ok # 候选编码逐一试
# 探测内容是否只含 ASCII：无输出即纯 ASCII，编码不可区分
python -c "b=open('sample.txt','rb').read(); print(all(x < 128 for x in b))"
# 用统计库给提示（仅供提示，不作为结论）
python -c "import chardet;print(chardet.detect(open('sample.txt','rb').read()))" 2>/dev/null || echo no-chardet证据可靠性对照
| 证据 | 可靠性 | 说明 |
|---|---|---|
| BOM | 高 | 开头的 EF BB BF 基本可断定 UTF-8；FF FE 类为 UTF-16/32 |
| XML/HTML 声明 | 高 | 声明与内容不符时以能正确解码者为准并修正声明 |
| HTTP/数据库连接声明 | 高 | 声明通常可信，但中间环节可能已按别的方式转码 |
| UTF-8 严格校验通过 | 较高 | 长文本通过基本可确认；短文本有误判概率 |
| 全为 ASCII 字节 | 高 | 内容与编码无关，任何 ASCII 兼容编码结果一致 |
| 统计探测结果 | 低到中 | 对短文本、单字节编码、中日韩文之间区分能力差 |
「用哪种编码读」与「文件是什么编码」是两件事：一个文件可能同时能被多种编码无错解码，但只有一种能得到有意义的内容。判定的落脚点是内容是否可读、是否符合预期语种，而不是解码器有没有报错。
不要用「打开再另存」的方式试探编码：一旦用错误编码打开并保存，原始字节就被永久改写，多字节序列可能已损坏。试探应在只读的副本上进行，并优先使用字节级工具。
批量场景应把识别结果与置信度一起记录（例如「BOM 判定」「UTF-8 校验通过」「统计猜测」），只对高置信项自动转换，其余进入人工复核队列。这样能避免误判被放大成批量数据事故。