sublime打开中文文件乱码需先手动指定原始编码（如chinese (gbk)），再执行save with encoding → utf-8完成真正转码；converttoutf8插件在st4中已过时，推荐改用持续维护的codecs37。
Sublime 打开中文文件显示乱码，不是插件没装对，而是你还没告诉它“这个文件本来就是 GBK”。ConvertToUTF8 插件本身不解决初始乱码——它只在你已经正确解码的前提下，帮你把编辑后的内容以 UTF-8 保存。
点击右下角编码名 → Reopen with Encoding → Chinese (GBK) 才是第一步
乱码文件一打开就满屏方块或问号，根本原因是 Sublime 默认用 UTF-8 解析了本该用 GBK 解的字节流。它不猜、不容错、也不 fallback 自动试——你得手动指定。
- 打开乱码文件 → 点击右下角状态栏当前编码（比如显示
UTF-8或Western (ISO 8859-1)）→ 选Reopen with Encoding→Chinese (GBK) - 如果仍乱码，再试
Chinese (GB2312)或Western (Windows 1252)；只要中文能看清，原始编码就基本判断对了 - 此时你看到的“正常中文”只是 Sublime 在内存里用 GBK 解出的 Unicode 字符串，磁盘上文件一个字节都没变
- 如果点完
Chinese (GBK)反而更乱，说明原始编码不是 GBK，别硬扛，换其他选项再试
Save with Encoding → UTF-8 是唯一真正转码动作
很多人以为点一下状态栏就转码了，其实那只是换了解码方式。让文件磁盘内容真正变成 UTF-8，只有这一步：
- 确认当前文件已用正确编码（如
Chinese (GBK)）打开，中文显示无误 - 菜单栏
File→Save with Encoding→UTF-8（注意：不是UTF-8 with BOM） - 保存后关闭再重开，右下角应显示
UTF-8，且中文依然正常 - 如果保存后别人用记事本打开还是乱码，说明你漏了上一步——文件根本没被正确识别为 GBK，直接保存只会把乱码字节按 UTF-8 再编码一遍，变成双乱码
ConvertToUTF8 插件现在基本是个“历史兼容补丁”，不是必选项
Sublime Text 4（Build 4100+）已内置 GBK/Big5 自动探测，多数场景下 ConvertToUTF8 反而会干扰原生逻辑，导致状态栏编码显示错乱或保存行为异常。
- 如果你用的是
Sublime Text 3或老项目里一堆无 BOM 的 GBK 文件，插件仍有价值；但必须从 GitHub 手动安装原作者仓库（seanliang/ConvertToUTF8），Package Control里搜到的几乎全是过期镜像或改名版（如CTU8），有兼容风险 - 插件生效的前提是你已通过
Reopen with Encoding正确加载内容；它不会自动猜对编码，也不会把 UTF-8 文件“转出”成 GBK - 装了插件后，
Save with Encoding→UTF-8这一步仍不可跳过——插件不改磁盘，只帮你把内存里的 Unicode 按 UTF-8 编码写回去
Sublime Text 4 用户建议直接换用 Codecs37
ConvertToUTF8 自 2019 年停更，在 ST4 中常出现加载失败、状态栏不显示编码、切换无效等问题。这不是你装错了，而是插件底层调用的 API 已被废弃。
- 先确认版本：
Help→About Sublime Text，若为 v4.4+，优先换用Codecs37（支持GBK/GB18030/UTF-8-BOM/Shift-JIS等 30+ 编码，持续维护） - 安装
Codecs37后无需额外配置——打开 GBK 文件会自动识别并正常显示，状态栏显示GBK，点击即可切换保存编码 - 若坚持用
ConvertToUTF8，可尝试降级到Sublime Text 3.3.2（最后稳定兼容版），但会失去 ST4 的 GPU 渲染、LSP 原生支持等关键特性
真正麻烦的从来不是操作步骤，而是得先判断文件原本是什么编码——尤其混合了 UTF-8-BOM、GBK、ANSI 的旧项目里，“一个一个试”才是常态。别指望插件全自动搞定，手动诊断才是最稳的起点。
