ConvertToUTF8在Sublime Text 4.4+上已失效，因其自2021年停更、依赖的chardet库与ST4 Python运行时不兼容，导致加载失败、状态栏不显编码、自动重载失灵；应改用持续维护的Codecs37插件。
ConvertToUTF8在Sublime Text 4上根本跑不动
它不是“装了就能用”，而是从ST4.4开始就失去维护支持。插件依赖的chardet底层库与ST4的Python运行时存在ABI不兼容，启动时可能静默失败，或打开GBK文件后状态栏完全不显示UTF-8 (ConvertToUTF8)标识——这说明插件根本没加载。
如果你用的是ST4（尤其是4.4+），别浪费时间调convert_on_load或改encoding_list，先确认是否真在运行：
- 打开
Preferences > Package Settings > ConvertToUTF8 > Settings – User，加一行"debug": true，重启后看Console（Ctrl+`）有没有[ConvertToUTF8]日志 - 没有日志？大概率被ST4跳过加载，此时应立即转向
Codecs37 - 有日志但状态栏无标识？检查是否和其他编码类插件（如
EncodingHelper）冲突，临时禁用再试
Linux/macOS用户必须装Codecs33（不是可选）
ConvertToUTF8在Linux和macOS下无法独立工作，它不自带解码器，全靠Codecs33提供GBK/BIG5等编码的底层字节转换能力。没装它，插件只会检测出编码、却无法正确解码——你看到的仍是乱码，只是状态栏多了一个假的GBK标签。
安装方式严格限定：
- 不能通过Package Control搜
Codecs33——官方源早已移除，搜到的多为篡改版 - 必须手动下载：访问
https://github.com/seanliang/Codecs33/releases，选最新.sublime-package文件 - 放入
Packages/目录后，需重启Sublime，且确保Packages/User/Codecs33.sublime-settings里"enable_codecs": true
Windows DPI缩放导致文件名乱码，不是编码问题
当Windows系统DPI设置＞100%（比如125%或150%），Sublime Text 3会把路径字符串解析错位，表现为：文件标签页显示为???.txt、侧边栏路径变成方块、甚至Preferences > Browse Packages打不开目录——这不是ConvertToUTF8能解决的，是GUI渲染层缺陷。
唯一可靠解法是强制禁用缩放：
- 打开
Packages/User/Preferences.sublime-settings - 加入
"dpi_scale": 1（注意不是"font_face"或"ui_scale"） - 重启生效；若仍异常，还需在快捷方式属性→兼容性→勾选“替代高DPI缩放行为”并选“系统（增强）”
配置encoding_list顺序决定GB2312/GBK识别成败
自动检测失败时，插件会按encoding_list顺序逐个尝试解码。如果把"GB2312"放在"GBK"前面，而文件实际是GBK（含GB2312未覆盖的汉字），就会因解码中途遇到非法字节而中断，最终 fallback 到错误编码。
真实项目中应这样排：
- 简体中文项目：
["GBK", "GB18030", "GB2312"]（GB18030兼容性最广，但速度略慢） - 繁体中文项目：
["BIG5", "BIG5-HKSCS"]（后者支持香港增补字符） - 混编项目：避免把
"UTF-8"写进列表——它会导致插件对UTF-8文件也强行重解码，引发二次乱码
最后提醒一句：ConvertToUTF8从不修改文件原始字节，它只做内存级转码。所以convert_on_save: true看似方便，实则把编辑器变成了“编码黑箱”——你永远不知道磁盘上存的是GBK还是UTF-8，除非盯紧状态栏右下角的实时编码标识。
