sublime需开启detect_encoding并设fallback_encoding为gbk才能正确识别gbk文件；default_encoding设为utf-8仅影响新建文件；已乱码文件须先reopen with encoding→gbk再save with encoding→utf-8。
怎么让 Sublime 自动识别 GBK 文件而不乱码
Sublime 原生不自动识别 GBK，哪怕文件里全是中文，它也大概率按 Western (windows 1252) 或空 fallback 解析，结果就是满屏方块。这不是“没设对默认编码”，而是探测机制压根没开，或者开了但没配对兜底策略。
- 必须开启
detect_encoding：在Preferences → Settings – User中加"detect_encoding": true - fallback 不能设成
UTF-8—— 这会让 GBK 文件被强行当 UTF-8 解，直接双重乱码；应设为"fallback_encoding": "GBK" - 别信“状态栏点一下 UTF-8 就好了”：那只是重解析当前字节流，不是转码；原文件是 GBK 字节，用 UTF-8 解，结果仍是错的
新建文件为什么还是显示 Western 编码？
新建空白文件的状态栏显示 Western (Windows 1252) 或 UTF-8 不稳定，根本原因是 default_encoding 没生效，或者被其他配置干扰（比如旧版残留的 default_encoding_on_save）。
- 唯一有效项是
"default_encoding": "UTF-8"，写进用户设置即可，无需其他字段 -
default_encoding_on_save是已弃用配置，Sublime 4+ 完全忽略，写了反而可能引发解析错误 - 新建文件内容为空时，bom 不会自动生成；所以即使设了 UTF-8，状态栏显示正常，也不代表保存后带 BOM —— 这是预期行为，不是 bug
ConvertToUTF8 插件到底该不该装
如果你日常要打开大量无 BOM 的 .txt、.log、老项目配置文件（尤其是 Windows 下记事本保存的），那它几乎是刚需；但如果你只处理 git 仓库里的现代代码文件，它反而可能干扰判断，甚至把 UTF-8 文件误判为 GBK。
- 插件作用很明确：打开时自动检测并以 UTF-8 显示，保存时可选还原原编码或统一存为 UTF-8
- 它不改磁盘原始字节，也不批量转换；所谓“自动”，仅限于单文件打开/保存这一闭环
- 禁用方法：命令面板输入
ConvertToUTF8: Disable，比卸载更轻量；启用时注意检查插件设置里的encoding_map是否包含"gbk": "GBK"
已乱码的文件怎么安全转成 UTF-8
已经打开并显示乱码的文件，不能靠改设置修复，必须人工干预解码路径。错一步，比如先 Save with Encoding → UTF-8，就会把错误解码后的垃圾字节再写成 UTF-8，彻底不可逆。
- 第一步永远是
File → Reopen with Encoding → GBK（或其他你怀疑的原始编码） - 确认中文显示正常后，再执行
File → Save with Encoding → UTF-8 - 如果不确定原始编码，可用外部工具辅助判断：Windows 下运行
chcp查当前控制台编码；linux/macos 用file -i filename.txt或enca filename.txt
真正容易被忽略的是：Sublime 的编码逻辑是「读时决定」而非「存时决定」。你改了 default_encoding，只影响新文件；而所有旧文件的打开方式，完全由 detect_encoding + fallback_encoding + 文件字节特征共同决定——没有万能开关，只有针对性配置。