sublime text中文乱码的根本原因是用utf-8解码gbk字节流，正确修复路径是：先执行reopen with encoding → chinese (gbk)使内容可读，再save with encoding → utf-8转存磁盘文件；fallback_encoding须设为"chinese (gbk)"，default_encoding已弃用，禁用detect_encoding:true。
Sublime Text 中文乱码不是文件损坏，也不是编辑器坏了，而是它用 UTF-8 去解一个实际是 GBK 的字节流——结果必然是“锟斤拷”或方块。真正有效的修复路径只有一条：先让内容能看懂，再决定要不要改磁盘文件。
Reopen with Encoding → Chinese (GBK) 是唯一救急动作
打开乱码文件后，右下角显示的 “UTF-8” 或 “Western (ISO 8859-1)” 只是 Sublime 当前怎么读这个文件，不是文件真实编码。盲目点状态栏切换、改 default_encoding 都没用。
- 立刻执行
File → Reopen with Encoding → Chinese (GBK)（有时也叫CP936） - 如果还是乱码，再试
Chinese (GB2312)或Western (Windows 1252)；只要中文一出来，右下角变成Chinese (GBK)，就说明原始编码识别对了 - 千万别点
Convert to UTF-8（老版本菜单里有）——它会静默重写文件且不提示，原始编码信息直接丢失 - 确认显示正常后，内存里已经是正确解码的 Unicode 内容，磁盘文件一字未动
Save with Encoding → UTF-8 才是真正转码动作
前面所有操作都只影响显示，只有这一步才改磁盘文件。跳过 Reopen with Encoding 直接点它，等于把乱码再编码一遍，变成双乱码。
- 必须在中文显示完全正常后，再执行
File → Save with Encoding → UTF-8（注意：不是UTF-8 with BOM） - 保存后关闭再重开，右下角应显示
UTF-8，且中文依然正常；如果别人用记事本打开还是乱码，说明上一步没做对——文件根本没被正确识别为 GBK - 验证是否真去除了 BOM：
xxd 文件名 | head -n1，输出不含ef bb bf才算干净 - 若保存失败或静默丢字，可能是文件含 GB18030 混合变体或异常控制字符，建议先用 Notepad++ 转一次再回 Sublime 验证
用户设置里 fallback_encoding 必须设为 "Chinese (GBK)"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置。Sublime 只认自己内置的编码标识符，比如 "Chinese (GBK)"。
- 推荐配对使用：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)" -
default_encoding已被官方标记为“已弃用”，它只影响新建空文件右下角显示的编码标识，不控制Ctrl+S的实际写入编码 -
fallback_encoding是“读取失败时尝试的备选编码”，比default_encoding更安全：它只在 UTF-8 解码失败时才启用 GBK，不会误伤真正的 UTF-8 文件 - 务必删掉配置里可能存在的
"detect_encoding": true——这个开关会让 Sublime 主动跳过 BOM 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码
ConvertToUTF8 插件在 ST4 中基本不推荐
该插件自 2020 年起停止更新，ST4（Build 4126+）的 API 变动导致常见失效现象：状态栏不显示编码名、右键无反应、Package Settings 里压根找不到入口。
- 即使强行安装，也容易和原生编码逻辑冲突，造成状态栏显示错乱或保存行为异常
- 如果你必须用（比如维护老 ST3 项目），注意三点：
– 只能通过Package Control: Install Package安装，手动拖文件夹到Packages目录在 ST4 中大概率无效
– 装完必须重启，否则插件监听事件不注册，等于没装
– 首次启用后要进Preferences → Package Settings → ConvertToUTF8 → Settings – User，写入配置：{"convert_on_load": true,"convert_on_save": true,"confidence": 0.95} -
confidence设太高（如 0.98）会漏掉弱信号 GBK 文件，太低（0.85）又可能把带 BOM 的 UTF-8 错判为 GBK
最常被忽略的一点是：你看到的“乱码”，其实是 Sublime 正确读出了字节，只是解错了——所以核心永远是先确认真实编码（用 file -i 或 Notepad++ 查），再匹配解码方式，而不是堆插件或调字体。
