Sublime乱码主因是编码识别错误而非缺插件，需先通过Reopen with Encoding选择正确编码（如GBK）使中文正常显示，再用Sa ve with Encoding→UTF-8真正转码保存。
乱码不是插件问题，是编码没对上
遇到Sublime打开文件时满屏的方块、问号或者错位字符，先别急着找插件。问题的根源往往很简单：编辑器用错了“翻译规则”。它默认用UTF-8这套规则去解读原本用GBK或GB2312编写的文件字节，结果自然是一团乱码。Sublime本身不会主动猜测编码，所以你得先告诉它正确的规则。
因此，第一步绝不是安装插件。试试这个标准流程：
- 打开那个乱码的文件，把目光移到编辑器右下角，那里会显示当前猜测的编码（比如
UTF-8）。 - 点击它，选择
Reopen with Encoding，然后在列表里找到Chinese (GBK)并点击。 - 如果中文还没正常显示，不妨再试试
Chinese (GB2312)或者Western (Windows 1252)。 - 一旦文字清晰可辨，恭喜你，原始编码已经找对了。
ConvertToUTF8 插件到底干了什么
这个插件的作用非常明确，但也常被误解。它本质上是一个“保存时的转换器”。当你按下Ctrl+S保存文件时，插件会将内存中已经正确解码的Unicode内容，按照UTF-8的编码规则重新写入磁盘。它不会实时转换你看到的内容，也不会去改动一个只读文件的字节。
这意味着几个关键点：
- 插件生效有个大前提：你必须已经能正常看到中文。如果文件还是乱码，插件也无能为力。
- 保存操作执行后，文件在磁盘上的内容才真正变为
UTF-8。在此之前，文件本质上还是原来的GBK字节，只是“看起来”正常。 - 这里有个风险：如果一开始就选错了原始编码（比如误把带BOM的UTF-8文件当成GBK打开），那么保存后文件内容就可能被错误转换，且这个过程通常是不可逆的。
- 对于只读文件、没有写入权限的目录或者网络驱动器上的文件，这个插件是无效的。
安装 ConvertToUTF8 要绕开 Package Control
这里有个常见的坑：ConvertToUTF8插件早在2020年就从官方的Package Control仓库下架了。现在如果你通过Package Control: Install Package去搜索安装，找到的很可能是过期的镜像或者改了名的版本（比如CTU8），这些版本不仅兼容性差，还可能存在安全风险。
目前最稳妥的方式是手动安装：
- 前往GitHub，搜索作者的原仓库
seanliang/ConvertToUTF8（最后更新于2020年）。 - 下载
master分支的ZIP压缩包，解压后将文件夹重命名为ConvertToUTF8。 - 在Sublime中，通过
Preferences → Browse Packages…打开插件目录，把刚才的文件夹拖进去。 - 重启Sublime Text。如果安装成功，当你打开一个GBK编码的文件时，右下角状态栏会显示
UTF-8 (ConvertToUTF8)。
需要注意的是，插件安装后默认不会自动激活。通常你需要手动打开一个GBK编码的文件，才能触发它的检测功能。
Sa ve with Encoding 才是真正转码动作
很多人存在一个误解，以为在状态栏点击切换编码名，文件就已经被转换了。其实那一步（Reopen with Encoding）仅仅改变了Sublime读取文件的方式，磁盘上的原始文件一个字都没有被改动。
真正执行编码转换、将文件永久变为UTF-8的，是下面这个菜单命令：
File → Sa ve with Encoding → UTF-8（注意，通常选择不带BOM的UTF-8即可）。
这个操作调用了Sublime核心的编码转换逻辑：它将内存中已解码的Unicode字符，严格按照UTF-8的规则重新编码成字节序列，然后覆盖写入原文件。不过，这个内部转换器并非万能，对于某些复杂的混合编码（如包含特殊变体的GB18030）或带有异常控制字符的ISO-8859系列文件，转换可能会失败，或者静默地丢失部分字符。
至于批量处理？建议对所谓的“一键转码”插件保持警惕。在老项目中，文件编码常常是UTF-8-BOM、GBK、ANSI的大杂烩，依赖自动识别就是在赌概率。最保险、最负责任的做法，还是一个文件一个文件地确认原始编码，然后手动执行Sa ve with Encoding进行转换。虽然慢一点，但能确保万无一失。
