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") } → 若前三个输出是 EF BB BF，就是 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 且保留内容原样：

navicatmysql

Navicat For MySQL

下载

• 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 设置，也不用换工具，关键是养成导出后立刻用二进制方式验头的习惯。