先说几个关于Sublime Text编码的硬核事实：它所谓的“自动检测”其实远没有想象中那么智能，更像是一种有限的启发式扫描，而且默认还是关闭的。即便你手动开启了 detect_encoding，也未必能覆盖所有中文场景，反而在遇到混合编码或无BOM的文件时，容易给出错误的判断。
Sublime 的 detect_encoding 实际能做什么
它只在什么情况下触发呢？只有当文件同时满足两个条件——没有BOM，也没有类似 # -*- coding: utf-8 -*- 这样的编码声明——它才会扫描文件前10KB左右的字节，尝试匹配GBK、GB2312、SHIFT_JIS这些常见编码。但注意，它不像chardet那样能够基于概率模型做判断，遇到UTF-8和GBK字节重叠的情况，更是直接放弃治疗。
- 你把
"detect_encoding": true打开后，GBK文件可能被正确识别，但一个无BOM的UTF-8文件，只要里面带中文，就经常被误判为Western (ISO 8859-1)。 - 一旦识别失败，就会回落到
fallback_encoding设置的值。所以这个字段你必须配好，但注意别写成"UTF-8"，这玩意儿在Sublime里不顶用。得写"Chinese (GBK)"或者Sublime能理解的内部名称。 - 检测过程不缓存、不记录，每次打开文件都会重新计算。已经打开并显示乱码的文件不会自动刷新，你还是得手动用
Reopen with Encoding来纠正。
为什么装了 ConvertToUTF8 插件反而更乱
这个插件已经好几年没更新了，在Sublime Text 4.4以上版本兼容性很差。它会劫持文件加载流程，绕过原生的 detect_encoding，导致状态栏显示的编码信息失真，保存时还会静默转码，却不校验原始字节。你看到“自动识别成功”的提示，很可能是插件用GBK强行解码了所有文件，连英文日志里的 café 都给你变成 caé。
- 卸载方法：
Ctrl+Shift+P→ 输入Remove Package→ 选择ConvertToUTF8。 - 替代方案推荐
Codecs37。它不接管打开逻辑，只提供右键菜单快速重载，状态栏显示真实的原始编码，而且持续更新，支持GB18030、UTF-8-BOM、Big5等30多种编码。 - 装完不用额外配置，打开GBK文件就能看到状态栏显示
GBK，点击状态栏可以一键切换保存为UTF-8，不会污染其他文件。
fallback_encoding 设成 "Chinese (GBK)" 的真实代价
这个设置会让Sublime对所有无法识别编码的文件——比如无BOM的纯英文日志、JSON API响应、.env文件——都尝试用GBK解码。这不是什么“多语言支持”，而是全局的编码污染。
- 举个例子，一个
charset=iso-8859-1的Apache日志，如果fallback_encoding设为"Chinese (GBK)"，那么café会变成caé，naïve会变成naïve。 - 如果你日常混用中、英、日、韩项目，更稳妥的做法是：
"fallback_encoding": "UTF-8"加上"detect_encoding": true，再配合Codecs37手动处理冷门文件。 - 另外，务必检查配置里是否还有残留的
"detect_indentation": true，它会提前读取文件头做缩进分析，干扰后续的编码检测流程。
保存后其他工具报错 Non-UTF-8 code starting with '\xef'
如果遇到这个问题，说明不是编码没设对，而是Sublime默认加了UTF-8 BOM（也就是 \xef\xbb\xbf）。Python、Git、Shell脚本、YAML解析器都会把它当作非法字符拒收。
- 确认是否加了BOM：用
xxd 文件名 | head -n1查看，输出里如果包含ef bb bf，那就是带BOM。 - 禁用方法：在用户设置里加上
"sa ve_with_bom": false，光靠"default_encoding": "UTF-8"是不够的。 - 对于已经保存的带BOM文件，不要直接用
Sa ve with Encoding → UTF-8覆盖。正确的做法是：先Reopen with Encoding → UTF-8，再Sa ve with Encoding → UTF-8，否则BOM会被重复写入。
真正让人头疼的是混合编码文件：同一文件里部分行是UTF-8，部分行是GBK（比如从不同来源复制粘贴的文本）。这种情况没有通用解法，自动检测必定失败，最终只能靠人工用 Reopen with Encoding 反复试，再逐段清理异常字节。别信什么“一键全量修复”的宣传，那是在赌概率，不是在解决问题。
