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 看前几个字节,比瞎猜快。