Navicat报Unknown Command错误大概率是SQL文件含UTF-8 BOM（EF BB BF）或非法控制字符，导致解析首行失败；需用VS Code或Notepad++转为“UTF-8无BOM”编码并验证head -n 5输出是否正常。
Navicat报Unknown Command错误，大概率是文件开头有BOM或非法控制字符
这个错误不是语法问题，而是navicat在读取sql文件第一行时，遇到不可见的字节（比如utf-8 bom头 ef bb bf），把它当成了sql命令去解析，于是报出 unknown command '\ufeff' 或类似提示。你打开文件可能看不到异常，但编辑器底层已经“中毒”了。
- 用VS Code打开SQL文件，右下角查看编码：如果显示
UTF-8 with BOM，必须转成UTF-8（注意不含BOM） - Notepad++用户：菜单栏「编码」→「转为UTF-8无BOM格式」→ 保存
- 别信“另存为UTF-8”——很多编辑器默认加BOM；一定要确认状态栏明确写着“UTF-8 无BOM”或“UTF-8 (no BOM)”
- Mac上用TextEdit打开再另存，极大概率悄悄塞进BOM；改用VS Code或BBEdit更可靠
导入前用head命令快速验证文件是否干净
Windows用户可用PowerShell，macOS/Linux直接用终端，快速检查文件前几行有没有乱码或异常符号：
head -n 5 your_file.sql
正常输出应该从 -- MySQL dump 或 CREATE DATABASE 这类可读语句开始。如果第一行是空、全是问号、或者出现 、，基本就是BOM或编码错乱。这时候别急着点“开始”，先修文件。
-
是UTF-8 BOM在ANSI环境下的典型乱码表现 - 如果看到
^@^@^@或\0\0\0，说明文件被二进制写入过（比如用Excel另存为CSV再改后缀），已损坏，需重导 - 部分备份工具（如旧版phpMyAdmin）会在文件头插入不可见的零宽空格（
\u200B），VS Code开启「显示所有字符」可识别
Navicat里勾选“使用UTF-8编码读取文件”不等于万能
这个选项只影响Navicat读取文件时的解码方式，它不会帮你过滤掉BOM、也不会修正已损坏的字节流。如果文件本身带BOM，Navicat即使勾选了该选项，仍会把BOM当命令解析，照样报 Unknown command。
- 该选项只在Navicat 15+版本中可见；老版本（如12）根本没这个开关，必须靠外部修文件
- 勾选后仍报错？说明问题不在读取路径，而在文件内容本身——回头再用
head或十六进制编辑器（如HxD）看前16字节 - 某些SQL文件含Windows风格换行
\r\n+ BOM，Linux服务器环境下更易触发解析失败，统一用LF换行+无BOM最稳妥
命令行导入也报Unknown Command？说明问题出在连接层而非Navicat
如果你改用 mysql -u root -p db_name 也报同样错误，那问题一定在MySQL客户端初始化阶段，和Navicat无关。
- 必须加
--default-character-set=utf8mb4参数启动客户端：mysql --default-character-set=utf8mb4 -u root -p db_name - 只在连接后执行
SET NAMES utf8mb4没用——source命令读取文件时，客户端已按默认字符集解码完毕 - 若目标库用的是
gbk，而文件是UTF-8，强行指定--default-character-set=gbk会导致更严重的乱码和解析中断
BOM和非法控制字符这类问题，往往藏得深、报错假、修复快。真正卡住人的，常常不是“找不到错在哪”，而是误以为是SQL语法或权限问题，结果在错误方向上反复折腾。修完文件再导入，90%的Unknown Command就消失了。
