混合编码文件需设 "detection_strategy": "aggressive" 并调低 min_confidence_threshold 至 0.75～0.85，配合 fallback_encodings 和 ignore_bom: false；save_to_original_encoding 必须设为 false 才能真正保存为 UTF-8。
ConvertToUTF8 的 detection_strategy 怎么选
混合编码文件（比如前半段是 GBK，后半段混了 UTF-8 BOM 或 Shift_JIS 片段）不是靠“猜一次”就能搞定的，detection_strategy 直接决定插件是否愿意多花时间做交叉验证。
默认值 "detection_strategy": "normal" 只扫前几百行、用主探测器快速出结果，对纯 GBK 或纯 BIG5 文件够用，但遇到混合内容大概率只识别开头那段，后面就显示乱码。
-
"aggressive"：强制启用所有探测器（GBK/BIG5/EUC-JP/Shift_JIS），扫描深度拉到probing_depth: 4096，适合已知含日文/韩文/繁简混排的配置文件或日志 -
"conservative"：跳过低置信度结果，宁可报错也不强行转换，适合金融、政务等对字符零容忍的场景 - 别设
"detection_strategy": "auto"—— 这个值在 ConvertToUTF8 v3.2+ 已被移除，设了会静默失效
fallback_encodings 配置为什么总不生效
很多人在 ConvertToUTF8.sublime-settings 里写了 "fallback_encodings": ["GB18030", "CP936"]，但打开一个无 BOM 的 GBK 文件还是乱码。根本原因不是配置写错，而是 fallback 机制只在「自动检测完全失败」时才触发，而 ConvertToUTF8 默认优先走 chardet 式统计分析 —— 即使它把 GBK 错判成 ISO-8859-1，也不会退到 fallback 列表。
真正起作用的是 "min_confidence_threshold"：设成 0.7 会让插件更早放弃低置信判断，从而激活 fallback；设成 0.95 则宁可显示乱码也不妥协。
- 混合文件建议设为
0.75～0.85，配合"fallback_encodings": ["GB18030", "CP936", "BIG5"] - 如果文件带部分 UTF-8 BOM（如开头几个字节是
EF BB BF，但后面全是 GBK），需额外加"ignore_bom": false，否则 BOM 会被直接剥离，导致后续字节偏移错乱 - Windows 路径含中文时，
fallback_encodings可能因插件初始化阶段读取路径失败而整体失效 —— 这是已知兼容问题，临时解法是把项目移到英文路径下
Save with Encoding 和插件自动保存行为冲突怎么办
点了 File → Save with Encoding → UTF-8，但下次打开还是显示 GBK，或者状态栏右下角明明标着 UTF-8，一保存却写回了原 GBK 编码 —— 这不是 bug，是 ConvertToUTF8 的默认策略：save_to_original_encoding 默认为 true，即“内存中转成 UTF-8 显示，磁盘上仍按原始编码存”。
想统一存为 UTF-8，必须显式关掉它：
{
"save_to_original_encoding": false,
"auto_convert_on_save": true
}
注意两个细节：
-
auto_convert_on_save控制是否在保存前自动转码；若为false，即使save_to_original_encoding关了，也只保存当前内存里的 UTF-8 内容，但不会主动重编码原始字节（比如你手动 reopen 成 GBK 后编辑，再保存，仍会写 GBK） - 关掉
save_to_original_encoding后，插件不再保留原始编码元数据，所以无法“一键还原回 GBK” —— 如果需要双向兼容，得靠外部工具如iconv备份 - Sublime Text 4 用户要注意：某些 412x 版本中该配置项名曾短暂改为
save_as_utf8，现已统一回save_to_original_encoding，旧配置会失效
为什么有些混合文件连 aggressive 模式都救不了
当文件里同时存在 GBK 中文、UTF-8 emoji、Shift_JIS 片段（如 Windows 日文路径）、以及几行 Base64 编码的二进制数据时，任何基于文本特征的探测都会崩。这不是插件能力不足，而是这类文件本质上已超出“文本编辑器”的处理边界 —— 它们更接近二进制容器。
此时唯一可靠的做法是分层处理：
- 先用
xxd或hexdump -C查看真实字节，确认哪些区域是纯文本、哪些是二进制 - 用
File → Reopen with Encoding → UTF-8强制加载，然后手动选中 GBK 区域 →Right-click → Convert Encoding → GBK（需安装 EncodingHelper 插件） - 对无法识别的片段，复制到在线工具如 WHATWG Encoding Standard tester 验证字节序列
- 最终保存前务必检查状态栏右下角是否稳定显示
UTF-8—— 如果它在你编辑过程中反复跳变成Western (ISO 8859-1)，说明仍有未识别的非法字节残留
真正的难点不在“怎么转”，而在“哪一段该用哪种规则转”。自动工具只能覆盖常见模式，混合越深，越得人工锚定边界。
