sublime text 的 detect_encoding 仅对无 bom、无编码声明的文件扫描前 10kb，支持 gbk/gb2312/shift_jis 等但不支持概率模型，易误判 utf-8 为 iso-8859-1；fallback_encoding 设为 "chinese (gbk)" 会导致英文文件乱码；converttoutf8 插件已过时且引发乱码，推荐 codecs37；禁用 bom 需设 "save_with_bom": false；混合编码文件无自动解法，须手动干预。
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 文件可能被正确识别，但 UTF-8（无 BOM）+ 中文仍常被当成Western (ISO 8859-1) - 一旦识别失败，就回落到
fallback_encoding—— 所以这个字段必须配，且不能写"UTF-8"（无效），得写"Chinese (GBK)"或"UTF-8"对应的 Sublime 内部名（实际只认"UTF-8"在default_encoding中） - 检测过程不缓存、不记录，每次打开都重算；已打开的乱码文件不会自动刷新，仍需手动
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 - 禁用方法：在用户设置里加
"save_with_bom": false，仅靠"default_encoding": "UTF-8"不够 - 已保存的带 BOM 文件，别用
Save with Encoding → UTF-8覆盖——先Reopen with Encoding → UTF-8，再Save with Encoding → UTF-8，否则 BOM 会被重复写入
真正难处理的是混合编码文件：同一文件里部分行是 UTF-8，部分是 GBK（比如从不同来源复制粘贴的文本）。这种没有通用解法，自动检测必败，最终只能靠人工 Reopen with Encoding 反复试，再逐段清理异常字节。别信“一键全量修复”的宣传，那是在赌概率，不是在解决问题。
