Sublime Text打开文件乱码的根本原因是默认不自动识别GBK等中文编码，而强行按UTF-8解析；应优先使用“Reopen with Encoding”手动指定GBK/GB2312，而非盲目安装ConvertToUTF8插件。
Sublime Text打开文件显示乱码，根本原因是编码未自动识别
Sublime Text 默认不主动探测文件真实编码，遇到 GBK、GB2312 或 Big5 等中文编码的文件，常直接按 UTF-8 解析，结果就是方块、问号或错位字符。这不是插件问题，是编辑器底层行为——它只在「已知编码」和「保存时指定编码」之间切换，不带解码容错。
所以别一上来就装插件。先确认：你打开的是什么文件？是不是从 Windows 记事本、微信/QQ 接收的文本、旧项目里的 .txt 或 .html？这类文件大概率是 GBK 编码，但 Sublime 默认不会猜。
临时解决办法：右下角点击当前编码名（如 UTF-8）→ 选 Reopen with Encoding → 找到并选 GBK 或 GB2312。如果显示正常，说明编码判断对了。
ConvertToUTF8 插件不是“万能解码器”，它只做一件事：自动转存为 UTF-8
ConvertToUTF8 的核心逻辑非常简单：检测到非 UTF-8 编码文件（靠 chardet 库粗略判断），就尝试用该编码读取内容，再以 UTF-8 重新写入磁盘。它不改变你当前视图的编码显示逻辑，也不实时转码预览——只有你保存时才触发转换。
这意味着：
- 它对只读文件、无写入权限的文件、远程挂载路径下的文件完全无效
- 如果原始编码识别错误（比如把
GBK误判成ISO-8859-1），保存后内容就真乱了，且不可逆 - 它无法处理 BOM 残留、混合编码、含控制字符的脏数据等边缘情况
所以安装前务必确认：你是否真的需要「把所有老文件统一转成 UTF-8 并长期保存」？如果只是偶尔查看，手动 Reopen with Encoding 更安全。
安装 ConvertToUTF8 必须绕开 Package Control 的默认行为
Package Control 官方仓库里早已下架 ConvertToUTF8（因维护停滞、兼容性差），现在搜到的大多是镜像或改名版本（如 CTU8）。直接通过 Package Control: Install Package 搜索安装，大概率装的是过期版或恶意 fork。
正确做法是手动安装：
- 去 GitHub 搜索
seanliang/ConvertToUTF8（作者原 repo，最后更新于 2020，但仍是目前最稳的） - 下载
master分支的 zip，解压得到文件夹，重命名为ConvertToUTF8 - 打开 Sublime Text 的
Packages目录：Preferences → Browse Packages…，把文件夹拖进去 - 重启 Sublime，右下角状态栏出现
UTF-8 (ConvertToUTF8)即生效
注意：ConvertToUTF8 不会自动启用。首次打开非 UTF-8 文件时，它会在状态栏提示「Detected encoding: GBK, convert?」，按 Enter 确认才执行转换。
比插件更可靠的长期方案：用 EditorConfig + 显式声明编码
真正减少乱码的，不是靠编辑器猜，而是让编码意图明确可追溯。推荐组合使用：
- 在项目根目录加
.editorconfig，写入：[*]\ncharset = utf-8
（提醒所有协作者和编辑器：本项目默认 UTF-8） - 对必须保留 GBK 的遗留文件，在文件头加注释说明，例如：
（虽不被 Sublime 原生识别，但人眼可读，配合脚本可自动化检查） - 用命令行批量转码：
iconv -f GBK -t UTF-8 input.txt > output.txt，比依赖插件更可控
插件只是补丁，而编码声明是契约。越晚统一，后期排查成本越高——特别是当 ConvertToUTF8 把一个误判的文件存成乱码 UTF-8 后，原始字节已丢失，基本无法恢复。
