sublime中文乱码与汉化无关，本质是文件真实编码（如gbk）与当前解码方式（如utf-8）不匹配；须先用file -i或notepad++确认真实编码，再通过reopen with encoding正确解码，最后save with encoding转存，配置需设"default_encoding": "utf-8"、"fallback_encoding": "chinese (gbk)"并禁用save_with_bom。
Sublime 在汉化环境下出现中文乱码，和是否汉化完全无关——它只是界面语言变了，底层编码逻辑没动。真正卡住你的，是文件真实编码（比如 GBK）和 Sublime 当前解码方式（比如 UTF-8）不匹配。修复核心就两条：先确认真实编码，再让 Sublime 用对的方式读。
怎么确认文件真实编码，而不是信右下角显示的“UTF-8”
Sublime 状态栏右下角写的“UTF-8”，只是它此刻正在用什么规则解析内存里的字节，不是文件本来的编码。满屏“锟斤拷”时，它很可能正拿 UTF-8 去解一个 GBK 文件。
- Linux/macOS 下直接运行：
file -i 文件名，看输出里charset=gbk或charset=utf-8 - Windows 用户用 Notepad++ 打开 → 右下角明确显示“GBK”或“UTF-8-BOM”，比 Sublime 更可信
- 别信网上那些 Python 脚本检测工具：短文本、混合内容、BOM 干扰下，误判率极高
Reopen with Encoding 和 Save with Encoding 到底怎么用
这两个菜单项功能相反，点错一次就可能把能读的文件“转坏”。关键不是猜，是按顺序操作：
-
Reopen with Encoding：只改当前视图怎么读，不写磁盘，安全。乱码后立刻试Chinese (GBK)、UTF-8、Chinese (GB2312)，看到中文就停 -
Save with Encoding：真把当前内容按新编码重写到磁盘，不可逆。必须等Reopen with Encoding显示正常后才点，否则乱码会被固化 - 绝对别点
Convert to UTF-8（老版本菜单里有）：静默重写，不提示，原始编码信息直接丢
用户设置里 fallback_encoding 怎么配才生效
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 或 "GBK" 是无效配置，等于没设。它只认 Sublime 内置的编码标识符。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"（注意大小写和括号） - 这个设置只在“无 BOM + 自动检测失败”时触发；带 UTF-8 BOM 的文件仍走 UTF-8，不会触发 fallback
- 必须配对使用：
"default_encoding": "UTF-8"（管新建和保存）+"fallback_encoding": "Chinese (GBK)"（管旧项目乱码文件） - 顺手删掉配置里可能存在的
"detect_encoding": true——它会让 Sublime 主动跳过 BOM 去试 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"不够 - 如果已装 ConvertToUTF8 插件，注意它默认保存回原编码（即 GBK）；如需统一存为 UTF-8，得把
"save_to_original_encoding"设为false
最常被忽略的一点：fallback_encoding 不是万能兜底，它只对无 BOM 且自动检测失败的文件起作用；而 Windows 下大量 GBK 文件根本不满足这个条件，必须手动切一次 Reopen with Encoding —— 配置再全，也绕不开这一步实操。
