发布于2026-07-17 阅读(0)
扫一扫,手机访问
说到 Sublime Text 的编码设置,坑确实不少。它自己并不会强制要求你一定要用UTF-8来新建或保存文件,所以光改一个default_encoding完全不够用。想要真正摆脱乱码困扰,必须把fallback_encoding和default_encoding_on_sa ve配套设置好,这才是关键。

Sublime Text 原生不强制新建或保存为 UTF-8,光改 default_encoding 不够,必须配对设置 fallback_encoding 和 default_encoding_on_sa ve 才能真正解决乱码问题。
default_encoding 还是乱码?核心原因在于,这个参数在官方文档里已经被标记为“已弃用”了。它主要影响的是新建文件时右下角的显示标识,以及“另存为”对话框里默认勾选的编码选项——但请注意,它并不控制实际保存行为。你看到右下角显示“UTF-8”,并不代表磁盘上那个文件真的就是UTF-8编码;尤其是空文件,保存后连字节都没有,更谈不上什么编码。
default_encoding_on_sa ve。不是 sa ve_encoding,也不是什么 convert_to_utf8_on_sa ve,别搞混。fallback_encoding 控制的是打开无BOM、无编码声明文件时的解码策略。Windows下默认是 Western (Windows 1252),一打开GBK中文文件,十有八九就全乱码了——这才是日常乱码的罪魁祸首。"convert_to_utf8_on_sa ve": true,是ConvertToUTF8插件的专属字段,Sublime原生根本不认,加了也没用。Preferences → Settings – User打开菜单 Preferences → Settings,在右侧用户设置文件里写入以下JSON(注意逗号、引号、大小写都不能错):
{ "default_encoding_on_sa ve": "UTF-8", "fallback_encoding": "GBK", "detect_indentation": false}
default_encoding_on_sa ve:设为 "UTF-8" 后,每次保存都强制以UTF-8编码写盘(无BOM)。fallback_encoding 设为 "GBK":让老项目里的中文文本文件一打开就能正常显示,避免被误判成Windows-1252。default_encoding ——它已弃用,且与 default_encoding_on_sa ve 冲突时优先级更低,反而可能添乱。detect_indentation 关掉:防止Sublime根据首行缩进反向推断并覆盖你的编码设置。状态栏右下角有一个编码名的显示(比如 Western (Windows 1252)),点击它只是让Sublime“用这个编码重新解码当前内存里的内容”,并不会改动磁盘上的字节,也不会进行转码。盲目点选 UTF-8,很可能把GBK字节当UTF-8来解,结果乱上加乱。
Reopen with Encoding → GBK。Sa ve with Encoding → UTF-8,这样才真正把GBK字节转成UTF-8字节写入磁盘。Reopen with Encoding → UTF-8 即可,不需要Sa ve with Encoding。iconv -f GBK -t UTF-8 file.txt > file_utf8.txt。ConvertToUTF8 插件确实能自动识别GBK并以UTF-8方式显示,但它本质上是一个“前端渲染层适配”,不是底层编码转换器。它的作用边界很清晰:
default_encoding_on_sa ve。default_encoding_on_sa ve 的行为,两者可以共存,但别指望插件能帮你绕过核心配置。最容易忽略的一点是:所有这些设置都只生效于本地。团队协作时,必须把 "default_encoding_on_sa ve": "UTF-8" 写入 .sublime-project 文件,才算真正落地,否则别人打开照旧乱码。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8