必须先确认原始编码再重解码：乱码是UTF-8解GBK字节流所致，非文件损坏；先Reopen with Encoding→Chinese (GBK)使中文正常显示，再Save with Encoding→UTF-8转存，ST4中需配default_encoding_on_save:"UTF-8"并禁用fallback_encoding。
不能直接“转回”，必须先确认原始编码再重解码——你看到的“乱码”是 Sublime 用 UTF-8 解了一个 GBK 字节流的结果，不是文件损坏，也不是汉化导致的，而是解码错配。
Reopen with Encoding 选错原始编码就永远看不到中文
右下角显示的 UTF-8 或 Western (ISO 8859-1) 只是当前解码方式，不是文件真实编码。满屏方块时，它大概率正用 UTF-8 读 GBK 文件。
- 立刻点击右下角编码名 →
Reopen with Encoding→Chinese (GBK)（ST4 中也叫GBK） - 如果还不对，依次试
Chinese (GB2312)、Western (Windows 1252)；只要中文一出来，右下角变成Chinese (GBK)，说明原始编码识别对了 - 点完
Chinese (GBK)后更乱？说明原始编码不是 GBK，别保存，直接换下一个选项 - Linux/macOS 下验证真实编码：运行
file -i 文件名，看charset=gbk这类输出；Windows 用户用 Notepad++ 打开，右下角直接显示GBK最可信
Save with Encoding → UTF-8 是唯一真正转码动作
所有 Reopen with Encoding 操作都只改内存显示，不碰磁盘。只有这一步才写入新编码，且不可逆。
- 必须在中文完全正常显示后，再执行
File → Save with Encoding → UTF-8（注意不是UTF-8 with BOM） - 跳过上一步直接点它，等于把乱码字节再按 UTF-8 编一次，生成双乱码，几乎无法恢复
- 保存后关闭再重开，右下角应显示
UTF-8，且中文仍正常；如果别人用记事本打开还是乱码，说明Reopen with Encoding根本没识别对原始编码 - 验证是否真去除了 BOM：
xxd 文件名 | head -n1，输出不含ef bb bf才算干净
用户设置里 fallback_encoding 和 default_encoding_on_save 必须配对
ST4 彻底移除了 fallback_encoding 的作用，但很多人还在瞎配。真正起效的是 default_encoding_on_save，而 fallback_encoding 已失效。
- 删掉配置里所有
"fallback_encoding": "..."—— 它在 ST4 中完全无效 - 确保用户设置中有：
"default_encoding_on_save": "UTF-8"（大小写和短横必须严格匹配） -
"default_encoding"已被官方标记为“已弃用”，它只影响新建空文件右下角显示的编码标识，不影响保存行为 - 顺手加一行：
"save_with_bom": false，否则 Python/Git 会报Non-UTF-8 code starting with '\xef' - 禁用
"detect_encoding": true—— 它会让 Sublime 主动跳过 BOM 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码
批量处理旧项目时最容易踩的坑
混合编码项目里，一个文件一个编码是常态。别信“一键转码”插件，尤其当项目里混着 UTF-8-BOM、GBK、ANSI 时。
- ConvertToUTF8 插件虽方便，但它依赖自动检测，短文本或含异常控制字符的文件极易误判
- 真正安全的做法：逐个用
file -i或 Notepad++ 确认原始编码，再手动Reopen with Encoding→Save with Encoding - 如果保存失败或静默丢字，很可能是文件含
GB18030混合变体或不可见控制字符，建议先用 Notepad++ 转一次再回 Sublime 验证 - 插件装了但没生效？检查是否漏掉重启，或插件本身不兼容 ST4 —— 很多老插件在 2026 年已停止维护
最常被忽略的一点：你确认“中文显示正常”之后，一定要再看一眼右下角状态栏——它显示的是当前解码方式，不是保存编码。只有 Save with Encoding → UTF-8 执行完，且 xxd 验证无 BOM，才算真正完成。
