Sublime Text 本身不支持真正批量修改文件编码，所有操作均为逐文件人工确认源编码；ConvertToUTF8插件仅处理当前打开文件，批量转码须用命令行工具如iconv并先备份、验证再覆盖。
Sublime Text 本身不支持真正批量修改文件编码
直接告诉你结论：Sublime Text 没有内置的「选中多个文件 → 一键转码并覆盖保存」功能。所有插件（包括 ConvertToUTF8）都只作用于当前打开的标签页，不会扫描目录、不读取未打开文件、也不自动识别源编码。指望它“扫一遍 src/ 下所有 .js 文件全转成 UTF-8”，结果大概率是部分文件变双乱码、Git diff 爆满、回滚都找不到原始字节。
为什么 ConvertToUTF8 不是批量工具
ConvertToUTF8 插件只在你**打开一个文件时**尝试用 GBK/GB18030 解码，并转为 UTF-8 内存表示；按 Ctrl+S 才写入磁盘。它不记录历史、不遍历、不备份、不验证。
- 状态栏右下角显示的
GBK或UTF-8只是 Sublime 最后一次手动指定或插件临时猜测的结果，不是磁盘真实编码 -
"convert_on_save": true会强制每次保存都转 UTF-8 —— 对本就是 UTF-8 的文件再转一次，可能引入 BOM 或无效字节 - 如果文件实际是
UTF-8 with BOM却被误判为 GBK，插件会错解再错转，中文直接变??? - Sublime Text 4 用户注意：部分版本中该插件已失效，
status bar不更新，convert_on_open不触发
真批量必须用 iconv 命令行，且必须显式指定源编码
离开 Sublime，在终端里执行才是唯一可控路径。关键不是“能不能转”，而是“敢不敢信自动识别”。混着 GBK 和 UTF-8 的项目里，chardet 会把带中文的 UTF-8 文件误判为 GBK，一跑就全毁。
- 先备份：
cp -r src src_backup（Windows 用robocopy或手动复制） - 确认真实编码：
file -i *.js（Linux/macOS），或用xxd a.js | head -5看开头三字节是否为ef bb bf（BOM） - 批量转换（示例：GBK → UTF-8，不覆盖原文件）：
find src -name "*.js" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \; - 验证新文件是否正常：
head -n 5 src/file.js.utf8，确认中文可读后再手动替换 - Windows 用户推荐用 WSL2 或 Git Bash 运行同上命令；别依赖 PowerShell 的
-Encoding参数——它只控制读取/写入行为，不改原始字节流
File → Reopen with Encoding 不等于转码
这是最常踩的坑。右下角点 GBK 只是让 Sublime 换种方式解释内存里的字节，不读磁盘、不写磁盘、不改文件内容。错误操作链：乱码 → 点 UTF-8 → 更乱 → 再点 GBK → Save with Encoding → UTF-8，此时保存的是已被错解两次的损坏文本。
- 正确顺序只有这一条：先
File → Reopen with Encoding → Chinese (GBK)（确认中文显示正常）→ 再File → Save with Encoding → UTF-8 - 菜单里没有
Chinese (GBK)？说明没安装对应编码支持，得手动在Packages/User/Preferences.sublime-settings加"fallback_encoding": "GBK"，或装ConvertToUTF8补充 - 即使你点了
Save with Encoding → UTF-8，如果之前没正确以 GBK 重新打开，内存里存的就是错解字符，保存出来还是乱码
最易被忽略的一点：Sublime 默认的 UTF-8 是无 BOM 的，而某些旧嵌入式环境或 Windows 工具依赖 BOM 判断编码。真要生成带 BOM 的 UTF-8，得用 iconv -f GBK -t UTF-8-BOM，而不是靠 Sublime 菜单里的 “UTF-8 with BOM” —— 那个选项只对新建文件或空文件生效，对已有内容无效。
