Sublime Text修复乱码必须先“Reopen with Encoding”正确解码，再“Save with Encoding→UTF-8”重新编码；直接Save with Encoding仅改标记不改字节，无法修复。
Sublime Text 默认不自动转码，直接改编码只是“假装”UTF-8，实际内容字节没变——真要修复乱码，必须重载+转存两步走。
为什么「Save with Encoding → UTF-8」不能修乱码？
这是最常踩的坑：点 Save with Encoding → UTF-8 后中文还是方块或问号。因为这个操作只改了文件头标记，没动底层字节。原文件如果是 GBK 编码存的，现在用 UTF-8 解释，自然错位。
- 真实场景：从 Windows 记事本、微信粘贴、旧项目复制来的 .txt/.html 文件，大概率是
GBK或GB2312编码 - Sublime 会按文件 BOM 或内容试探编码，但试探失败时默认 fallback 成
Western (Windows 1252)，一打开就崩 -
Save with Encoding是“覆盖保存”，不是“解码再编码”，相当于换标签不换内容
正确修复流程：先「Reopen with Encoding」，再「Save with Encoding」
核心是让 Sublime 先用对的编码读进来，再以 UTF-8 写出去。顺序反了就白忙。
- 打开乱码文件后，先点菜单
File → Reopen with Encoding → GBK（或GB2312、ISO 8859-1，试到文字正常为止） - 确认中文显示正确后，再点
File → Save with Encoding → UTF-8 - 关掉重开，如果还乱，说明第一次选的源编码不对，回去重试
Reopen with Encoding - 注意：Mac 上没有
GBK选项，得装插件ConvertToUTF8才能识别
怎么让新文件默认 UTF-8，且不带 BOM？
避免下次再踩坑，得改两个地方：新建文件默认编码 + 保存时不加 BOM。
- 菜单
Preferences → Settings，在右侧用户设置里加这两行：
{
"default_encoding": "UTF-8",
"save_with_bom": false
}
default_encoding 只影响新建空白文件；已存在的文件仍按原编码打开save_with_bom 设为 false 很关键：Windows 记事本认 BOM，但大多数 Web 服务和 Git 会把它当脏字符处理批量转码用命令行更稳，别信插件一键转换
几十个文件要转？别用 ConvertToUTF8 或 EncodingHelper 插件点来点去。它们内部调的也是 iconv，但参数常写错，容易把 UTF-8 文件误转成乱码。
- 终端进目录，用这句安全转（跳过已 UTF-8 的文件）：
for f in *.txt; do iconv -f GBK -t UTF-8 "$f" -o "${f%.txt}_utf8.txt" 2>/dev/null || echo "skip $f"; done
iconv -f GBK -t UTF-8 明确指定源和目标，比插件猜编码靠谱chcp 65001 && iconv -f gbk -t utf-8，但先确认系统支持 iconv
file -i filename 或 Python 的 chardet 库比人眼靠谱最麻烦的永远不是操作步骤，而是你不知道它原本是什么编码。试 GBK、GB18030、Big5 都不行时，八成是混合编码或者有隐藏控制字符——这时候别硬刚，用 hexdump -C 看前几个字节，比瞎猜快。
