应先用file -i（Linux/macOS）或Notepad++（Windows）确认文件真实编码，再通过Reopen with Encoding临时解码、Save with Encoding转存；用户设置中需配对使用"default_encoding": "UTF-8"和"fallback_encoding": "Chinese (GBK)"，并禁用detect_encoding和save_with_bom。
Sublime Text 中文乱码不是字体或系统语言问题，而是解码方式和保存编码不匹配导致的——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才算干净 - 必须加这行配置：
"save_with_bom": false，只靠"default_encoding": "UTF-8"不够 - Windows 记事本另存为“UTF-8”，实际存的是 UTF-8 with BOM；Sublime 对 BOM 敏感，有时反而不如无 BOM 稳定
真正麻烦的不是操作步骤，而是得先判断文件原本是什么编码——尤其混合了 UTF-8-BOM、GBK、ANSI 的项目里，一个一个试才是常态。BOM、混合编码、插件劫持、缓存记忆……这些干扰项不会报错，但会让设置看起来“没生效”。
