根本原因是Windows导出的SQL文件在编码、换行、路径和初始化设置上不符合Linux版Navicat解析预期：含UTF-8 BOM头致首行报错、CRLF换行引发语句截断、缺失SET NAMES utf8mb4或Windows路径注释干扰解析，且连接层未设UTF-8字符集。
根本原因不是系统不兼容，而是 Windows 导出的 SQL 文件在编码、换行、路径和初始化设置上默认不符合 Linux 版 Navicat 的解析预期。Linux 版对边缘格式更严格，而 Windows 版常“自动容错”。
文件含 UTF-8 BOM 头导致首行解析失败
Windows 记事本或旧版 Navicat 导出时容易生成带 EF BB BF BOM 的 UTF-8 文件，Linux 版 Navicat 会把 BOM 当作非法字符，使 CREATE DATABASE 或 SET NAMES 等首条语句直接报 ERROR 1064 (42000)。
- 用
head -c 3 your_file.sql | xxd检查：输出含ef bb bf即存在 BOM - VS Code 打开 → 右下角点击编码 → 选
Save with Encoding→UTF-8（无 BOM） - 导入弹窗中必须手动勾选
使用 UTF-8 编码读取文件，该选项在 Linux 版默认常为关闭状态
CRLF 行尾符引发语句截断或注释错位
Windows 默认用
（CRLF），而 Linux MySQL 客户端和 Navicat 解析器依赖
（LF）。当 SQL 含多行 INSERT 或末尾有注释时，CRLF 可能被切在关键字中间，例如把 INSERT 拆成 INSER
T，造成语法错误。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用
file your_file.sql查看：若返回CRLF line terminators，说明是 Windows 风格 - 转 LF 最简命令：
dos2unix your_file.sql（推荐）或sed -i 's/ $//' your_file.sql - 避免用 Linux 自带
gedit或TextEdit保存——它们可能悄悄加回 CRLF 或改编码
缺少 SET NAMES utf8mb4 或路径注释干扰解析
Linux 版 Navicat 不会自动注入字符集声明，且对注释中出现的 Windows 绝对路径（如 -- Source: C:datadump.sql）更敏感，某些版本会误将反斜杠当作转义符处理，导致后续语句偏移。
- 用文本编辑器打开 SQL 文件，确认第一行是
SET NAMES utf8mb4;（不能有空行、BOM 或注释前置） - 全局搜索替换所有
C:\或C:/路径注释，改为 Linux 风格（如/home/user/dump.sql）或直接删掉整行注释 - Linux 版连接属性 → 「高级」页中，必须勾选
Use Unicode UTF-8，并在Initial command填入SET NAMES utf8mb4;
Navicat 连接层未对齐服务端字符集
即使文件编码正确，若 Navicat 连接初始化没设字符集，MySQL 服务端仍按默认 latin1 或 utf8mb3 解析，遇到中文字段名或 emoji 就报 Incorrect string value —— 此时错误看似在 SQL 文件，实则发生在连接握手阶段。
- 检查 MySQL 服务端配置：
SHOW VARIABLES LIKE 'character_set%';，确保character_set_server是utf8mb4 - Navicat 连接属性 → 「高级」→
Initial command必须显式写SET NAMES utf8mb4; - 导入弹窗右下角的「编码」下拉菜单只控制文件读取解码，不改变执行时的字符集；光选 UTF-8 不管用
真正跨平台可用的 SQL 文件，必须同时满足：UTF-8 无 BOM + LF 换行 + 开头有 SET NAMES utf8mb4; + 无 Windows 路径注释。Navicat 导出逻辑本身就不标准化，尤其在 Linux 端对格式洁癖更重，别指望“导出即用”。
