Sublime Text 默认不按文件实际编码读取，需设置 fallback_encoding 为 "Chinese (GBK)" 解决打开乱码，default_encoding 设为 "UTF-8" 确保新建和保存文件用 UTF-8 编码。
Sublime Text 打开文件显示乱码，怎么改默认编码？
Sublime Text 默认不按文件实际编码读取内容，尤其遇到 GBK/GB2312 编码的中文文件时，直接显示为方块或问号。这不是文件损坏，是解码方式错了——得告诉 Sublime 用什么编码打开它。
- 在菜单栏点 File → Reopen with Encoding → GB2312（或 GBK），能临时修复当前文件
- 想一劳永逸？改默认解码逻辑：打开 Preferences → Settings – User，加这行：
"fallback_encoding": "Chinese (GBK)"
- 注意：
fallback_encoding只在 Sublime 无法自动识别编码时生效；如果文件带 UTF-8 BOM，它仍会优先走 UTF-8，不会触发 fallback - 不要写
"utf-8"或"UTF-8"给fallback_encoding—— 这个字段不接受标准编码名，必须用 Sublime 内置的编码标识符，比如Chinese (GBK)、Western (ISO 8859-1)
保存新文件时中文变乱码，是不是编码设错了？
新建文件打中文，一保存就乱，大概率是保存编码不是 UTF-8。Sublime 新建文件默认用系统 locale 编码（Windows 上常是 GBK），但现代项目基本要求 UTF-8（无 BOM）。
- 保存前先确认右下角状态栏显示的是
UTF-8；如果不是，点它 → 选 Save with Encoding → UTF-8 - 更彻底的办法：在 Settings – User 里加上
"default_encoding": "UTF-8"
-
default_encoding控制「新建文件」和「显式保存时」的默认编码，但它不改变已打开文件的编码，只影响后续操作 - 别混淆
default_encoding和fallback_encoding：前者管“我主动存成啥”，后者管“它没声明编码时我猜成啥”
为什么有些中文文件改了编码还是乱？可能是混合编码或 BOM 问题
不是所有“中文乱码”都靠换编码能解决。真实项目里常见几种干扰：
- 文件本身是 UTF-8 编码，但开头有 BOM（
\ufeff），而某些工具（比如旧版 Python 解释器、部分 shell 脚本）读到 BOM 就报错或跳过——此时应选 File → Save with Encoding → UTF-8（注意不是 UTF-8 with BOM） - 文件里混用了多种编码（比如从 Word 复制粘贴进来的文本，含隐藏控制字符），Sublime 无法统一识别，建议先用 File → Reopen with Encoding → UTF-8，再手动删掉异常字符
- Windows 记事本另存为“ANSI”格式的文件，实际是当前系统 locale 编码（简体中文 Win10 就是 GBK），但 Sublime 有时识别成
Western (ISO 8859-1)，这时必须手动选Chinese (GBK)重载
插件能自动处理中文编码吗？推荐哪些靠谱的？
纯靠插件全自动解决乱码，目前不现实。Sublime 的编码检测本身很弱，插件只是封装了手动切换流程。
-
ConvertToUTF8插件确实流行，但它本质是监听文件加载 → 自动尝试用 GBK 解码 → 成功则转成 UTF-8 内存表示 → 保存时强制 UTF-8。副作用明显：- 会导致 Git 显示大量“文件已修改”，因为内存中已是 UTF-8，但原始文件仍是 GBK
- 遇到真 UTF-8 + BOM 文件可能误判为 GBK，反而弄乱
- 更轻量的选择是
EncodingHelper：只提供快捷键快速切换常用编码（Ctrl+Alt+G = GBK，Ctrl+Alt+U = UTF-8），不干预自动逻辑 - 如果你长期处理遗留 GBK 项目，与其依赖插件，不如把
fallback_encoding和default_encoding配稳，再养成保存前看一眼右下角编码的习惯
编码问题从来不是“设对一个选项就完事”。关键在于分清：这是打开时解码错，还是保存时编码错，又或者文件本身就带不可见干扰字符。很多人卡住，是因为在错误环节调参数。
