汉化插件不会导致乱码，乱码源于原有编码问题或误操作；st4已废弃fallback_encoding，应使用codecs37插件自动识别gbk等编码，save with encoding→utf-8前须先reopen with正确编码。
汉化插件本身不会导致乱码——它只改界面语言，不碰文件编码逻辑。你看到的“乱码”，其实是原本就存在的编码问题被暴露出来，或者汉化后误操作触发了错误解码流程。
为什么汉化后突然乱码？
汉化包只是把菜单、对话框翻译成中文，和文件读取无关。但用户常在汉化后顺手点右下角“UTF-8”→选“中文（GBK）”，结果发现更乱；或以为“界面中文了，文件也该是 UTF-8”，盲目 Save with Encoding → UTF-8，把原本正常的 GBK 文件二次损坏。
- 汉化前后，Sublime 解析文件的方式完全没变——还是靠
default_encoding、fallback_encoding和 BOM 判断 - 真正出问题的，是汉化后你更容易去点状态栏、更容易信“右下角写的那个就是文件编码”
- ST4 已移除
fallback_encoding，但很多汉化教程还在抄旧配置，加了等于白加
Reopen with Encoding 选错编码反而更乱怎么办
点完 Chinese (GBK) 出现“锟斤拷”变“”或整行偏移，说明原始编码不是 GBK。别保存，立刻关掉重开，换其他选项试。
- 先用外部工具确认真实编码：
file -i 文件名（Linux/macOS），或 Notepad++ 打开看右下角（Windows） - 常见误判组合：
Chinese (GB2312)对 GBK 文件有时更准；Western (Windows 1252)对老旧记事本生成的混合文件有效 - 如果试遍所有中文选项都乱，可能是文件含
GB18030变体或损坏 BOM，建议先用 Notepad++ “转为 UTF-8 无 BOM”再回 Sublime
ST4 用户配 fallback_encoding 完全无效
Sublime Text 4.4+ 彻底废弃 fallback_encoding 字段。你在设置里写 "fallback_encoding": "Chinese (GBK)"，编辑器直接忽略。
- ST4 真正控制保存行为的是
default_encoding_on_save（仅影响 Ctrl+S），而default_encoding已被标记为“已弃用”，只影响新建空文件右下角显示 - 若要让旧项目 GBK 文件打开即正常，必须用插件：优先选
Codecs37（持续维护、支持 GB18030/Shift-JIS 等 30+ 编码），而非早已停更的ConvertToUTF8 -
Codecs37安装后无需配置，打开 GBK 文件自动识别，状态栏直接标出GBK，比手动 Reopen 更可靠
Save with Encoding → UTF-8 后别人打不开？
保存后用记事本打开仍是乱码，说明这步根本没生效——文件磁盘内容还是 GBK，只是 Sublime 当前视图用了 UTF-8 解码规则。
- 关键检查点：
xxd 文件名 | head查开头是否有\xef\xbb\xbf（UTF-8 BOM）。有，说明你误点了UTF-8 with BOM；没有，说明压根没成功保存为 UTF-8 - ST4 中，
Save with Encoding → UTF-8是唯一真正写入 UTF-8 字节的动作，但前提是：必须先用Reopen with Encoding让内存内容正确解码成 Unicode，否则存进去的就是“锟斤拷”的 UTF-8 编码 - 别依赖“状态栏显示 UTF-8”——那只是当前解码方式，不是磁盘内容。关掉再重开，能继续显示中文才算真正转成功
最易被忽略的一点：同一个项目里可能混着 UTF-8、GBK、甚至带 BOM 的 UTF-8 文件。别指望一个设置或一个插件通吃，得逐个文件确认真实编码再操作。
