sublime乱码需用reload with encoding重读而非转换编码：先试utf-8或gbk，含bom选utf-8 with bom；convert to encoding会修改文件字节且不可逆，仅在确认内容正确后用于永久转码。
Sublime 打开乱码文件时，Reload with Encoding 怎么选对编码
乱码不是文件坏了，是 Sublime 读错了编码。关键不是“转”，而是“重读”——用正确的编码重新解析字节流。Reload with Encoding 不改变文件内容，只改解释方式。
常见错误现象：UTF-8 文件被当成 GBK 打开，中文全变问号或方块；反之，GBK 文件用 UTF-8 读，出现 或错位汉字。
- 先试
UTF-8：现代文本、代码、网页源码大概率是它 - 中文文档/旧系统导出的 txt，优先试
GB2312或GBK - windows 记事本保存的带 BOM 的 UTF-8，选
UTF-8 with BOM（否则可能仍乱） - 不确定时，右键菜单 →
Set Encoding→ 逐个试，看中文是否恢复自然断行和标点
Convert to Encoding 和 Reload with Encoding 到底区别在哪
这是最常混淆的两个操作：Reload with Encoding 是“换眼镜看原图”，Convert to Encoding 是“把原图重画一遍”。后者会真实修改文件字节，不可逆。
使用场景：只有当你确认当前文件内容正确（比如已用 Reload with Encoding 看清了），且需要永久存为另一种编码（如提交到只认 GBK 的老系统），才用 Convert to Encoding。
- 误用
Convert to Encoding后保存，原始编码信息就丢了，再想还原很难 -
Convert to Encoding对含 BOM 的 UTF-8 文件可能静默失败，表面没报错但实际没变 - 编辑过程中频繁切换编码？别用
Convert，用Reload更安全
为什么有些文件选了正确编码还是乱码
不是编码选错了，是文件本身混合了多种编码，或者用了非标准实现（比如某些 excel 导出的 CSV 强行塞进 UTF-8 但实际是 GBK 字节+UTF-8 标题）。
性能影响很小，但兼容性陷阱多：Sublime 默认不检测 BOM，也不自动识别 GB18030 或 Big5，得手动选。
- 检查文件开头是否有 BOM：用十六进制工具看前几个字节，
EF BB BF= UTF-8 BOM - 日文/韩文文件别只盯
UTF-8，试试EUC-JP或EUC-KR - 从微信、钉钉复制粘贴进 Sublime 的文字，可能自带不可见控制字符，导致局部乱码，删掉前后空格再试
命令面板里搜不到 Reload with Encoding？
默认快捷键是 Ctrl+Shift+P（Win/linux）或 Cmd+Shift+P（Mac），输入 “reload” 就能出来。但前提是该功能没被插件禁用或覆盖。
容易踩的坑：装了 ConvertToUTF8 这类老插件后，它会劫持编码行为，让原生 Reload 功能失效或响应迟钝。
- 临时解决：禁用可疑插件，重启 Sublime 再试
- 长期建议：用官方支持更好的
UTF8-Correct替代老插件 - 路径不对？不是插件路径问题，是 Sublime 自带功能，无需额外安装
真正麻烦的从来不是选哪个编码，而是文件压根没声明自己是谁——尤其当它来自不同操作系统、不同年代的软件、甚至被多次复制粘贴过。这时候，比编码名更重要的是观察乱码规律：是整段错位？还是单字变方块？有无固定偏移？这些细节比菜单里的名字更可靠。