Sublime中文乱码主因是编码错配，须先用file -i（Linux/macOS）或Notepad++（Windows）确认文件真实编码，再Reopen with Encoding匹配解码，最后Save with Encoding→UTF-8转存，并配置"default_encoding": "UTF-8"、"save_with_bom": false，ST4中fallback_encoding已失效。
汉化本身不会导致乱码——它只改界面语言，不碰文件编码逻辑。真正出问题的，是 Sublime 用 UTF-8 去解一个实际为 GBK 的文件，结果满屏“锟斤拷”或方块。
怎么确认文件真实编码，而不是信右下角显示的“UTF-8”
Sublime 状态栏右下角写的“UTF-8”，只是它此刻正在用什么规则解析内存里的字节，不是文件本来的编码。你看到乱码，恰恰说明它读错了。
- Linux/macOS 下直接运行：
file -i 文件名，看输出里charset=gbk或charset=utf-8 - Windows 用户用 Notepad++ 打开 → 右下角明确显示“GBK”或“UTF-8-BOM”，比 Sublime 更可信
- 别信网上那些 Python 脚本检测工具：短文本、混合内容、BOM 干扰下，误判率极高
Reopen with Encoding 和 Save with Encoding 到底怎么用
这两个菜单项功能相反，点错一次就可能把能读的文件“转坏”。关键不是猜，是按顺序操作：
-
Reopen with Encoding：只改当前视图怎么读，不写磁盘，安全。乱码后立刻试Chinese (GBK)、UTF-8、Chinese (GB2312)，看到中文就停 -
Save with Encoding：真把当前内容按新编码重写到磁盘，不可逆。必须等Reopen with Encoding显示正常后才点，否则乱码会被固化 - 绝对别点
Convert to UTF-8（老版本菜单里有）：静默重写，不提示，原始编码信息直接丢
用户设置里 fallback_encoding 怎么配才生效
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 或 "GBK" 是无效配置，等于没设。它只认 Sublime 内置的编码标识符。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"（注意大小写和括号） - 这个设置只在“无 BOM + 自动检测失败”时触发；带 UTF-8 BOM 的文件仍走 UTF-8，不会触发 fallback
- 必须配对使用：
"default_encoding": "UTF-8"（管新建和保存）+"fallback_encoding": "Chinese (GBK)"（管旧项目乱码文件） - 顺手删掉配置里可能存在的
"detect_encoding": true——它会让 Sublime 主动跳过 BOM 去试 GBK，反而把带 BOM 的 UTF-8 判成乱码
Sublime Text 4 用户特别注意：fallback_encoding 已失效
ST4 彻底移除了 fallback_encoding，所谓“全局兜底编码”不复存在。你加 "fallback_encoding": "Chinese (GBK)" 到设置里，完全无效。
- 真正控制保存行为的是
default_encoding_on_save：设为"UTF-8"（注意大小写和短横），就能强制所有Ctrl+S静默以 UTF-8 写入磁盘 -
default_encoding已被官方标记为“已弃用”，它只影响新建空文件右下角显示的编码标识，不控制Ctrl+S的实际写入编码 - 务必加
"save_with_bom": false，否则保存后 Python/Git 会报Non-UTF-8 code starting with '\xef'
最常被忽略的一点：确认文件是否真的被转成了 UTF-8 无 BOM。保存后运行 xxd 文件名 | head -n1，输出不含 ef bb bf 才算干净。否则其他工具（尤其是 Python 脚本）会把它当非法字符处理。
