sublime text中文乱码的根本原因是编码错配，需先用file -i（linux/macos）或notepad++（windows）确认文件真实编码，再通过reopen with encoding选对解码方式（如chinese (gbk)）使内容正常显示，最后用save with encoding→utf-8转存，并配置"default_encoding": "utf-8"、"fallback_encoding": "chinese (gbk)"及"save_with_bom": false。
Sublime Text 显示中文乱码，不是文件坏了，也不是编辑器出问题，而是它用错了编码去读你的文件——比如拿 UTF-8 的规则去解一个 GBK 字节流，结果必然满屏方块。真正能快速修复的，从来不是装插件或调字体，是先确认真实编码，再选对解码方式。
怎么确认文件真实编码，而不是瞎猜
Sublime 右下角显示的“UTF-8”只是它当前用什么解码，并不等于文件就是 UTF-8。你看到方块字，恰恰说明它正在用错的方式读。
- Linux/macOS 下运行
file -i 文件名，看输出里的charset=字段（例如charset=gbk或charset=utf-8） - Windows 用户直接用 Notepad++ 打开 → 右下角明确显示“GBK”“UTF-8-BOM”等，比 Sublime 更可信
- 别信
detect_encoding: true：这个设置会让 Sublime 主动跳过 BOM 去试 GBK，反而把带 BOM 的UTF-8文件判成乱码，建议删掉
Reopen with Encoding 和 Save with Encoding 别点反了
这两个菜单项功能完全相反，点错一次就可能把能读的文件“转坏”。
-
Reopen with Encoding：只改当前视图怎么读文件，不改磁盘内容，安全。适合乱码后快速试Chinese (GBK)、UTF-8、GB2312，看到中文就停 -
Save with Encoding：真把当前视图内容按新编码重写到磁盘，不可逆。必须在Reopen with Encoding确认显示正常后才用 - 绝对别点
Convert to UTF-8（老版本菜单里有）：它会静默重写文件且不提示，原始编码信息直接丢失
fallback_encoding 为什么不能写 "UTF-8"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置，等于没设。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"或"Western (ISO 8859-1)"，这些是 Sublime 内部注册的编码标识符 -
default_encoding才支持"UTF-8"，它管新建文件和显式保存时的默认编码 - 推荐组合：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)"，兼顾新建文件和旧项目乱码文件 - 顺手加一行
"save_with_bom": false，否则保存后 Python/Git 会报Non-UTF-8 code starting with '\xef'
ConvertToUTF8 插件要不要装
它确实能自动识别 GBK 并转成 UTF-8 显示，但风险边界很清晰：
- Package Control 官方仓库早已下架它，现在搜到的多是过期镜像或非官方 fork，安装前务必确认来源是
seanliang/ConvertToUTF8（最后更新于 2020） - 默认配置下，它会静默把编辑后的内容按原编码（
GBK）写回磁盘，但若你误设了"save_to_original_encoding": false，就会无提示覆盖成UTF-8，原始GBK文件信息永久丢失 - 旧版插件（尤其 ST3）可能跳过备份直接重写，卸载后残留的
Preferences → Package Settings → ConvertToUTF8 → Settings配置仍会干扰原生逻辑 - 它无法处理带 BOM 的
UTF-8文件，反而因detect_encoding: true设置导致这类文件被误判为乱码
真正容易被忽略的是：所有操作都依赖你对“当前视图解码”和“磁盘实际字节”的区分。一旦混淆这两者，哪怕配置全对，也会反复踩坑。
