sublime text 中真正改变文件内容的编码操作只有 reopen with encoding 和 save with encoding 两个手动步骤；其余所有编码切换均不修改磁盘文件，仅为内存显示调整。
Sublime Text 里没有“一键转编码”的快捷键，所有真正改变文件内容的编码操作都必须手动触发两个独立动作：先 Reopen with Encoding，再 Save with Encoding。任何试图用单个快捷键完成“识别+转码+保存”三合一的操作，本质都是错觉或插件封装，底层逻辑不变。
Reopen with Encoding 必须手动选对原始编码
右下角显示“UTF-8”但中文是方块？说明 Sublime 正在用 UTF-8 解析 GBK 字节流——它不会自动猜，也不会 fallback。你得告诉它“这其实是 GBK”。
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac），输入Reopen with Encoding回车 - 优先试
Chinese (GBK)、Chinese (GB2312)、UTF-8—— 哪个显示正常，哪个就是原始编码 - 菜单里没这些选项？不是 Sublime 坏了，是原生不支持，需装
ConvertToUTF8插件，或在用户设置里加"fallback_encoding": "Chinese (GBK)" - 错选一次就可能让内存 Unicode 进一步失真，别硬扛，换一个再试
Save with Encoding 是唯一真正写磁盘的转码操作
Save with Encoding 不是“另存为”，而是把当前视图内容（已解码成 Unicode）按新编码规则重新编码、写回磁盘。不可逆，且不备份。
- 确认
Reopen with Encoding显示正常后，再执行File → Save with Encoding → UTF-8 - 点错成
Save with Encoding而非Reopen with Encoding，等于用 UTF-8 编码强行重写 GBK 字节流，原始信息大概率损毁 - 该操作不依赖插件，原生支持；但若文件本身含 BOM，且配置中没关
"save_with_bom": false，可能多出无用字节 - 没有全局快捷键绑定它——因为风险太高，Sublime 故意不提供默认映射
ConvertToUTF8 插件的配置陷阱
它能自动做 Reopen with Encoding 那步，但不能绕过“原始编码识别失败”这个根本限制。很多失效不是插件问题，是配置冲突。
- 删掉用户设置里任何
detect_encoding: true—— 它会让 Sublime 主动跳过 BOM 去试 GBK，把带 BOM 的 UTF-8 文件判成乱码 -
fallback_encoding不接受标准编码名，写"UTF-8"无效；必须用 Sublime 内部标识符，如"Chinese (GBK)" - ST4 中偶有加载失败，常见原因是缺依赖
Codecs36或Codecs37；得先装它们，再装ConvertToUTF8 - 插件不处理构建系统输出乱码（那是终端或
PYTHONIOENCODING的事），也不修复已损坏的 BOM
default_encoding 和 fallback_encoding 别混用
这两个字段分工明确，混设会导致新建文件和老文件全乱套。
-
default_encoding控制新建文件和显式保存时的编码，必须设为"UTF-8" -
fallback_encoding是“兜底解码方式”，只在打开无 BOM、无声明的老文件时起作用，应设为"Chinese (GBK)"（不是"GBK"或"UTF-8"） - 用户设置里同时出现
"default_encoding": "UTF-8"和"fallback_encoding": "UTF-8"，等于告诉 Sublime：“所有文件都当 UTF-8 解”，结果 GBK 文件一打开就是乱码 - 别信网上教程说“加
detect_encoding: true提高识别率”——它实际是降低准确率的开关
最易被忽略的一点：Sublime 所有“编码切换”动作中，只有 Reopen with Encoding 和 Save with Encoding 真正影响文件内容；其余所有点击、状态栏切换、插件自动识别，都只改内存表示，不碰磁盘一个字节。理解这点，才能不被“看似转成功了”骗过去。
