Sublime设置自动感应编码格式 解决多语言乱码

先说几个关于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 反复试，再逐段清理异常字节。别信什么“一键全量修复”的宣传，那是在赌概率，不是在解决问题。