代码区中文乱码与汉化无关，主因是文件编码（如GBK）与编辑器解码方式（如UTF-8）不匹配；应先用Reopen with Encoding→Chinese (GBK)正确识别原始编码，再Save with Encoding→UTF-8转存。
Sublime Text 汉化后代码区域出现中文乱码（如“锟斤拷”、方块、问号），和汉化本身完全无关。界面语言变中文，只影响菜单和对话框；代码区乱码是文件编码与编辑器解码方式不匹配导致的——大概率是你用 UTF-8 解了一个实际是 GBK 的文件。
Reopen with Encoding 选错原始编码就永远看不到中文
右下角显示的 UTF-8 或 Western (ISO 8859-1) 只是当前解码方式，不是文件真实编码。乱码时它正在错读，所以不能信状态栏。
- 立刻执行
File → Reopen with Encoding → Chinese (GBK)（有时也叫CP936） - 如果仍乱码，再试
Chinese (GB2312)或Western (Windows 1252)；只要中文一出来，右下角变成Chinese (GBK)，就说明原始编码识别对了 - 菜单里没出现
Chinese (GBK)？说明缺失基础编码支持——去Preferences → Browse Packages…手动放入GBK Support插件目录（别依赖 Package Control 搜到的过期镜像） - 别点
Convert to UTF-8（老版本菜单项）：它静默重写磁盘，原始编码信息直接丢
Save with Encoding → UTF-8 是唯一真正转码动作
前面所有操作都只改内存显示，不碰磁盘。只有这一步才把当前已正确解码的 Unicode 内容，按新编码写回文件。
- 必须等
Reopen with Encoding后中文完全正常，再执行File → Save with Encoding → UTF-8（注意：不是UTF-8 with BOM） - 保存后关闭重开，右下角应显示
UTF-8且中文仍正常；如果别人用记事本打开还是乱码，说明上一步根本没识别对原始编码 - 验证是否真去除了 BOM：
xxd 文件名 | head -n1，输出不含ef bb bf才算干净 - 若保存失败或静默丢字，可能是文件含
GB18030混合变体或异常控制字符，建议先用 Notepad++ 转一次再回Sublime Text
用户设置里 fallback_encoding 必须写对标识符
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 或 "GBK" 是无效配置，等于没设。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"（注意括号、空格、大小写） - 它只在“无 BOM + UTF-8 解码报错”时触发，不是默认编码；
default_encoding已弃用，仅影响新建空文件右下角显示 - 推荐配对使用：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)"+"save_with_bom": false - 务必删掉配置中可能存在的
"detect_encoding": true——它会让Sublime Text主动跳过 BOM 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码
ST4 用户注意：fallback_encoding 已失效
Sublime Text 4 彻底移除了 fallback_encoding，所谓“全局兜底编码”不复存在。你加了也白加。
- 真正控制保存行为的是
default_encoding_on_save：设为"UTF-8"（注意大小写和短横），就能强制所有Ctrl+S静默以 UTF-8 写入磁盘 -
default_encoding仅影响新建文件和“另存为”对话框默认选项，不影响实际保存 - 混合编码项目（同一目录下既有 UTF-8 脚本又有 GBK 配置）无法靠全局设置解决，得靠右下角手动切编码，或用项目专属
.sublime-project绑定规则
最麻烦的其实是混合编码项目——全局配置再完美，也救不了一个目录里同时混着 UTF-8 Python 脚本和 GBK ini 配置的场景。这点不提前用 .sublime-project 锁死规则，等 git commit 报错才反应过来，就晚了。
