真正能“秒修”单个乱码文件的操作是：先用reopen with encoding尝试chinese (gbk)、gb2312或utf-8确认原始编码，显示正常后立即执行save with encoding保存为utf-8；注意reopen只改视图，save才写磁盘。
Sublime Text 里乱码不是文件坏了，是它用错了编码去读——比如拿 UTF-8 规则解一个 GBK 字节流，结果必然满屏方块。真正能“秒修”的操作只有两个：先 Reopen with Encoding 看对不对，再 Save with Encoding 真改磁盘内容。
怎么快速确认并修复单个乱码文件
右下角显示的“UTF-8”只是 Sublime 当前怎么读这个文件，不是文件真实编码。盲目点它只会让错上加错。
- 先按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac），输入Reopen with Encoding回车 - 从列表里优先试
Chinese (GBK)、GB2312、UTF-8—— 哪个显示中文正常，哪个就是原始编码 - 确认显示无误后，立刻执行
File → Save with Encoding → UTF-8（或你目标编码） - 注意：
Save with Encoding是真写磁盘，Reopen with Encoding只改当前视图，不碰文件
为什么 ConvertToUTF8 插件有时不生效
它不是万能开关，依赖两个前提：原始编码能被识别 + 没和其他配置冲突。
- 插件默认启用
convert_on_load: true，但若用户配置里留着detect_encoding: true，Sublime 会跳过 BOM 直接试 GBK，把带 BOM 的UTF-8文件判成乱码 - ST4 中偶有加载失败，常见原因是缺依赖
Codecs36或Codecs37；得先装它们，再装ConvertToUTF8 - Package Control 搜索到的
ConvertToUTF8多为过期镜像，推荐直接从 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"） - 删掉配置中任何
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→ 逐个打开 → 看状态栏原始编码标识 → 切换验证 → 确认后再Ctrl+S - 真要批量处理，用命令行更可靠：
iconv -f GBK -t UTF-8 input.txt > output.txt（Linux/macOS）或nkf -w -Lu input.txt > output.txt（Windows） - Sublime 原生不支持批量
Save with Encoding，所有号称“一键转码”的插件或宏，背后都没做真实编码校验
最麻烦的永远不是操作步骤，而是得先判断文件原本是什么编码——尤其混合了 UTF-8-BOM、GBK、ANSI 的老项目里，靠猜不如靠 file -i 或 Notepad++ 右下角看一眼。
