必须先确认真实编码再批量转换，否则会毁文件；用file -i *.txt（Linux/macOS）或Notepad++右下角显示（Windows）识别原始编码，Reopen with Encoding仅改读取方式，Save with Encoding才真正重写磁盘。
不能批量“一键修复”——所有声称能全自动识别并转码的方案，都会在混合编码项目里出错。真正安全的批量处理，必须基于已知真实编码，再逐个确认显示效果。盲目批量转换，等于把 UTF-8 文件当 GBK 重写一遍，乱码就真毁了。
怎么确认一批文件的真实编码？别猜，用命令或 Notepad++
Sublime 右下角显示的 “UTF-8” 或 “Western (ISO 8859-1)” 是它当前怎么读，不是文件本来就是这个编码。满屏方块时，它大概率正用 UTF-8 解一个 GBK 字节流。
- Linux/macOS 用户：运行
file -i *.txt（替换为你的扩展名），看输出里的charset=gbk、charset=utf-8或charset=us-ascii - Windows 用户：用 Notepad++ 批量打开 → 右下角会明确显示每个文件的编码（如
GBK、UTF-8-BOM、ANSI） - 绝对不要依赖
detect_encoding: true：它会让 Sublime 跳过 BOM 主动试 GBK，结果是把带 BOM 的 UTF-8 文件判成乱码
Reopen with Encoding 和 Save with Encoding 到底谁管什么？
这两个菜单项功能完全相反，点错一次就不可逆。它们不改变文件内容，只改变 Sublime 怎么解释那一堆字节。
-
Reopen with Encoding：只改当前视图解码方式，不碰磁盘文件，安全。适合乱码后立刻试Chinese (GBK)、Chinese (GB2312)、UTF-8—— 中文一出来，右下角变成对应编码，就说明原始编码对了 -
Save with Encoding：真把内存里当前 Unicode 内容，按新编码重写到磁盘。必须等Reopen with Encoding确认中文完全正常后才点，否则就是把乱码再存一遍 - 千万别点老版本里的
Convert to UTF-8：它静默重写文件且不提示，原始编码信息直接丢失
ConvertToUTF8 插件能帮你省多少事？边界在哪？
它确实能自动识别 GBK 并转成 UTF-8 显示，但只在“显示层”起作用，背后仍是靠规则匹配，不是 AI 推理。短文本、混合编码、BOM 干扰下误判率不低。
- 安装后状态栏会显示当前检测到的编码（如
GBK），点击可快速切换解码方式 - 按
Ctrl+S时，插件会自动以 UTF-8 保存 —— 但它不会修改原文件编码逻辑，只是做一次性转换 - Linux/macOS 用户注意：必须额外安装
Codecs插件，否则ConvertToUTF8无法完整工作 - Sublime Text 4 用户注意：
fallback_encoding已彻底失效，控制保存行为的是default_encoding_on_save，设为"UTF-8"才管用
最麻烦的从来不是操作步骤，而是得先判断每个文件原本是什么编码。尤其在遗留项目里，可能同时存在 UTF-8（带/不带 BOM）、GBK、GB18030、甚至 ANSI 混合的情况。一个一个试不是偷懒，是唯一能守住数据底线的做法。
