根本原因是Sublime未按XML声明的encoding属性（如GBK）解析，而用默认编码（如Windows-1252）解码导致方块；需先Reopen with Encoding→匹配声明编码，再Save with Encoding→UTF-8转存。

Sublime Text 打开 XML 文件显示方块或问号

根本不是 XML 文件损坏，而是 Sublime 按默认编码（如 Western (Windows 1252) 或系统 locale 编码）去解析含中文的字节流，而文件真实编码是 GBK、GB2312 或带 BOM 的 UTF-8。插件不能绕过这个前提——必须先人工确认并指定原始编码，否则所有自动转换都可能出错。

ConvertToUTF8 插件已不可靠，别再依赖它

Package Control 官方仓库早在 2025 年底就下架了 ConvertToUTF8，当前搜索到的多数是过期镜像或非官方 fork，容易与 Sublime Text 4 的原生编码逻辑冲突，导致状态栏编码显示错乱、保存后 BOM 残留、甚至静默丢字。ST4 用户尤其要注意：fallback_encoding 字段已被完全移除，插件内部硬编码的 fallback 行为在新版本中失效。

• 不推荐安装任何声称“全自动识别 GBK/UTF-8”的插件——字节重叠区（如 0x81–0xFE）会让纯统计式探测在短文本中误判率超 40%
• 如果已装，建议卸载：Preferences → Package Control → Remove Package → ConvertToUTF8
• 真正需要的只有基础编码支持：确保菜单里能点出 Chinese (GBK) 和 UTF-8 with BOM，若没有，手动放入 Packages/GBK Support/ 目录（非 Package Control 安装）

正确修复 XML 乱码的两步实操流程

以一个声明为 <?xml version="1.0" encoding="GBK"?> 却显示满屏方块的 XML 文件为例：

• 第一步：点击右下角当前编码名（如 UTF-8），选 Reopen with Encoding → Chinese (GBK) —— 这是强制用 GBK 解码器重读磁盘原始字节，不改文件内容，安全可逆
• 第二步：确认中文正常显示后，再执行 File → Save with Encoding → UTF-8（注意不是 UTF-8 with BOM），完成真实转码
• 验证是否干净：终端运行 xxd 文件名.xml | head -n1，输出不含 ef bb bf 才算成功去除 BOM

XML 项目混合编码时的长期配置建议

同一工程里既有 UTF-8 脚本又有 GBK 配置文件，全局设置会顾此失彼。更稳的做法是用项目级绑定：

• 菜单 Project → Save Project As... 生成 .sublime-project 文件
• 在该文件的 "settings" 块内加：

  {
    "default_encoding_on_save": "UTF-8",
    "save_with_bom": false
  }

• 对特定路径启用编码规则（如所有 conf/ 下的 XML）：在同项目文件中添加 "syntax_specific_settings"，配合 file_name 正则匹配

最易被忽略的一点：XML 声明里的 encoding 属性只是提示，Sublime 不会自动读取它；你必须自己看声明、查字节、手动选对编码，机器不会替你做这一步判断。