sublime text 中文乱码源于 utf-8 解码器误读 gbk 字节流，彻底解决需三步：确认真实编码（用 file -i 或 notepad++）、匹配解码方式（reopen with encoding）、按需转存（save with encoding），插件如 codecs37 更可靠。
Sublime Text 中文乱码不是编辑器坏了，而是它用 UTF-8 规则去解一段 GBK 字节流——结果必然是满屏“锟斤拷”或方块。真正能“彻底解决”的方案，只有一条路径：先确认真实编码，再匹配解码方式，最后按需转存。插件只是辅助，不是万能钥匙。
怎么确认文件真实编码，而不是靠猜
Sublime 右下角显示的 UTF-8 或 GBK 只是当前解码方式，不是文件真实编码。点开就是方块？说明它正在错读。
- 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)，看到中文就停 -
Save with Encoding：真把内存里已解码的内容，按新编码重写到磁盘，不可逆。必须在Reopen with Encoding显示正常后才用 - 绝对别点
Convert to UTF-8（老版本菜单里有）：它会静默重写文件且不提示，原始编码信息直接丢失
ST4 用户别硬上 ConvertToUTF8，优先选 Codecs37
截至 2026 年中，ConvertToUTF8 在 Sublime Text 4.4+ 上已基本不可靠。它依赖的底层库（如 chardet）在 ST4 中兼容性断裂，且作者自 2020 年起未更新。
- GitHub 官方仓库已归档，Package Control 里搜到的基本是镜像或改名版本（如
CTU8），存在兼容性差甚至安全风险 -
Codecs37是目前更稳的选择：支持GBK/GB18030/Shift_JIS等 30+ 编码，持续维护，安装后开箱即用 - 安装方式：命令面板输入
Package Control: Install Package→ 搜索Codecs37→ 安装 → 重启。打开 GBK 文件时状态栏直接标出GBK，无需额外配置
用户配置里 fallback_encoding 为什么不能写 "UTF-8"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置，等于没设。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"或"Western (ISO 8859-1)"，这些是 Sublime 内部注册的编码标识符 -
default_encoding_on_save（ST4 中替代已弃用的default_encoding）才支持"UTF-8"，它管新建文件和显式保存时的默认编码 - 推荐组合：
"default_encoding_on_save": "UTF-8"+"fallback_encoding": "Chinese (GBK)"+"save_with_bom": false；否则保存后 Python/Git 会报Non-UTF-8 code starting with '\xef'
最常被忽略的一点：Sublime 会记住每个文件上次用的编码，关掉重开仍沿用——所以改完设置不会自动生效，必须手动触发 Reopen with Encoding 才行。
