汉化本身不会导致乱码，乱码只和编码解析逻辑有关——你看到的“中文变方块”，是 Sublime 用 UTF-8 去读一个实际为 GBK 的 .txt 文件所致。
汉化本身不会导致乱码，乱码只和编码解析逻辑有关——你看到的“中文变方块”，是 Sublime 用 UTF-8 去读一个实际为 GBK 的 .txt 文件所致。
右下角显示 UTF-8 却满屏方块？先别改设置，立刻 Reopen with Encoding
状态栏显示的 “UTF-8” 只是当前解码方式，不是文件真实编码。Windows 记事本默认存为 GBK（无 BOM），Sublime 直接拿 UTF-8 解，两个字节被当一个字符，必然崩坏。
- 点击右下角当前编码名（如
UTF-8或Western (ISO 8859-1)）→ 选Reopen with Encoding→Chinese (GBK) - 若仍乱码，换试
Chinese (GB2312)；千万别选Western (Windows 1252)（它不含中文） - 只要中文一出来、右下角变成
Chinese (GBK)，就说明原始编码识别对了 - 此时内存内容已正确解码，但磁盘文件一字未动——这是救回乱码的唯一前提
Convert to UTF-8 和 Save with Encoding 别搞混
很多人点状态栏选 Convert to UTF-8，结果发现保存后别人用记事本打开还是乱码。这是因为：
-
Convert to UTF-8只在内存中重编码，不写入磁盘（旧版菜单里有，ST4 已移除） - 真正改磁盘字节的是
Save with Encoding→UTF-8（注意：不是UTF-8 with BOM） - 必须在
Chinese (GBK)下确认中文完全正常后，再执行这一步，否则会把乱码二次编码成不可逆的双乱码（如ä½ å¥½） - 保存后可用
xxd 文件名 | head -n1检查开头：不含\xef\xbb\xbf才算干净 UTF-8
ST4 用户注意：fallback_encoding 已失效，default_encoding_on_save 才管用
Sublime Text 4 彻底移除了 fallback_encoding，你在用户设置里加 "fallback_encoding": "Chinese (GBK)" 完全无效。真正控制保存行为的是：
- 在
Preferences → Settings右侧用户设置中添加："default_encoding_on_save": "UTF-8"（大小写、短横必须严格匹配） -
default_encoding已弃用，它只影响新建空文件右下角显示和“另存为”对话框默认项 - 禁用
detect_encoding: true——它会让 Sublime 主动跳过 BOM 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码 - 不要写
save_with_encoding或save_encoding，这些不是原生命令，会导致配置报错
混合编码项目里，全局设置根本不够用
同一目录下既有 UTF-8 脚本又有 GBK 配置文件时，靠改全局配置只会顾此失彼。最稳妥的方式是：
- 右下角手动切编码：打开文件后点状态栏 →
Reopen with Encoding临时指定 - 或建
.sublime-project文件，在settings里按路径绑定规则，例如："syntax_override": {"*.conf": "Chinese (GBK)"} - 插件如
ConvertToUTF8在 ST4 上易与原生逻辑冲突，状态栏编码显示错乱，不推荐新项目使用 - 如果文件含 GB18030 混合变体或异常控制字符，先用 Notepad++ 转一次再导入 Sublime，避免静默丢字
真正麻烦的从来不是单个乱码文件，而是没意识到 Sublime 不会自动猜编码——它只按你明确指定的方式读字节。每一份 GBK 文件都得手动告诉它“请用 GBK 规则重读”，少这一步，后续所有保存、Git 提交、脚本调用都会出问题。
