Reopen with Encoding只重解释字节、不改磁盘，安全试探原始编码；Save with Encoding才真正转码写入磁盘，不可逆。必须先用前者确认显示正常，再用后者保存为UTF-8，顺序颠倒会导致文件损坏。
Reopen with Encoding 和 Save with Encoding 别点反了
这两个操作功能完全相反，点错一次就可能把能读的文件“转坏”。Reopen with Encoding只改当前视图怎么读文件，不碰磁盘内容，安全；Save with Encoding是真把当前视图内容按新编码重写到磁盘，不可逆。
常见错误现象：右下角显示“UTF-8”，但中文全是方块，一通乱点后文件更乱——大概率是误点了Save with Encoding，用 UTF-8 规则把 GBK 字节流硬存了一遍，原始信息已损毁。
- 先按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac），输入Reopen with Encoding回车 - 优先试
Chinese (GBK)、GB2312、UTF-8—— 哪个显示中文正常，哪个就是原始编码 - 确认无误后，再执行
File → Save with Encoding → UTF-8，这才是真正写磁盘
ConvertToUTF8 插件为什么有时不生效
它不是万能开关，依赖两个前提：原始编码能被识别 + 没和其他配置冲突。插件默认启用 convert_on_load: true，但若用户配置里留着 detect_encoding: true，Sublime 会跳过 BOM 直接试 GBK，把带 BOM 的 UTF-8 文件判成乱码。
ST4 中偶有加载失败，常见原因是缺依赖 Codecs36 或 Codecs37；得先装它们，再装 ConvertToUTF8。Package Control 搜索到的多为过期镜像，推荐直接从 GitHub 镜像仓库 https://gitcode.com/gh_mirrors/co/ConvertToUTF8 手动安装。
- 插件不处理构建系统输出乱码（那是终端或
PYTHONIOENCODING的事） - 也不修复已损坏的 BOM
- 它只作用于当前打开的标签页，不扫描目录、不遍历文件
用户配置里 fallback_encoding 和 default_encoding 怎么设
这两个字段分工明确，混用会导致新旧文件全乱套。default_encoding 控制新建文件和显式保存时的编码，必须设为 "UTF-8"；fallback_encoding 是“兜底解码方式”，只在打开无 BOM、无声明的老文件时起作用，应设为 "Chinese (GBK)"（不是 "GBK" 或 "UTF-8"）。
fallback_encoding 不接受标准编码名，写 "UTF-8" 是无效配置。正确写法是 "fallback_encoding": "Chinese (GBK)" 或 "Western (ISO 8859-1)"，这些是 Sublime 内部注册的编码标识符。
- 删掉配置中任何
detect_encoding: true—— 它会让 Sublime 主动绕开 UTF-8 去试 GBK，反而把 UTF-8-BOM 文件搞崩 - 加一行
"save_with_bom": false，否则保存后 Python/Git 会报Non-UTF-8 code starting with '\xef'
批量转码别信“一键”脚本
所谓批量转换，本质是赌概率。一旦某文件实际是 UTF-8-BOM 却被误判为 GBK，转完就不可逆毁了。稳妥做法：装 ConvertToUTF8 → 逐个打开 → 看状态栏原始编码标识 → 切。
ConvertToUTF8 本身不支持批量，真正批量转码得靠 File Encoding User 插件 + 命令行工具配合。例如 Linux/macOS 下用 iconv：
{
"shell_cmd": "iconv -f GBK -t UTF-8 \"$file_path/$file_name\" > \"$file_path/utf8_$file_name\""
}
选中多个文件 → 右键 → Build With → 选该构建系统，即可逐个生成新编码文件（注意：原文件不会被覆盖）。
最常被忽略的一点：Sublime 右下角显示的“UTF-8”只是它当前怎么读这个文件，不是文件真实编码。盲目点它只会让错上加错。
