ConvertToUTF8插件是解决Sublime Text中文乱码的核心工具，需手动配置convert_on_load、convert_on_save为true并调低confidence至0.90，配合file -i或Notepad++确认真实编码，避免误用Reopen/Save with Encoding导致不可逆损坏。
Sublime Text 本身不自动识别 GBK、BIG5、EUC-KR 等非 UTF-8 编码，所谓“智能识别”必须靠 ConvertToUTF8 插件驱动；没有它，detect_encoding: true 反而会让带 BOM 的 UTF-8 文件被误判为 GBK，越配越乱。
怎么确认文件真实编码，而不是瞎试右下角菜单
Sublime 右下角显示的 “UTF-8” 或 “Western (ISO 8859-1)” 只是当前解码方式，不是文件真实编码。点错一次 Reopen with Encoding 就可能让能读的文件变乱码，所以先验明正身：
- Linux/macOS 下运行
file -i 文件名，看输出中charset=gbk或charset=utf-8 - Windows 用户用 Notepad++ 打开，右下角直接显示 “GBK”、“UTF-8-BOM”、“ANSI”（即系统默认编码，通常是 GBK）
- 别信
detect_encoding: true：它会跳过 BOM 直接试 GBK，把带 BOM 的 UTF-8 当乱码处理——这个配置建议直接删掉
ConvertToUTF8 安装后必须改的三个关键配置项
插件默认配置偏保守，convert_on_load 和 convert_on_save 都是 false，等于没开自动转换。打开用户级配置 ConvertToUTF8.sublime-settings（路径：Preferences > Package Settings > ConvertToUTF8 > Settings – User），填入：
{
"convert_on_load": true,
"convert_on_save": true,
"confidence": 0.90
}
-
convert_on_load: true：文件一打开就转成 UTF-8 显示，编辑无感 -
convert_on_save: true：保存时自动还原为原始编码（如 GBK），不破坏协作环境 -
confidence: 0.90：默认 0.95 太高，对短文件或混合编码易漏检；降到 0.90 能覆盖更多 GBK/GB2312 边界情况
Save with Encoding 和 Reopen with Encoding 别混用
这两个菜单功能完全相反，误操作会导致文件内容被静默重写，且不可逆：
-
Reopen with Encoding：只改当前视图怎么读磁盘字节，不碰文件本身，安全试探。适合乱码后快速点Chinese (GBK)、UTF-8看哪项能出中文 -
Save with Encoding：真把当前视图内容按新编码写回磁盘。必须在Reopen with Encoding确认显示正常后才用，否则可能把已修复的中文再存成乱码 - 绝对避开
Convert to UTF-8（旧版菜单里有）：它不提示、不备份、不保留原始编码信息，点了就丢
fallback_encoding 写 "UTF-8" 是无效的
fallback_encoding 不接受标准编码名，写 "UTF-8" 等于没设。它只认 Sublime 内部注册的编码标识符：
- 正确写法：
"fallback_encoding": "Chinese (GBK)"或"Western (ISO 8859-1)" -
default_encoding才支持"UTF-8"，它管新建文件和显式保存时的默认行为 - 推荐组合：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)"，兼顾新文件统一性和旧项目兼容性 - 顺手加
"save_with_bom": false，否则 Python/Git 会报Non-UTF-8 code starting with '\xef'
最易被忽略的一点：插件不会帮你改文件磁盘内容，它只是在加载和保存时做透明转换。如果你把一个 GBK 文件用 Save with Encoding → UTF-8 强行另存，ConvertToUTF8 就再也无法还原原始编码——它依赖原始字节流做检测，BOM 和编码痕迹一旦被覆盖，就真成黑盒了。
