Navicat导出SQL文件在其他编辑器中显示空白，几乎确定是UTF-8 BOM（EF BB BF）导致解析失败；需用十六进制工具验证前3字节，再通过sed、PowerShell或Notepad++等清除BOM并保存为UTF-8无BOM格式。
navicat 备份导出的 sql 文件在其他编辑器（如记事本、vs code、sublime）里打开显示为空白，**几乎可以确定是文件开头存在 utf-8 bom（ef bb bf）导致的解析失败**——不是文件真空，而是编辑器因 bom 识别异常而拒读或渲染失败。
用十六进制确认是否含 BOM 头
很多编辑器（尤其是 Windows 记事本、旧版 Notepad++）看到 EF BB BF 就直接放弃解析，不报错也不显示内容。验证方式必须绕过编辑器直查字节：
- Windows 下用 PowerShell：
Get-Content -Path "backup.sql" -Encoding Byte -TotalCount 6 | ForEach-Object { $_.ToString("X2") }→ 若前三个输出是EFBBBF，就是 BOM - macOS/Linux 终端：
xxd -l 6 backup.sql→ 看第一行最左三列是否为ef bb bf - VS Code 打开后右下角显示“UTF-8 with BOM”，就明确告诉你问题所在
Navicat 导出默认带 BOM 是已知行为
Navicat Premium / MySQL / PostgreSQL 版本在「转储 SQL 文件」时，**默认使用带 BOM 的 UTF-8 编码写入**（尤其在 Windows 系统下），这是它内部文本写入逻辑决定的，不是 bug，但和多数命令行工具、数据库客户端（如 mysql 命令行）不兼容。
- 导出时无法在 UI 中关闭 BOM 选项 —— 它压根没提供这个开关
- 即使你手动在 Navicat 里把连接字符集设成
utf8mb4，导出文件编码仍带 BOM - 该 BOM 对 Navicat 自己导入无影响（它自己能跳过），但对其他工具就是硬伤
快速清除 BOM 的实操方法
别重导，直接处理已有文件。以下命令均能安全移除 BOM 且保留内容原样：
- Linux/macOS：
sed -i '1s/^\xEF\xBB\xBF//' backup.sql - Windows PowerShell（管理员权限非必需）：
(Get-Content backup.sql -Raw) -replace "\xEF\xBB\xBF", "" | Set-Content backup.sql -Encoding UTF8 - Notepad++：编码 → “转为 UTF-8 无 BOM 格式” → 保存
- VS Code：右下角点击编码名 → 选“Save with UTF-8”（注意不是“UTF-8 with BOM”）
导出后立即验证的可靠姿势
别等拿到文件再开编辑器看——BOM 问题必须前置拦截：
- 导出完成后，立刻用
xxd -l 8 backup.sql或上述 PowerShell 命令扫一眼头几个字节 - 在终端用
head -n 1 backup.sql | cat -A查看是否有^[[?1h^[类乱码（BOM 的常见可视化表现） - 若需自动化流程（比如脚本定期导出），直接在导出命令后追加 sed 清理，避免人工介入
BOM 是个隐形门槛：它不报错、不提示、不警告，只让文件在你最需要查看的时候变成“透明”。处理它不需要改 Navicat 设置，也不用换工具，关键是养成导出后立刻用二进制方式验头的习惯。
