Sublime如何实现批量修改文件编码？Sublime批量转换UTF8教程

Sublime Text 本身不支持真正批量修改文件编码，所有“批量”操作均为伪批量；ConvertToUTF8 插件仅处理当前打开文件，需先正确 Reopen with Encoding 再 Sa ve with Encoding，真批量须用 iconv 等命令行工具显式指定源目标编码。

先直接说结论：Sublime Text 本身不支持真正意义上的批量修改文件编码，所有“批量”操作都只是伪批量——必须逐个加载、解码、再保存。指望插件一键扫目录转码，等于把文件命运交给概率。

很多人装完 ConvertToUTF8 就以为能批量转码，结果发现右键菜单没变化、命令面板搜不到批量命令。它只在你打开一个乱码文件时自动触发：检测到可能是 GBK，就用 GBK 解码并转成 UTF-8 内存表示，保存时才写入磁盘。这里有个关键点：它不会扫描项目目录，也不会批量打开文件；未打开的文件对它完全不可见。状态栏显示 GBK 或 UTF-8 只反映你最后一次手动指定或插件临时判断的结果，不是真实编码。配置项 "convert_on_open": true 是默认开启的，但仅对「新打开」的文件生效；已打开的乱码文件仍需手动 Reopen with Encoding。需要警惕的是：插件不备份原文件，保存即覆盖——如果源编码猜错了（比如把 UTF-8-BOM 误判为 GBK），乱码不可逆。

再来说说最常被搞反的一步：File → Reopen with Encoding 不是转码，而是重解释。乱码文件不能直接点 Sa ve with Encoding → UTF-8，因为 Sublime 此时内存里存的是错解后的字节（比如把 GBK 的 0xC4, 0xE3 当 UTF-8 解成两个非法码点），再以 UTF-8 写出只会雪上加霜。正确的操作顺序是：必须先选对源编码，执行 File → Reopen with Encoding → GBK（优先试 GBK，不行再试 GB2312 或 GB18030），确认中文显示正常后，再执行 File → Sa ve with Encoding → UTF-8。如果菜单里没有 GBK 选项，说明 Sublime 原生不支持，要么装 ConvertToUTF8，要么手动编辑 Package Settings → Default (Windows).sublime-settings 加入 "fallback_encoding": "GBK"。Mac 用户尤其要注意：GBK 不在原生编码列表中，不装插件就无法手动选。

真正的批量转码，得离开 Sublime，用 iconv + shell 脚本。Sublime 的 GUI 环境对多字节编码极其脆弱，尤其遇到混合 GB18030、UTF-8、BOM 的老旧项目，强行在编辑器里批量操作等同于盲打。可靠路径只有一条：终端里用 iconv 显式指定源和目标编码，逐个转换并生成新文件。Linux/macOS 直接可用：for f in *.txt; do iconv -f GBK -t UTF-8 "$f" -o "utf8_$f"; done。Windows 推荐走 WSL2：find ./src -name "*.py" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \;。千万别信 auto_detect 类参数——iconv 不自动识别源编码，-f GBK 必须明确写出；写错就输出乱码，且无提示。安全起见，先用 file -i filename（Linux/macOS）或 chcp && type filename.txt（Windows）粗略验证源编码，再批量执行。

最后提两个容易混淆的配置项：default_encoding 和 sa ve_with_encoding。名字太像，导致很多人设了 "default_encoding": "UTF-8" 就以为万事大吉——其实它只影响新建空白文件，对已有文件毫无作用。"sa ve_with_encoding": "UTF-8" 才是每次 Ctrl+S 都强制以 UTF-8 编码写入，不管当前文件原本是什么编码（慎开，可能覆盖非 UTF-8 意图）。强烈建议加上 "sa ve_with_bom": false，避免 Git 提交时把 BOM 当作脏字符报 warning。另外，配置值大小写敏感："UTF-8" 正确，"utf8" 或 "utf-8" 会被忽略。

说到底，真正麻烦的从来不是怎么转，而是怎么确认每个文件的原始编码。尤其当项目里混着 Windows 记事本 ANSI（实际 GBK）、爬虫抓取的 ISO-8859-1、带 BOM 的 UTF-8 和无 BOM 的 UTF-8 时，一个一个试 Reopen with Encoding 是唯一靠谱的方式——自动化在这里反而最危险。