ConvertToUTF8插件不解决初始乱码，仅在手动通过Reopen with Encoding正确解码（如Chinese GBK）后，于保存时将内存中Unicode转为UTF-8写回磁盘；ST4用户应优先选用持续维护的Codecs37。
ConvertToUTF8 插件现在基本不能“一键解决”乱码，它不负责让乱码文件立刻变正常，只在你已正确解码的前提下，帮你把编辑后的内容按 UTF-8 保存回去。装了就见效？不是的——第一步永远是手动告诉 Sublime：“这个文件是 GBK”。
为什么刚打开的中文文件还是方块？
Sublime 默认用 UTF-8 解析所有文件。一个 GBK 编码的文件被当 UTF-8 读，字节流直接错位，显示就是乱码。ConvertToUTF8 不会在这一步自动纠正——它没机会介入，因为内容还没解出来。
- 必须先点右下角状态栏的编码名（比如
UTF-8或Western (ISO 8859-1)），选Reopen with Encoding → Chinese (GBK) - 如果还不对，再试
Chinese (GB2312)或Western (Windows 1252)；只要中文能看清，就说明原始编码判断对了 - 此时你看到的“正常中文”只是内存里的 Unicode，磁盘文件一字未动
- 插件只有在这之后才开始工作：你 Ctrl+S 时，它把内存里的 Unicode 按 UTF-8 编码写回磁盘
Package Control 安装的 ConvertToUTF8 基本不可信
官方仓库早在 2020 年就下架了该插件，现在通过 Package Control: Install Package 搜到的，大多是过期镜像、改名版本（如 CTU8），甚至带可疑依赖。
- 手动安装才是目前最稳的方式：去 原作者仓库 下载
master分支 zip，解压后重命名为ConvertToUTF8 - 打开 Sublime →
Preferences → Browse Packages…，把文件夹拖进打开的目录 - 重启 Sublime，否则插件监听逻辑不注册，形同虚设
- 首次启用需手动打开一个 GBK 文件触发检测；状态栏出现
UTF-8 (ConvertToUTF8)才算生效
ST4 用户别硬扛，Codecs37 是更现实的选择
ConvertToUTF8 自 2019 年起停止更新，ST4 的 API 已大幅变更。常见失效表现：Preferences → Package Settings 里找不到它、状态栏不显示编码名、右键无反应、重启后仍乱码。
- ST4.4+（2026 年主流版本）建议直接换
Codecs37：支持 GBK/GB18030/UTF-8-BOM/Shift-JIS 等 30+ 编码，持续维护 - 安装后开箱即用，状态栏如实显示当前解码方式（如
GBK），点击即可切换保存编码 - 若非要保留 ConvertToUTF8，必须在
Preferences → Package Settings → ConvertToUTF8 → Settings – User中强制加配置：
{
"convert_on_load": true,
"convert_on_save": true,
"confidence": 0.95,
"max_detect_lines": 600
}
confidence: 0.95 是关键：太高（如 0.98）会漏掉弱信号 GBK 文件；太低（0.85）可能把带 BOM 的 UTF-8 当 GBK 错判。
真正把文件变成 UTF-8 的唯一动作
很多人以为状态栏显示 UTF-8 就代表文件已是 UTF-8，其实那只是当前视图的解码方式。磁盘文件是否真为 UTF-8，只取决于你有没有执行这一步：
- 确认文件已用
Chinese (GBK)正确打开，中文显示无误 - 菜单栏
File → Save with Encoding → UTF-8（注意：不是UTF-8 with BOM） - 保存后关闭再重开，右下角显示
UTF-8且中文依然正常，才算真正转码成功 - 如果跳过手动指定原始编码这步，直接点这一步，等于把乱码当原文本再存一遍，不可逆
插件不会绕过这个前提自动完成——它不猜编码，也不改磁盘，只做“解码后保存”这一件事。最容易被忽略的，就是那个必须手动点的 Reopen with Encoding。
