sublime text 不支持真正批量修改文件编码，converttoutf8 仅处理当前打开文件，file → reopen with encoding 不等于转码，真批量需用 iconv 命令行并明确指定源编码。
Sublime Text 本身不支持真正意义上的批量修改文件编码——所有“批量”操作都绕不开手动确认源编码或依赖外部工具。指望插件一键扫目录、自动识别、全部转码并覆盖保存，结果大概率是部分文件乱码、部分编码错乱、Git 提交历史全崩。
ConvertToUTF8 插件只能处理当前打开的文件
很多人装完 ConvertToUTF8 就以为能批量干活，其实它只响应「当前标签页」：文件一打开，它尝试用 GBK/GB2312/GB18030 等解码；显示正常后，你按 Ctrl+S，它才以 UTF-8 写回磁盘。它不会扫描项目目录，也不会记住你昨天开过的 config.ini 是什么编码。
- 插件配置里设
"convert_on_save": true后，每次保存都会强制转成 UTF-8 —— 但若原文件本就是 UTF-8（带 BOM 或无 BOM），再转一次可能多出无效字节 - 它默认不改原始编码意图：比如你用 GBK 打开一个旧脚本并编辑，插件可能仍以 GBK 保存（除非关掉
save_to_original_encoding） - Sublime Text 4 用户需注意：部分版本中该插件已失效，状态栏不显示编码变化，或根本无法触发自动识别
File → Reopen with Encoding 不等于转码
右下角点 UTF-8 或 GBK，只是让 Sublime 换种方式解释内存里的字节流，不读磁盘、不写磁盘、不改文件内容。这是最常被误解的操作。
- 错误做法：
File → Reopen with Encoding → UTF-8→ 发现还是乱码 → 再点GBK→ 乱码更严重 → 最后Save with Encoding → UTF-8：此时保存的是已被错解两次的损坏文本 - 正确顺序：先
Reopen with Encoding → Chinese (GBK)（确认中文显示正常）→ 再Save with Encoding → UTF-8（此时才是真实转码） - 如果菜单里没有
Chinese (GBK)，说明没安装对应编码支持，得靠插件或手动补全编码列表（如加CP936）
真批量转码必须用命令行 + 明确指定源编码
离开 Sublime，在终端里用 iconv 是唯一可控、可复现、可脚本化的方案。关键不是“能不能转”，而是“敢不敢信自动识别”。GBK 和 UTF-8 混在一个项目里时，chardet 会把带中文的 UTF-8 文件误判为 GBK，一跑批量就全废。
- Linux/macOS 示例（转当前目录所有
.py文件）：for f in *.py; do iconv -f GBK -t UTF-8 "$f" -o "utf8_$f"; done
- Windows 推荐走 WSL2：
find ./src -name "*.txt" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \; -
-f GBK必须写准：写成-f GB2312可能漏掉某些汉字；写成-f UTF-8却去转实际是 GBK 的文件，输出全是问号 - 永远先备份：
cp -r src src_backup，别指望 Sublime 的撤销能救回磁盘上被覆盖的乱码文件
default_encoding_on_save 设置有陷阱
在 Preferences → Settings – User 里加 "default_encoding_on_save": "UTF-8"，看起来很美，但它只影响「新建文件」或「未声明编码的空文件」的保存行为。对已存在的非 UTF-8 文件，Sublime 仍会按原编码保存——除非你先手动 Reopen with Encoding 正确解码，否则设置完全不生效。
- 想强制所有保存都走 UTF-8？得配合插件（如
File Encoding User）+ 自定义 Build System 调用iconv，但这就不再是“设置一下就行”的事了 -
"UTF-8 with BOM"是唯一被 Sublime 正确识别的变体；写成"UTF8-BOM"或"UTF-8+BOM"会静默失败，状态栏仍显示 UTF-8，但文件没写入 BOM - 大项目统一编码前，务必检查是否含
.gitattributes或编辑器配置（如.editorconfig），避免团队协作时又退回乱码循环
真正麻烦的从来不是“怎么转”，而是“怎么确认每个文件原本是什么编码”。没有银弹，只有逐个验证、小批量试跑、留备份、看 Git diff。别跳过预演，也别迷信自动识别。
