正确处理乱码文件的第一步是用Reopen with Encoding尝试真实编码，而非Save with Encoding；Windows中文文本优先试Chinese (GBK)，再试GB2312、GB18030；状态栏编码名不反映磁盘内容，需手动配置fallback_encoding。
乱码文件打开后第一件事不是 Save with Encoding
看到“锟斤拷”或方块字就去点 Save with Encoding，等于把错解的 Unicode 再错写一遍——原始 GBK 字节被当 UTF-8 解出一堆无效字符，再按 UTF-8 存回去，文件就真坏了。
正确顺序只有一步：先用 Reopen with Encoding 尝试真实编码。Windows 下生成的中文文本，优先试 Chinese (GBK)；若仍乱码，再依次试 Chinese (GB2312)、Chinese (GB18030)。状态栏右下角显示的编码名只是当前解码方式，不反映磁盘内容。
- 别信菜单里没出现
Chinese (GBK)就代表不支持——那是 Sublime 原生没注册，得手动加"fallback_encoding": "Chinese (GBK)"到用户设置 - 如果试了所有常见中文编码都还是乱，用
file -i 文件名（Linux/macOS）或 Notepad++（Windows）确认真实编码，别靠猜 -
detect_encoding: true会干扰 BOM 判断，尤其对带 UTF-8 BOM 的文件，建议直接删掉这一项
ConvertToUTF8 插件不是万能钥匙，它只管当前文件
装完 ConvertToUTF8 就以为能批量转项目里所有 GBK 文件？错了。Convert to UTF-8 命令只对当前标签页生效，不会扫描目录、不记历史、不备份原文件——它本质是快捷版 Reopen with Encoding + Save with Encoding 合体，但依然要你手动开每个文件。
- 插件默认启用
convert_on_load和convert_on_save，意味着你编辑完保存时，它会默默把内容按原始编码（比如 GBK）写回去——这适合协作场景，但如果你目标是统一成 UTF-8，就得关掉convert_on_save - 配置里
"encoding_list"必须显式包含你要处理的编码，比如["Chinese Simplified (GBK)", "GBK"]，光写"GBK"不生效 - 大文件慎开
max_detect_lines超过 1000 行，检测慢且容易误判；confidence低于 0.9 会增加把 UTF-8 当 GBK 的风险
批量转码必须绕开 Sublime 自身，用外部工具驱动
Sublime 没有原生批量编码转换能力，任何声称“一键全项目转 UTF-8”的插件，背后都是调用 iconv 或 nkf。想安全批量处理，得自己搭一层命令行胶水。
- 先用
file -i *.txt批量看真实编码，确认全是charset=gbk再动手，别跳过这步 - 建一个 Build System：
{"shell_cmd": "iconv -f GBK -t UTF-8 '$file_path/$file_name' > '$file_path/utf8_$file_name'"}，右键多个文件 →Build With，生成新文件而非覆盖原文件 - Python 用户可用
chardet先扫一遍：chardet *.py | grep -E 'confidence.*0.9'，筛出高置信度结果再转 - Git 项目建议同步加
.editorconfig：charset=utf-8，避免新人又提交 GBK 文件
Save with Encoding 后还要检查 BOM 和换行符
你以为选了 UTF-8 就万事大吉？Python 读文件报 Non-UTF-8 code starting with '\xef'，Git diff 显示一堆 ^M，八成是这两处没关好。
-
save_with_bom默认为true，但 Python、JSON、Git 都讨厌 UTF-8 BOM，务必设为false - Windows 生成的文件自带 CRLF 换行，Sublime 保存时若没设
default_line_ending，可能混入 CR，建议配"default_line_ending": "unix" - 保存后用
xxd -l 16 文件名看头几个字节：UTF-8 BOM 是ef bb bf，纯 UTF-8 应从可读字符开始
