Sublime中文乱码主因是解码与保存编码不匹配，需先用file -i（Linux/macOS）或Notepad++（Windows）确认真实编码，再通过Reopen with Encoding试读、Save with Encoding转存，禁用detect_encoding并设"default_encoding":"UTF-8"、"fallback_encoding":"Chinese (GBK)"、"save_with_bom":false。
Sublime 中文乱码不是字体或系统语言问题，而是解码方式和保存编码不匹配导致的——90% 的“乱码”根本没改错地方，只是在瞎试编码。
怎么确认文件真实编码，而不是靠猜
Sublime 右下角显示的 UTF-8 或 Western (ISO 8859-1) 只是它当前怎么读这个文件，不是文件本来就是这个编码。满屏方块时，它可能正用 UTF-8 解一个 GBK 文件。
- Linux/macOS 下直接运行：
file -i 文件名，看输出里的charset=字段（如charset=gbk） - Windows 用户用
Notepad++打开 → 右下角明确显示 “GBK” 或 “UTF-8-BOM”，比 Sublime 更可信 - 别信网上说的“用 Python 脚本检测”——短文本、混合编码、BOM 干扰下，纯字节分析误判率极高
Reopen with Encoding 和 Save with Encoding 到底该点哪个
这是最常点错的两个菜单项，功能完全相反，点错一次就可能把能读的文件“转坏”。
-
Reopen with Encoding：只改当前视图怎么读文件，不写磁盘，安全。适合乱码后立刻试Chinese (GBK)、UTF-8、GB2312，看到中文就停 -
Save with Encoding：真把当前视图内容按新编码重写到磁盘，不可逆。必须在Reopen with Encoding确认显示正常后才用 - 千万别点
Convert to UTF-8（老版本菜单里有）——它会静默重写，且不提示，原始编码信息直接丢失
用户设置里 fallback_encoding 为什么不能写 "UTF-8"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置，等于没设。Sublime 只认自己内置的编码标识符。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"或"Western (ISO 8859-1)" -
default_encoding才支持"UTF-8"，它管新建文件和显式保存时的默认编码 - 推荐配对使用：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)"，兼顾新文件和旧项目乱码文件 - 顺手删掉配置里可能存在的
"detect_encoding": true—— 这个开关会让 Sublime 主动跳过 UTF-8 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码
保存后其他工具报错 Non-UTF-8 code starting with '\xef'
这不是 Sublime 没设对，而是它悄悄加了 UTF-8 BOM（\xef\xbb\xbf），Python、Git、Shell 脚本都把它当非法字符。
- 检查是否生效：
xxd 文件名 | head -n1，输出不含ef bb bf才算干净 - 关掉 BOM：在用户配置里加
"save_with_bom": false，只靠"default_encoding": "UTF-8"不够 - 如果已用
Save with Encoding → UTF-8保存过，但状态栏仍显示UTF-8 with BOM，说明配置没生效或被插件覆盖
真正麻烦的从来不是操作步骤，而是得先判断文件原本是什么编码——尤其混合了 UTF-8-BOM、GBK、ANSI 的老项目里，“猜”和“一键转”最容易固化双重乱码。
