sublime text切换编码仅reopen with encoding和save with encoding真正修改文件；前者重解释字节，后者转码写入；其他操作均不改动磁盘内容。
Sublime Text 里所谓“切换编码”，其实只有两个动作真正改文件：一个是 File → Reopen with Encoding（重解释字节），另一个是 File → Save with Encoding（真正转码写入）。其他所有点击、状态栏切换、插件自动识别，都只是影响显示或内存表示，不碰磁盘上一个字节。
乱码文件第一步：必须先选对原始编码再重开
打开一个 GBK 文件却显示“锟斤拷”或方块，不是文件坏了，是 Sublime 默认用 UTF-8 去解 GBK 字节流。它不会猜，也不会 fallback —— 你得手动告诉它“这其实是 GBK”。
- 点击右下角当前编码名（比如显示
UTF-8或Western (ISO 8859-1)）→ 选Reopen with Encoding→Chinese (GBK) - 如果还不对，依次试
Chinese (GB2312)、Chinese (GB18030)；Windows 下生成的文本，优先试Chinese (GBK) - 若菜单里压根没有这些选项，说明 Sublime 原生不支持，需装
ConvertToUTF8插件，或手动在用户设置里加"fallback_encoding": "Chinese (GBK)" - 切完仍乱码？别硬扛，换一个编码再试。错选编码再重开，只会让内存里的 Unicode 字符进一步失真
Save with Encoding 才是唯一真正转码操作
确认中文已正常显示后，File → Save with Encoding → UTF-8 这一步才把内存中已解码的 Unicode 字符，按 UTF-8 规则重新编码成字节，覆盖写回磁盘。此前所有操作，都不改变文件内容。
- 务必选
UTF-8，不是UTF-8 with BOM—— 后者在多数现代环境（Git、Python、Linux）中反而容易引发问题 - 保存后关闭再重开，右下角应稳定显示
UTF-8，且中文依然清晰。如果别人用记事本打开还是乱码，说明上一步没选对原始编码，这次保存等于把乱码又“固化”了一次 -
ConvertToUTF8插件默认save_to_original_encoding是true，即 Ctrl+S 仍按原编码（如 GBK）保存。如需统一存为 UTF-8，必须进插件设置把该项设为false
批量转码别指望 Sublime 原生功能
Sublime 没有“选中多个文件 → 一键转 UTF-8 并保存”的菜单项。所谓“批量”，要么是插件暴力扫目录（风险高、不可控），要么是伪批量（你得一个个点开、reopen、save）。
-
ConvertToUTF8只对当前打开的文件生效，未打开的文件它完全看不见 - 真批量请用命令行：
iconv -f GBK -t UTF-8 input.txt > output.txt。注意-f必须填对原始编码，填错会导致双乱码 - Windows 用户建议用 Git Bash 运行
iconv，避免 CMD 自身编码污染；批量处理时加个备份习惯：cp *.txt backup/ - 如果项目含换行符敏感逻辑（如 shell 脚本、Makefile），记得关掉 Git 的自动换行：
git config --global core.autocrlf false
ST4 用户注意：ConvertToUTF8 已过时，慎用
Sublime Text 4（Build 4100+）已内置 GBK/Big5 自动探测能力，ConvertToUTF8 反而可能干扰原生逻辑，导致状态栏编码显示错乱、保存行为异常，甚至覆盖失败无提示。
- 新装用户推荐改用持续维护的
Codecs37插件，兼容性更稳 - 已装
ConvertToUTF8的用户，卸载后务必检查Preferences → Package Settings → ConvertToUTF8是否残留配置，否则重启后仍可能生效 - 如果你只是偶尔处理旧 GBK 文件，不用装任何插件——靠
Reopen with Encoding+Save with Encoding两步足够，还更可控
最容易被忽略的一点：所有“显示正常”的前提，是你已经正确还原了原始字节到 Unicode 的映射。一旦这一步错了，后面每一步都在加固错误。所以别跳过预览确认，也别迷信插件自动识别。
