sublime text中文乱码需先reopen with encoding选对原始编码（如chinese (gbk)），再save with encoding→utf-8转存；右下角显示编码仅为当前解码方式，非文件真实编码，须用file -i或notepad++确认。
Sublime Text 中文乱码不是字体或系统语言问题，而是它用 UTF-8 去解一个实际是 GBK 的字节流——结果必然是满屏“锟斤拷”或方块。解决它不需要装一堆插件，核心就两步：Reopen with Encoding 选对原始编码，再 Save with Encoding → UTF-8 真正转存。
怎么确认文件真实编码而不是瞎猜
Sublime 右下角显示的 UTF-8 或 Western (ISO 8859-1) 只是它当前怎么读这个文件，不是文件本来就是这个编码。你看到乱码，恰恰说明它正在用错的方式读。
- Linux/macOS 下直接运行：
file -i 文件名，看输出里的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)、Chinese (GB2312)、Western (Windows 1252)，看到中文就停 -
Save with Encoding：真把当前视图内容按新编码重写到磁盘，不可逆。必须在Reopen with Encoding确认显示正常后才用 - 绝对别点
Convert to UTF-8（老版本菜单里有）：它会静默重写文件且不提示，原始编码信息直接丢失
ST4 用户慎用 ConvertToUTF8 插件
Sublime Text 4（Build 4100+）已内置 GBK/Big5 自动探测，多数场景下 ConvertToUTF8 反而会干扰原生逻辑，导致状态栏编码显示错乱或保存行为异常。
- Package Control 里搜到的
ConvertToUTF8几乎全是过期镜像或改名版（如CTU8），有兼容风险 - 正确做法是去 GitHub 搜
seanliang/ConvertToUTF8（最后更新于 2020），下载 zip 手动安装；但 ST4.4+ 用户更推荐Codecs37 -
Codecs37支持GBK/GB18030/UTF-8-BOM/Shift-JIS等 30+ 编码，持续维护，安装后无需额外配置
用户配置里 fallback_encoding 为什么不能写 "UTF-8"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置，等于没设。Sublime 只认自己内置的编码标识符。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"或"Western (ISO 8859-1)" -
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'
真正容易被忽略的是：Sublime 会记住每个文件上次用的编码，关掉重开仍沿用——所以改完设置不会自动生效，必须手动对每个乱码文件执行一遍 Reopen with Encoding → Save with Encoding 流程。
