Navicat 不原生支持 GBK 编码执行 SQL 文件，必须将文件转为 UTF-8（无 BOM），并同步配置连接层 Initial Charset 为 utf8mb4、MySQL 服务端字符集全为 utf8mb4，且目标库/表需显式声明 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci。
直接结论：Navicat 本身不原生支持 GBK 编码执行 SQL 文件，强行用 GBK 文件 + 默认 UTF-8 连接必然导致中文截断或乱码（如 '张三' 变成 '张?' 或主键冲突），必须统一转为 UTF-8（无 BOM）并配齐三层字符集。
确认SQL文件真实编码再操作
别猜，先验证。在 VS Code 或 Notepad++ 中打开文件，右下角看当前编码；若显示 GBK、GB2312 或 ANSI，说明不是 UTF-8。Linux/macOS 下可用：file -i your.sql，输出含 charset=gbk 即确认。
- 不要依赖文件后缀或记事本“另存为”时的默认选项——Windows 记事本保存为“UTF-8”实际是 UTF-8 with BOM，Navicat 解析时可能误读开头三字节
 - VS Code 中选
Reopen with Encoding → GBK看是否恢复中文，再选Save with Encoding → UTF-8转存（务必选“UTF-8”，不是“UTF-8 with BOM”） - 转存后用
xxd your.sql | head -5检查头三字节不是ef bb bf，否则仍是带 BOM
Execute SQL File 必须手动选对编码
Navicat 的 Execute SQL File（右键数据库/连接 → 执行 SQL 文件）弹窗里，“选择文件编码”下拉框是关键开关，它只影响本次读取，不改变连接设置。
- 如果文件刚转为 UTF-8（无 BOM），此处必须选
UTF-8；选GBK会二次错解，变成双乱码 - 如果坚持用原始 GBK 文件（不推荐），此处选
GBK，但必须同步满足：连接高级设置中Initial Charset设为gbk，且 MySQL 服务端character_set_client和character_set_results也得是gbk（实操中极难对齐，易出错） - 该窗口里勾选
遇到错误时继续仅控制执行流，不解决编码问题；乱码引发的语法错误（如引号识别失败）仍会中断
连接层与服务端必须协同为 utf8mb4
即使文件和执行窗口编码全对，若 Navicat 连接参数或 MySQL 服务端默认字符集仍是 latin1 或旧版 utf8，INSERT 后查出来仍是 ??。
- 右键连接 → 编辑连接 → 高级 → 勾选
使用 MySQL 字符集，并在Initial Charset中填utf8mb4（不是utf8） - 执行
SHOW VARIABLES LIKE 'character_set%';，确认character_set_client、character_set_connection、character_set_results全为utf8mb4 - 目标库/表创建语句中必须含
CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci；若导出 SQL 里没这行，手动补或建库前先执行ALTER DATABASE xxx CHARACTER SET = utf8mb4;
为什么不能跳过转码直接用 GBK？
根本矛盾在于 MySQL 协议层限制：MySQL 客户端协议协商字符集时，gbk 不是标准支持值，Navicat 实际会 fallback 到 latin1 或触发隐式转换，导致多字节 GBK 字符被拆成单字节乱码，进而引发字符串截断、主键重复、Incorrect string value 报错。这不是 Navicat 的 bug，而是 MySQL 对非 Unicode 字符集的兼容性设计缺陷。
跨平台（尤其 macOS/Linux + MySQL）环境下，GBK 更不可靠——系统 locale 往往是 en_US.UTF-8，连终端都打不开 GBK 文件，此时硬扛只会放大问题。统一走 UTF-8（无 BOM）+ utf8mb4 是唯一可稳定复现的路径。
