Reopen with Encoding → Chinese (GBK) 是唯一能立刻让乱码文件变正常的动作；它强制Sublime用GBK规则重读磁盘字节流，使“锟斤拷”变中文，且不修改磁盘文件。
Reopen with Encoding 是唯一能立刻让乱码文件变正常的动作
汉化本身不会导致乱码——乱码只发生在“用错编码读文件”的那一刻。你看到的方块、问号或“锟斤拷”，说明 Sublime 正在拿 UTF-8 规则去解一个实际是 GBK 的字节流。汉化只是改了菜单文字，不影响底层编码逻辑。
为什么右下角显示 UTF-8 却还是乱码？
右下角显示的 UTF-8 只是 Sublime 当前用什么方式“解释”这个文件，不是文件真实编码。它根本没猜对原始编码，所以越切换越乱。别点状态栏反复试，那是在拿错误解码结果再错解一遍。
怎么确认文件真是 GBK 而不是 UTF-8？
靠猜会翻车。必须验证：
- Linux/macOS 下运行
file -i 文件名，看输出里charset=gbk或charset=gb18030 - Windows 用户直接用 Notepad++ 打开，右下角明确显示
GBK或GB2312（比 Sublime 更可信） - 绝对别信
detect_encoding: true：它会跳过 BOM 直接试 GBK，把带 BOM 的UTF-8文件判成乱码
Reopen with Encoding → Chinese (GBK) 后还乱码？
说明原始编码不是 GBK，但大概率是这几个之一：
-
Chinese (GB2312)：老式简体中文文档常见 -
Western (Windows 1252)：部分 Windows 记事本保存的 ANSI 文件 -
Chinese (BIG5)：繁体中文环境生成的文件 -
CP936：Windows 下GBK的别名，有些版本菜单里叫这个
只要中文一出来，右下角变成对应编码名，就说明内存里已正确解码——此时磁盘文件一字未动。
Save with Encoding → UTF-8 之前必须检查三件事
这是唯一真正改磁盘的动作，点错等于固化乱码：
- 必须等中文完全正常显示后再点，不能将就“差不多能认”
- 选
UTF-8，不是UTF-8 with BOM；BOM 会导致 Python 报Non-UTF-8 code starting with '\xef' - 保存后关闭再重开，右下角应显示
UTF-8且中文不丢——如果别人用记事本打开还是乱码，说明上一步根本没识别对原始编码
真正的麻烦不在操作步骤，而在于：同一个项目里可能混着 UTF-8-BOM、GBK、GB18030 甚至带异常控制字符的文件，得一个一个手动验证。自动插件（比如 ConvertToUTF8）在 Sublime Text 4 中已不可靠，状态栏不显示、右键失效、配置项消失都是常态——别把它当救命稻草，先练熟 Reopen with Encoding 和 Save with Encoding 这两个原生动作。
