sublime text 编码问题核心在于区分新建、打开、保存三阶段:default_encoding已弃用;default_encoding_on_save控制保存编码;fallback_encoding决定无bom文件的打开解析;状态栏显示仅为当前解码方式,不改变文件实际编码。

新建文件默认编码不是靠 default_encoding 就能搞定的
sublime text 新建空白文件时,界面显示为 UTF-8,但这个“显示”不等于“已写入 BOM”或“已绑定保存行为”。default_encoding 确实控制新建文件的初始编码标识,但它在 Sublime 中早已被弱化——官方明确标注为“已弃用”,实际生效依赖上下文。你改了它,新建文件右下角可能还是显示 UTF-8,但一保存,如果内容为空或没触发编码确认流程,它根本不会写入任何字节,更不会带 BOM。
真正起作用的是:default_encoding_on_save(仅影响保存动作)和 fallback_encoding(决定打开未知文件时怎么猜)。所以别只盯着 default_encoding 配,它现在更多是个兼容占位符。
-
default_encoding_on_save设为"UTF-8":确保按 Ctrl+S 时默认走 UTF-8 编码写入 -
fallback_encoding设为"UTF-8":让 Sublime 打开无 BOM、无声明的旧文件时,优先用 UTF-8 解析,而不是误判成Western (windows 1252)或 GBK 导致满屏方块 - 不要设
"UTF-8 with BOM":Sublime 不识别这个字符串,会静默失效或回退到系统 locale
打开旧文件乱码?不是设置错了,是解码逻辑没对上
你在 Windows 上双击一个记事本存的中文 .txt,打开全是 ,这不是因为你没设对 default_encoding,而是 Sublime 拿 fallback_encoding 去读了一个实际是 GBK 的文件——它把两个 GBK 字节当做一个 UTF-8 字符解,自然崩坏。
此时点右下角状态栏的编码名(比如点一下 UTF-8),只是让 Sublime “重解析当前内存内容”,不改磁盘字节,也不转码。你越点越乱,因为每次都是拿错的规则再解一遍错的字节。
- 正确做法:菜单栏
File → Reopen with Encoding → Chinese (GBK)(或GBK),先让内容正常显示 - 确认无误后,再执行
File → Save with Encoding → UTF-8,这才真正把 GBK 字节转成 UTF-8 字节写回磁盘 - 若频繁处理这类文件,建议安装
ConvertToUTF8插件,它会在打开时自动识别 GBK 并转为 UTF-8 显示,但注意:它默认保存仍回 GBK,如需统一存 UTF-8,得进插件配置关掉save_to_original_encoding
convert_to_utf8_on_save 是假选项,原生 Sublime 不支持自动转码保存
网上很多教程让你在用户设置里加 "convert_to_utf8_on_save": true,这行配置 Sublime 原生根本不认——它不是内置键名,属于某些插件(如老版 ConvertToUTF8)的私有字段。加了不仅无效,还可能导致配置解析失败(jsON 格式错误)。
Sublime 的保存行为永远基于当前文件“当前使用的编码”:如果你用 Reopen with Encoding → GBK 打开了文件,那 Ctrl+S 默认就以 GBK 保存;只有你手动执行过 Set Encoding → UTF-8,它才会以 UTF-8 保存。不存在“后台偷偷转码”这回事。
- 想强制某类文件总用 UTF-8 保存?装
File Encoding Manager插件,可按扩展名绑定默认保存编码(例如所有.py文件自动设为 UTF-8) - 想一键批量转项目里所有 GBK 文件?别指望 Sublime 内置功能,用命令行:
iconv -f GBK -t UTF-8 file.txt -o file_utf8.txt - 插件转换有边界:ConvertToUTF8 能帮你“看懂” GBK,但不能把 UTF-8 文件反向转成 GBK;它也不改文件磁盘编码,只是编辑时做内存映射
带 BOM 还是不带 BOM?多数场景该选无 BOM 的 UTF-8
Sublime 右下角能看到 UTF-8 和 UTF-8 with BOM 两个选项,但它们不是等价切换。前者是标准、干净的 UTF-8;后者开头多三个字节 EF BB BF,会导致 Python 解释器报 SyntaxError: Non-UTF-8 code starting with 'xef',git 提交时显示异常,Node.js 读取也可能出问题。
除非对接的系统(比如某些老旧 Windows 工具、IE6 时代的 ASP 页面)明文要求 BOM,否则一律用无 BOM 版本。Sublime 默认的 UTF-8 就是无 BOM 的,而 UTF-8 with BOM 只应在明确需要时手动选择。
- 新建文件后立刻要输中文?不用管 BOM,直接敲字,Ctrl+S 即按
default_encoding_on_save规则保存 - 已有文件带了 BOM 想去掉?
File → Reopen with Encoding → UTF-8 with BOM→ 全选复制 → 新建文件 → 粘贴 →Save with Encoding → UTF-8 - 插件如 ConvertToUTF8 默认不写 BOM,但它的配置项
write_bom若被设为true,就会悄悄加上——检查插件 settings 是否有这一行
编码问题从来不是改一个配置就能终结的事。它横跨新建、打开、编辑、保存、插件介入、跨平台协作多个环节,每个环节都可能卡住。最常被忽略的是:状态栏显示的编码名,只是 Sublime 当前“怎么读”,不是文件“本来是什么”;而保存动作永远忠于“当前怎么读”,不是“你想怎么存”。搞清这个前提,比背一百条配置项都管用。