插件安装后中文乱码并非插件故障，而是Sublime解码状态与文件真实编码不匹配所致；需先File→Reopen with Encoding→Chinese(GBK)恢复显示，再Save with Encoding→UTF-8保存修正。
插件安装后中文变乱码，不是插件坏了，是编码链断了
插件（比如 ConvertToUTF8 或 Codecs37）装完反而更乱，大概率不是插件本身出错，而是它和 Sublime 当前视图的解码状态冲突了。插件只负责“转换保存”或“自动识别”，不负责“让已乱的文件立刻变正常”。你看到的乱码，是 Sublime 用 UTF-8 错解 GBK 字节的结果——插件没能力倒带重放这个错误过程。
常见现象：ConvertToUTF8 装完，打开一个 GBK 文件，状态栏仍显示 UTF-8，中文还是“锟斤拷”；Codecs37 装完，右下角标出 GBK，但字还是方块。
- 先别动插件设置，直接走
File → Reopen with Encoding → Chinese (GBK) - 如果菜单里没有
Chinese (GBK)，说明插件没提供编码支持（ConvertToUTF8不自带，Codecs37自带），得手动补：Preferences → Browse Packages… → 新建文件夹叫GBK Support，里面放一个空的gbk.py（内容可为空，仅占位触发加载） - 重启 Sublime 后再试，确保
Chinese (GBK)出现在菜单里
ConvertToUTF8 插件装完不生效，90% 是因为没重启或配置错
ConvertToUTF8 在 ST4（Build 4126+）中默认不监听事件，装完不重启 = 白装。它也不靠 Package Control 自动激活，必须靠一次“触发式加载”：打开一个乱码文件 → 手动 Reopen with Encoding → Chinese (GBK) → 此时插件才注册监听器。
配置项写错也会静默失效：
-
"convert_on_load": true必须显式开启，否则插件对新打开文件完全无感 -
"confidence": 0.95对弱信号 GBK 文件（如纯数字+少量中文）容易漏判，降到0.90更稳 -
"detect_encoding": true这个字段要删掉——它会让插件跳过 BOM 检查，把带 BOM 的 UTF-8 文件误判为 GBK
Codecs37 比 ConvertToUTF8 更适合 ST4 用户
如果你用的是 Sublime Text 4.4+，ConvertToUTF8 已基本不可靠：底层依赖的 chardet 库在 ST4 中被重构，原插件未适配，常出现状态栏编码名不更新、右键菜单消失、保存时编码回退等问题。
Codecs37 是目前更稳的选择：
- 支持
GBK、GB18030、Shift-JIS、EUC-KR等 30+ 编码，持续维护 - 安装后开箱即用，无需改配置，打开 GBK 文件会自动识别并显示正确中文，右下角直接标
GBK - 不会和 Sublime 原生编码逻辑打架，状态栏显示真实、保存行为可预期
Save with Encoding → UTF-8 是唯一真正改文件的动作
所有插件、所有设置、所有菜单操作，都只影响内存里的 Unicode 内容显示。只有 File → Save with Encoding → UTF-8 这一步，才会把当前已正确解码的字符，严格按 UTF-8 编码规则写回磁盘。
关键约束不能漏：
- 必须在
Reopen with Encoding → Chinese (GBK)确认中文正常之后执行，否则存的是“锟斤拷”的 UTF-8 编码，双乱码不可逆 - 选
UTF-8，不是UTF-8 with BOM——后者会让 Python、Git 报Non-UTF-8 code starting with '\xef' - 保存后关掉再重开，右下角应显示
UTF-8且中文不变形；如果别人用记事本打开还是乱码，说明你第一步原始编码判断错了
最麻烦的其实是混合编码项目：同一目录下既有 UTF-8 脚本又有 GBK 配置文件，全局设置毫无意义，得靠右下角手动切编码，或者用 .sublime-project 绑定路径级规则——这点不提前设，等 Git 提交失败才反应过来。
