Sublime Text 无官方汉化包，解决中文乱码的关键是正确识别并转换文件编码：先用Reopen with Encoding匹配原始编码（如Chinese (GBK)），再Save with Encoding→UTF-8转存；ST4用户应弃用ConvertToUTF8，改用Codecs37插件，并正确配置fallback_encoding为"Chinese (GBK)"。
Sublime Text 本身没有官方汉化包，所谓“汉化”基本是误操作或第三方非正规修改，反而极易引发乱码。真正要解决的不是“汉化”，而是让中文内容能被正确读取、编辑和保存——核心在编码匹配，不在界面语言。
Reopen with Encoding 是唯一可靠的救急动作
打开一个显示“锟斤拷”或方块的文件后，右下角显示的 UTF-8 或 Western (ISO 8859-1) 只是 Sublime 当前的解码方式，不是文件真实编码。盲目切换状态栏、改 default_encoding 都无效。
- 立刻点击右下角当前编码名 → 选
Reopen with Encoding→Chinese (GBK) - 如果还不对，依次试
Chinese (GB2312)、Western (Windows 1252)；只要中文一出来，右下角变成Chinese (GBK)，就说明原始编码识别成功 - 这个操作只影响内存显示，不写磁盘，安全可逆
- 千万别反复点状态栏切换——那是用错解码器去解释一堆已错解的字节，只会越来越乱
Save with Encoding → UTF-8 才是真转码，且必须分两步走
Save with Encoding 是唯一真正修改磁盘文件的动作，但它的前提是：内存里已经是正确解码的 Unicode 内容。跳过上一步直接点它，等于把乱码再按 UTF-8 编码一遍，结果是双乱码，不可逆。
- 必须在
Reopen with Encoding → Chinese (GBK)确认中文完全正常后，再执行Save with Encoding → UTF-8（注意不是UTF-8 with BOM） - 保存后关闭再重开，右下角应显示
UTF-8，且中文依然正常 - 若别人用记事本打开仍是乱码，说明上一步没识别对原始编码，文件根本没被正确还原
- 验证是否真去除了 BOM：
xxd 文件名 | head -n1，输出不含ef bb bf才算干净
ST4 用户请彻底放弃 ConvertToUTF8，改用 Codecs37
Sublime Text 4（Build 4126+）已内置 GBK/GB18030 自动探测能力。ConvertToUTF8 不仅停更，还会干扰原生逻辑：状态栏编码名消失、右键菜单失效、配置入口找不到，甚至让原本能自动识别的文件反而乱码。
- 通过
Package Control: Install Package搜索并安装Codecs37（目前唯一持续维护、支持 30+ 编码的现代插件） - 安装后无需任何配置，打开 GBK 文件即显示正常，右下角明确标出
Chinese (GBK) - 若仍乱码，大概率是文件本身非纯 GBK（如混用 GB2312、含异常控制字符），此时手动走
Reopen with Encoding流程更可靠 - ST4 中
fallback_encoding已被移除，设了也无效；真正控制保存行为的是default_encoding_on_save，应设为"UTF-8"
用户设置里 fallback_encoding 必须写对标识符，不能写标准编码名
fallback_encoding 字段只接受 Sublime 内置的编码标识符，比如 "Chinese (GBK)"，写 "GBK" 或 "UTF-8" 都是无效配置，等于没设。
- 推荐配对使用：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)" -
default_encoding已被官方标记为“已弃用”，它只影响新建空文件右下角显示的编码标识，以及“另存为”对话框默认选中的编码项 - 务必删掉配置中可能存在的
"detect_encoding": true——它会让 Sublime 主动跳过 BOM 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码 - 加一行
"save_with_bom": false，否则保存后 Python/Git 会报Non-UTF-8 code starting with '\xef'
最常被忽略的一点：你看到的乱码从来不是文件损坏，而是 Sublime 用错了钥匙开门。所有操作都围绕“先读对、再存对”展开，插件只是辅助，不是替代判断。一旦依赖插件自动识别，就容易在混合编码、无 BOM、GB18030 变体等边界场景里翻车。
