Sublime Text 保存文件为 GB2312 编码需先执行“Set Encoding: GBK”命令，再按 Ctrl+S 显式保存；仅修改 default_encoding 配置无效，因 Sublime 不原生支持 GB2312，实际应使用 GBK。
Sublime Text 保存文件时强制用 GB2312 编码
Sublime Text 默认不会自动按 GB2312 保存中文文件，它更倾向 UTF-8；一旦你手动选了 GB2312 编码但没保存，下次打开还是可能回退到 UTF-8 或系统默认编码——这不是 bug，是它的编码检测逻辑在起作用。
真正起效的方式是：先切换当前文件编码，再显式保存。不能只靠“设置里改默认值”就一劳永逸。
-
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS）呼出命令面板 - 输入
Set Encoding: GB2312并回车（注意不是 “Save with Encoding”） - 立刻按
Ctrl+S（或Cmd+S）保存，此时才会真正以 GB2312 写入磁盘 - 如果跳过第 2 步直接保存，Sublime 会按当前文件“已识别的编码”存，而识别结果常是 UTF-8
为什么改 Preferences.sublime-settings 不管用
很多人去改用户配置里的 default_encoding，比如设成 "GB2312"，但这只是告诉 Sublime “新空白文件默认用啥编码打开”，不影响已有文件的保存行为，也不影响从磁盘读取时的解码逻辑。
更关键的是：GB2312 不是 Sublime 原生支持的编码名，它实际识别的是 GBK 或 GB18030；直接写 GB2312 可能被忽略或 fallback 到 UTF-8。
- 配置中写
"default_encoding": "GBK"比"GB2312"更可靠 - 但即便如此，对已存在内容的文件，Sublime 仍优先信任 BOM 或内容探测结果，而非这个配置
- 如果你需要批量转码，别依赖设置，用
Convert to Encoding: GBK命令更直接
保存后乱码？检查是否真用了 GB2312 写入
常见现象：用记事本打开显示正常，但用 VS Code 或浏览器打开就乱码——大概率是 Sublime 实际保存成了 UTF-8 with BOM，或者你只改了显示编码没保存。
验证方法很简单：用十六进制编辑器（如 HxD、xxd）看文件头。GB2312 编码的纯中文文本不会有 EF BB BF（UTF-8 BOM），且字节序列应符合 GB2312 双字节规则。
- 在 Sublime 中按
Ctrl+Shift+P→ 输入File Encoding: Detect，看右下角状态栏显示什么 - 如果显示
UTF-8却以为自己存了 GB2312，说明第 2 步没做：必须先Set Encoding，再Save - 某些老系统或嵌入式设备只认严格 GB2312（不含扩展字符），此时用
GBK保存也可能出问题，得用外部工具转
插件不是必需，但能减少手误
纯手动操作容易漏掉“Set Encoding”这步，尤其频繁切换文件时。有个轻量插件 EncodingHelper 可绑定快捷键一键完成“设编码 + 保存”，比记命令快。
不推荐装大而全的编码管理插件（比如自带自动转换的），它们常干扰原生编码检测，反而让乱码更难排查。
- 安装插件后，在
Key Bindings里加一行：{ "keys": ["ctrl+alt+s"], "command": "set_encoding_and_save", "args": {"encoding": "GBK"} } - 注意参数写
"GBK"，不是"GB2312"；Sublime 内部没有独立的 GB2312 解码器，GBK是兼容子集 - 插件不能绕过编码本质限制：GB2312 不支持 emoji、部分生僻汉字，强行存会丢字符或报错
GB2312 是个窄编码，现在多数场景该用 UTF-8；真要兼容老系统，重点不是“怎么设”，而是“谁在读、是否真需要 GB2312 而非 GBK”。
