汉化补丁本身不会导致文件内容乱码，只改界面语言；菜单乱码或显示英文是因font_face未配置或系统字体缺失，打开中文文件乱码则源于fallback_encoding设错或未用Reopen with Encoding匹配真实编码。
汉化补丁本身不会导致文件内容乱码——它只改界面语言，不碰文件编码逻辑。所谓“汉化后菜单乱码”或“打开中文文件变方块”，99% 是系统字体、渲染配置或用户设置没对上，不是补丁的问题。
菜单显示□或英文：检查 font_face 和系统字体注册
Sublime Text 汉化后菜单出现方块（□）、空白或回退成英文，核心原因是界面文本无法被当前 font_face 渲染。它和文件乱码无关，是纯 UI 层面的字体链断裂。
- Windows 用户必须确认系统已注册
Microsoft YaHei（微软雅黑），且未被禁用：打开“控制面板 → 字体”，搜索“Microsoft YaHei”，确保存在；PowerShell 运行[System.Text.Encoding]::UTF8.WebName应返回utf-8 - macOS 用户需验证 locale：终端执行
locale | grep -E "(LANG|LC_ALL)"，输出中必须含UTF-8，不能是en_US.ISO8859-1 - 用户设置（
Preferences → Settings – User）中必须显式声明："font_face": "Microsoft YaHei"（Windows）或"font_face": "PingFang SC"（macOS）。只装汉化包不设字体，等于没配
打开中文文件仍乱码：和汉化完全无关，重点查 fallback_encoding 配置
汉化补丁不影响文件读取流程。你看到的“锟斤拷”或满屏问号，是 Sublime 用错解码器读了 GBK 文件——跟菜单语言是中文还是英文毫无关系。
-
fallback_encoding必须写成"Chinese (GBK)"，不是"GBK"或"utf-8"；写错等于没设，Sublime 会默认用Western (Windows 1252)去解中文，必然失败 - 必须配对使用：
"default_encoding": "UTF-8"（管新建/保存） +"fallback_encoding": "Chinese (GBK)"（管旧项目自动探测） - 删掉配置里任何
"detect_encoding": true——这个开关在 ST4+ 上反而会绕过 BOM，把带 BOM 的 UTF-8 文件误判为 GBK，引发新乱码
Reopen with Encoding 点了没反应？先确认真实编码再试
右下角显示 UTF-8 不代表文件真是 UTF-8。它只是 Sublime 当前的解码假设。点 Reopen with Encoding 没效果，大概率是你在瞎试，而不是按真实编码来。
- Linux/macOS 下用命令确认：
file -i 文件名，看输出中的charset=gbk或charset=utf-8 - Windows 用户用 Notepad++ 打开，右下角明确显示的编码（如
GBK、UTF-8-BOM）比 Sublime 更可信 - 点菜单时只试三个选项：
Chinese (GBK)、UTF-8、Chinese (GB2312)；只要中文一出来，右下角变成对应标识，就说明找对了 - 绝对别点
Convert to UTF-8（老版本菜单项）——它静默重写，不提示，原始编码信息直接丢
最常被忽略的一点：save_with_bom 默认为 true，保存后文件头部会多出 \xef\xbb\xbf，导致 Python/Git 报 Non-UTF-8 code starting with '\xef'。必须在用户设置里加 "save_with_bom": false，并用 xxd 文件名 | head -n1 验证是否真去掉了 BOM。
