ConvertToUTF8 插件在 sublime Text 4 中基本不可用，因其自2019年停更，API 已废弃，常见加载失败、状态栏不显示编码等问题；ST4 用户应改用持续维护的 Codecs37 插件。
ConvertToUTF8 插件到底能不能用？兼容性要先看版本
sublime text 4 用户要注意：ConvertToUTF8 自 2019 年后已停止更新，在 ST4 中常出现加载失败、状态栏不显示编码、切换无效等问题。这不是你装错了，而是插件底层调用的 API 已被废弃。如果你点开 Preferences → Package Settings 看不到 ConvertToUTF8 选项，或右下角编码名点击后无反应，基本可判定失效。
实操建议：
- 先确认 Sublime 版本：
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 原生支持等关键特性
乱码文件打不开？别急着改设置，先做“编码诊断”
Sublime 不会“猜错编码”，它只是按 fallback 顺序试解码。所谓“一打开就乱码”，本质是它用 UTF-8 解了本该用 GBK 解的字节流，结果把两个字节当一个 UTF-8 字符解析，全变成 或方块。
正确做法是跳过猜测，直接告诉它“你试试 GBK”：
- 打开乱码文件 → 点击右下角当前编码名（如
UTF-8）→ 选Reopen with Encoding → Chinese (GBK) - 若仍乱码，再试
Chinese (GB2312)或Western (windows 1252)（旧版记事本无 BOM 的常见误判） - 一旦中文正常显示，立刻执行
File → Save with Encoding → UTF-8—— 这步才是转码，不是“另存为”，否则乱码会固化
Settings–User 里加 fallback_encoding 是治标还是治本？
加 "fallback_encoding": "GBK" 确实能让部分老旧文本“秒开不乱码”，但它会污染所有未声明编码的文件：比如你打开一个纯英文日志（实际是 ISO-8859-1），Sublime 也会强行用 GBK 解，导致 café 变成 caé。
更稳妥的策略是分场景设：
- 日常开发新项目：设
"default_encoding": "UTF-8"+"fallback_encoding": "UTF-8"，强制所有新建/另存走 UTF-8 - 专攻银行/嵌入式日志等 GBK 重灾区：加
"detect_indentation": false防止插件因编码检测干扰缩进识别 - 绝对不要同时设
default_encoding和fallback_encoding为不同中文编码（如一个 GBK 一个 GB2312），Sublime 不会智能合并，反而增加误判概率
批量转 GBK → UTF-8，为什么不能一键全选？
因为“批量转换”插件（如 ConvertAllEncodings）没有上下文判断能力。它会把所有文件无差别按指定编码重读再写入，如果其中混着一个真实 UTF-8 且带 BOM 的文件，用 GBK 强解就会把 BOM 当作中文字符，转出一堆  开头的脏数据。
安全做法只有两个字：逐个确认。
- 用
Codecs37打开第一个文件 → 看状态栏是否显示GBK→ 点击编码名 →Save with Encoding → UTF-8 - 关闭再重开，确认中文和格式（尤其缩进、空行）没变 → 再处理下一个
- 若某文件状态栏显示
UTF-8却乱码，说明它其实是 GBK 但无 BOM 被误判，此时手动Reopen with Encoding → Chinese (GBK)再保存
真正耗时的从来不是操作步骤，而是得在几十个文件里，靠肉眼分辨哪个是真 GBK、哪个是假 UTF-8、哪个带 BOM 哪个不带——这才是没人明说但最卡脖子的地方。