汉化本身不会导致乱码，乱码只和编码解析逻辑有关——你看到的“中文变方块”，是 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)" 完全无效。真正控制保存行为的是：

Sublime Text Build Linux版

Sublime Text Linux x86-64 deb 安装包。官方也提供 rpm、tar.xz 和软件源安装方式。

下载

• 在 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 提交、脚本调用都会出问题。