ConvertToUTF8插件仅对单个打开的GBK文件自动解码并转为UTF-8内存表示，保存时才写入磁盘，不支持批量处理；误操作如乱码下直接另存为UTF-8会导致二次损坏；真批量需用终端iconv命令按扩展名分组处理并验证。
ConvertToUTF8 插件只处理当前文件，不是批量扩展
它会在你打开一个 GBK 文件时自动尝试用 GBK 解码，并转成 UTF-8 内存表示；按 Ctrl+S 才真正以 UTF-8 写入磁盘。但它不扫描目录、不遍历文件、不记录原始编码，更不会批量打开多个文件。装完就以为能“一键扫项目转码”，结果发现命令面板搜不到批量命令，右键菜单也没变化——这是正常现象，不是插件坏了。
常见误操作包括：
– 在乱码状态下直接 Save with Encoding → UTF-8（此时内存里已是错解内容，再保存等于二次损坏）
– 把 convert_on_save 设为 true 后对已有 UTF-8 文件也强制转，可能引入 BOM 或无效字节
– 依赖状态栏右下角显示的 GBK 或 UTF-8 判断真实编码（那只是 Sublime 最后一次手动指定的解码方式，不是磁盘字节的真实编码）
File Encoding User 配合 Build System 才算“半批量”方案
这个插件本身不做转换，但能把文件编码信息透出给外部命令，配合自定义构建系统可实现“选中多个文件 → 右键 Build With → 逐个调用 iconv”。它比 ConvertToUTF8 更可控，但需要手动写配置：
- 在
Packages/User/File Encoding User.sublime-settings中设置 fallback 编码，例如：{"fallback_encoding": "GBK"} - 新建 Build System（
Tools → Build System → New Build System），填入类似以下内容（Linux/macOS）：{ "shell_cmd": "iconv -f GBK -t UTF-8 \"$file_path/$file_name\" > \"$file_path/utf8_$file_name\"" } - 必须先选中多个文件（且它们都在同一个项目目录下），再右键 →
Build With→ 选该构建系统 - 注意：它不会覆盖原文件，而是生成新文件（如
utf8_main.js），你得自己验证后再手动替换
真批量必须离开 Sublime，用 iconv + 显式指定源编码
Sublime 的 GUI 环境对多字节编码极其脆弱，尤其当项目里混着 GBK、UTF-8-BOM、无 BOM UTF-8 时，任何“自动识别”都等于赌运气。唯一可靠路径是终端命令行：
- 先备份：
cp -r src src_backup（Windows 用户请用robocopy或 WSL2） - 确认源编码：别信 chardet，用
file -i *.js（Linux/macOS）或nkf -g *.txt（需先brew install nkf）粗筛，重点看是否含charset=gbk或charset=utf-8 - 批量执行（Linux/macOS/WSL2）：
find src -name "*.html" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \; - Windows 建议用 PowerShell + WSL2，而非原生
Get-Content -Encoding Default—— 因为Default实际对应系统 ANSI（如 cp936），不是文件真实编码 - 转换后务必用
git diff或diff -u对比前后，检查中文是否完整、BOM 是否多余、换行符是否被改
别忽略 BOM 和混合编码场景下的隐性破坏
很多老旧项目里，.js 是 UTF-8（无 BOM），.jsp 是 GBK，.properties 是 ISO-8859-1 —— 这时强行统一用 iconv -f GBK 批量扫，会把原本就是 UTF-8 的文件当成 GBK 解，导致双乱码。更麻烦的是，某些 UTF-8 文件带 BOM（EF BB BF），iconv 默认不认它为 UTF-8，可能误判为 GBK。
所以真正落地时，必须：
– 按扩展名分组处理（比如先 .jsp，再 .js）
– 对疑似 UTF-8 的文件加 -c 参数跳过非法字节（iconv -c -f UTF-8 -t UTF-8 可清洗）
– 转完别急着删备份，留三天观察 CI 构建和前端打包是否报字符错误
