Navicat跨平台开发中编码不一致必然导致乱码或报错，需同步SQL文件编码、MySQL连接字符集（SET NAMES utf8mb4）及Navicat客户端解析行为；导出SQL须清理CRLF、BOM和Windows路径；连接配置迁移须用内置导出/导入功能并确保UTF-8与服务端utf8mb4匹配。
navicat 跨平台开发中，编码不一致不是“偶尔出问题”，而是只要 windows 和 linux/macos 混用，就一定会在某个环节爆出来——核心矛盾在于：sql 文件编码、mysql 连接层字符集、navicat 客户端解析行为，三者必须手动对齐，缺一不可。
导出的 SQL 文件在 Linux 上执行前必须清理 Windows 痕迹
Windows 导出的 SQL 文件默认带 CRLF 换行、可能含 UTF-8 BOM、注释里还藏着 C:\path\to\table.sql 这类路径。Linux MySQL 客户端（包括 Navicat 自身）不会自动转换这些，直接执行会报语法错误或静默跳过中文字段定义。
- 用
dos2unix backup.sql统一换行为 LF - 用 VS Code 打开 → 右下角点击编码 →
Save with Encoding→ 选UTF-8 (no BOM) - 全局搜索替换所有 Windows 路径注释，例如把
-- Source: C:\projects\dump.sql改成-- Source: /home/user/dump.sql - 确保首行是
SET NAMES utf8mb4;，且前面不能有空行或 BOM
Linux 版 Navicat 导入时的编码下拉菜单只是个假象
导入弹窗右下角的「编码」下拉菜单只控制文件读取解码，不改变 MySQL 执行时的字符集。即使你选了 UTF-8，若连接没设 SET NAMES utf8mb4，照样报 Incorrect string value。
- 在 Navicat 连接属性 → 「高级」页中，必须勾选
Use Unicode UTF-8 - 在同一页面的
Initial command框里填入：SET NAMES utf8mb4; - 别信「自动检测编码」——Linux 版 Navicat 常把带 BOM 的 UTF-8 文件识别为
ISO-8859-1，中文全变问号 - 导入前先确认终端 locale：
locale | grep UTF-8，不是就临时执行export LANG=en_US.UTF-8
跨平台连接配置迁移后中文名乱码或密码失效
Navicat 的 connections.nex（v16+）或 connections.ncx（v15 及以前）是用本机用户密钥 AES 加密的，直接复制到另一系统上基本打不开。更隐蔽的问题是：Windows 默认用 GBK 存连接名，macOS/Linux 用 UTF-8，老版本（v12–v14）导出时可能误判编码。
- 必须用内置功能导出：右键连接 →
Export Connection→ 勾选Include password→ 保存为.ncx文件 - 导入时不能双击打开，要在目标 Navicat 中执行
文件 → 导入连接→ 选该.ncx文件 - 导入后密码字段仍为空？说明导出时没勾选包含密码，或目标端 Navicat 版本太低（v15 不支持该选项）
- 连接名含中文却显示乱码或截断？优先升级到 v15+，它们统一强制 UTF-8 处理元数据；若必须用旧版，导出前先把连接名临时改成英文
最常被忽略的一点：Navicat 本身不参与字符集转换，它只是把 SQL 语句原样发给 MySQL 服务端。所以哪怕你把所有客户端设置调得再完美，只要 MySQL 服务端的 character_set_server 或数据库/表级字符集不是 utf8mb4，乱码依然会发生——这一步必须在服务端确认，不能只靠 Navicat 设置蒙混过关。
