Sublime中文乱码主因是编码错配，须先Reopen with Encoding选对原始编码（如Chinese (GBK)）使内容正常显示，再Save with Encoding→UTF-8真正转存；配置应设"default_encoding": "UTF-8"、"fallback_encoding": "Chinese (GBK)"，并禁用detect_encoding。
Sublime 打开中文文件显示乱码，**不是文件损坏，也不是编辑器坏了，而是它用错了编码去读字节流**。你看到的方块、问号或错位字符，99% 是因为 Sublime 默认拿 UTF-8 去解一个实际是 GBK 的文件——两个字节被当一个 UTF-8 字符，自然崩掉。解决的核心就两步：先让内容“看着对”，再让磁盘“存得对”。
Reopen with Encoding 选对原始编码才能正常显示
右下角显示的 “UTF-8” 只是 Sublime 当前怎么读这个文件，不是文件真实编码。盲目点它只会让错上加错。
- 打开乱码文件后，立刻点击右下角当前编码名（比如
UTF-8）→ 选Reopen with Encoding→Chinese (GBK) - 如果还不对，再试
Chinese (GB2312)或Western (Windows 1252)（旧版记事本无 BOM 时常见） - 只要中文显示正常，就说明原始编码判断对了；如果全变乱码，说明选错了，别保存，直接重试
- 若列表里没有合适选项，先用
file -i 文件名（Linux/macOS）或 Notepad++ 打开看右下角标识，确认真实编码
Save with Encoding → UTF-8 才是真正转码动作
很多人以为点一下状态栏就转码了，其实那只是换了解码方式，磁盘文件一字未动。真正把文件变成 UTF-8 的，只有这一步。
- 必须在
Reopen with Encoding确认显示正常后，再执行File → Save with Encoding → UTF-8（注意：不是UTF-8 with BOM） - 跳过第一步直接保存，等于把 GBK 字节当 UTF-8 解，再以 UTF-8 写出——结果是
ä½ å¥½这类不可逆乱码 - 保存后可用
xxd 文件名 | head验证是否含 BOM：\xef\xbb\xbf就是 BOM，说明配置没生效 - 如果保存失败或静默丢字，可能是文件含 GB18030 混合变体或异常控制字符，建议先用 Notepad++ 转一次再回 Sublime
用户设置里 fallback_encoding 和 default_encoding 怎么配
这两个配置项分工明确，混用会出问题。它们不解决已打开的乱码文件，但能大幅减少后续新打开文件的乱码概率。
-
default_encoding：只管新建文件和显式保存时的编码，必须设为"UTF-8" -
fallback_encoding：只在打开无 BOM、无声明的老文件时兜底，正确写法是"Chinese (GBK)"（不是"GBK"或"UTF-8"） - 推荐组合：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)" - 务必删掉配置里可能存在的
detect_encoding: true—— 它会让 Sublime 主动跳过 UTF-8 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码
ConvertToUTF8 插件现在还值得装吗
官方仓库早在 2020 年就下架了 ConvertToUTF8，现在通过 Package Control 搜到的基本是过期镜像或改名版本（如 CTU8），兼容性差、甚至有安全风险。
- ST4.4+ 用户强烈建议换
Codecs37：支持 GBK/GB18030/UTF-8-BOM/Shift-JIS 等 30+ 编码，持续更新，状态栏自动显示真实编码 - 若坚持用原版，必须手动安装：GitHub 搜
seanliang/ConvertToUTF8，下载 zip 解压后重命名为ConvertToUTF8，拖进Packages目录，重启生效 - 插件默认不自动启用，首次需手动打开一个 GBK 文件触发检测；它对只读文件、无写入权限路径完全无效
- 别信“一键批量转码”——一旦某文件实际是 UTF-8-BOM 却被误判为 GBK，转完就毁了，且不可逆
最麻烦的从来不是操作步骤，而是得先判断文件原本是什么编码。尤其混合了 UTF-8-BOM、GBK、ANSI 的老项目里，“哪个文件该用哪种方式打开”没有银弹，只能靠 file -i 或 Notepad++ 辅助验证。别省这一步，否则后面全是补救。
