sublime text中reopen with encoding仅重解释字节流、不改文件，save with encoding才真正转码写盘且不可逆；右下角显示的是当前解码方式而非真实编码；批量转换应使用iconv等外部工具而非sublime。
Sublime Text 没有真正意义上的“一键批量转换编码”功能，所谓“一键”基本等于赌运气——误判原始编码后保存，文件就不可逆损坏。
Reopen with Encoding 和 Save with Encoding 到底在干什么
这两个菜单项是 Sublime 里唯一能真正影响磁盘文件编码的操作，但作用完全不同：
-
Reopen with Encoding：只改当前视图怎么解释字节流，不写磁盘。比如一个 GBK 文件被当成 UTF-8 打开显示乱码，点它选Chinese (GBK)，立刻变正常——这只是内存重解码，文件本身一字未动 -
Save with Encoding：把当前视图里已解码好的 Unicode 文本，按你选的编码规则重新编码、写回磁盘。这才是真转码，且不可逆 - 右下角状态栏显示的
UTF-8或Western (ISO 8859-1)是当前解码方式，不是文件真实编码。瞎点它只会让错上加错
ConvertToUTF8 插件必须改的三项配置
装完插件默认是摆设，convert_on_load 和 convert_on_save 都是 false，等于没开。打开 Preferences > Package Settings > ConvertToUTF8 > Settings – User，填入：
{
"convert_on_load": true,
"convert_on_save": true,
"confidence": 0.90
}
-
convert_on_load: true：文件一打开就自动转成 UTF-8 显示，编辑时无感 -
convert_on_save: true：Ctrl+S 时按原始编码（如 GBK）写回，避免破坏协作环境 -
confidence: 0.90：默认0.95太高，短文本或混合中文易漏检；降到0.90覆盖更多 GBK/GB2312 边界情况 - 删掉任何
detect_encoding: true—— 它会让 Sublime 主动跳过 BOM 去试 GBK，把带 BOM 的 UTF-8 当乱码处理
怎么确认文件真实编码，而不是靠猜
别信右下角显示、别试到“看起来像中文”就停。先验明正身：
- Linux/macOS 下运行：
file -i 文件名，看输出中charset=gbk还是charset=utf-8 - Windows 用户用 Notepad++ 打开，右下角直接显示
GBK、UTF-8-BOM或ANSI（即系统默认编码，通常是 GBK） - 如果文件带 BOM，
file -i可能识别不准，此时用 hexdump -C 文件名 | head -n 1 看开头字节：ef bb bf是 UTF-8-BOM，ff fe是 UTF-16LE
批量转码别碰 Sublime，用 iconv 更稳
想把整个项目从 GBK 统一转成 UTF-8？Sublime 不适合干这事。风险太高：
- ConvertToUTF8 插件只对当前打开的文件生效，不会扫描目录批量改磁盘
- 所谓“批量转换脚本”本质是循环执行
Reopen with Encoding+Save with Encoding，一旦某文件实际是 UTF-8-BOM 却被误判为 GBK，保存后就彻底毁了 - 推荐命令行：
iconv -f GBK -t UTF-8 file.txt -o file_utf8.txt，再配合find . -name "*.txt" -exec bash -c 'iconv -f GBK -t UTF-8 "$1" -o "${1%.txt}_utf8.txt"' _ {} \; - Windows 下可用
chcp 65001切换控制台编码，但注意这不影响 Sublime 自身行为
最常被忽略的一点：Save with Encoding 选 UTF-8 和 UTF-8 with BOM 是两回事。后者在 Git、Python 解释器、Linux 工具链里都容易出问题，除非对接老 Windows API，否则一律选前者。
