sublime新建文件默认utf-8需设"default_encoding":"utf-8"；打开乱码文件须先reopen with encoding（如gbk）再save with encoding→utf-8，否则双重乱码。
怎么让新建文件默认就是 UTF-8？
Sublime 默认不强制新建文件用 UTF-8，尤其在中文 Windows 下，常继承系统 ANSI（即 GBK），导致一保存就埋下乱码隐患。这不是界面显示问题，而是字节写入时就错了。
关键配置只有两个：default_encoding 和 fallback_encoding，它们分工明确：
-
default_encoding控制「新建文件」和「另存为」时写入磁盘的编码 —— 必须设为"UTF-8" -
fallback_encoding是打开无 BOM、无声明编码的旧文件时的“兜底解码方式”，它不决定保存行为，只影响读取
打开 Preferences → Settings – User，在右侧粘贴或修改为合法 JSON：
{ "default_encoding": "UTF-8", "fallback_encoding": "GBK" }
注意：末尾不能有多余逗号；键名必须双引号；改完不用重启（部分 ST3 版本需重启，ST4 基本实时生效）。
打开已乱码的文件，为什么点右下角“UTF-8”没用？
状态栏右下角显示的编码名（比如 UTF-8 或 Western (Windows 1252)），仅代表 Sublime 当前“怎么读这个文件”，不是文件真实编码，更不会改磁盘内容。盲目点击只会让它用错的编码再错一遍。
正确流程是两步缺一不可：
- 先 File → Reopen with Encoding → Chinese (GBK)（或
GB2312、Big5，优先试GBK）—— 这步是“重新读对” - 确认中文正常显示后，立刻 File → Save with Encoding → UTF-8 —— 这步才是“真正转码写入”
如果跳过第一步直接 Save with Encoding → UTF-8，Sublime 会把原本 GBK 编码的字节当 UTF-8 解，再以 UTF-8 写出，结果是双重乱码，基本不可逆。
ConvertToUTF8 插件到底该不该装？
它不是万能解药，但对日常处理 GBK/GB2312 文件确实省事。它的核心价值是：打开时自动识别并以 UTF-8 方式渲染，保存时可选转回原编码或统一存为 UTF-8。
安装后常见表现：
- GBK 文件打开即正常显示，不用手动
Reopen with Encoding - 编辑后按
Ctrl+S，插件默认自动以 UTF-8 保存（可通过配置关掉） - 状态栏会显示原始编码（如
GBK），点击可快速切换解析方式
但要注意：
- 它不解决构建系统输出乱码（那是终端 locale 或
chcp的事） - 它不批量转码，也不识别 BOM 错误的 UTF-8 文件
- Sublime Text 4 中偶有加载失败，可换
Codecs36替代
为什么 fallback_encoding 设成 GBK 反而可能出问题？
设 "fallback_encoding": "GBK" 能秒开老项目里的 GBK 文件，但会污染其他场景：比如你打开一个 ISO-8859-1 编码的英文日志，Sublime 也会强行用 GBK 解，café 就变成 caé。
更稳妥的做法是分场景判断：
- 纯新项目开发：用
"fallback_encoding": "UTF-8"，靠default_encoding确保源头干净 - 维护遗留银行/嵌入式系统项目（大量 GBK 日志）：才启用
"fallback_encoding": "GBK"，并配合"detect_indentation": false防止缩进识别被干扰 - 绝对不要混搭
default_encoding和fallback_encoding为不同中文编码（如一个GBK、一个GB2312），Sublime 不会合并逻辑，只会增加误判概率
真正的难点从来不在设置几行 JSON，而在于你得先知道那个乱码文件本来是什么编码 —— 尤其当项目里混着 UTF-8-BOM、无 BOM 的 UTF-8、GBK、ANSI，一个一个试才是常态。
