navicat协作乱码本质是连接层、表结构、同步脚本三处字符集未对齐,须按角色动作分别控制:连接需设utf8mb4并测试生效;结构比对须勾选compare collations;数据同步需单独配置utf8mb4;sql文件须手动指定编码并加set names utf8mb4。
navicat协作中字符集不一致,本质是多人操作时连接层、表结构、同步脚本三处编码未对齐,不是“配一次就完事”的问题,必须按角色和动作分别控制。
协作前必须统一每个人的 Navicat 连接字符集设置
不同人新建的连接默认走 latin1 或 utf8(非 utf8mb4),哪怕连同一台 MySQL,查出来的中文也可能一个正常、一个问号。这不是数据问题,是连接握手阶段就错了。
- 右键连接 → 编辑连接 → 高级 → 勾选
Override default charset→ 下拉选utf8mb4(不是utf8) - 如果下拉菜单里没有
utf8mb4,在「其他选项」框里手动加:characterEncoding=utf8mb4 - 务必点「测试连接」成功后再保存——仅点确定不测试,该设置不会生效
- 旧连接不要改,直接新建一个带
utf8mb4的连接并重命名(如加后缀_v2),避免误用残留配置
结构比对失败常因 collation 被忽略,而非字符集本身
Navicat 默认不比对排序规则(collation),但只要源表用 utf8mb4_0900_ai_ci、目标表是 utf8mb4_unicode_ci,即使字段类型完全一样,也会标红报“结构不一致”。这不是误报,是它把 collation 差异归进了整体结构差异里。
- 右键比对任务 → 选项 → 对象比较设置 → 必须勾选
Compare collations和Compare column character sets - 比对前先统一目标表 collation:执行
ALTER TABLE `t` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 若表含全文索引或生成列,
CONVERT TO会失败,改用MODIFY COLUMN逐列处理,例如:ALTER TABLE `t` MODIFY `name` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 批量改多张表?别手敲,用
SELECT CONCAT('ALTER TABLE `', table_name, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;') FROM information_schema.tables WHERE table_schema = 'your_db';生成语句再执行
同步数据时乱码,根源在同步连接独立于主连接
Navicat「数据同步」功能会新建一个连接,完全不继承你主连接里设好的 utf8mb4。即使主连接一切正常,同步仍可能把 utf8mb4 字节当 latin1 解,结果存进目标库的是 æäº›å 这类十六进制乱码,且不可逆。
- 启动同步向导后,在「连接设置」页 → 点击「编辑连接」→ 高级 → 同样勾选
Override default charset并选utf8mb4 - 或者在「其他选项」里加:
characterEncoding=utf8mb4 - 同步前在「SQL 过滤」或「初始化 SQL」里写
SET NAMES utf8mb4是无效的——同步走二进制协议,不解析 SQL 文本 - 验证是否生效:同步完成后立刻在目标库执行
SELECT HEX(col_name) FROM t LIMIT 1;,若结果是 6 字节(如E69F90E4BAA7E5AD97),说明源发的是 utf8mb4 字节,但被错解了
自动化脚本执行中文乱码,文件编码与连接声明必须双控
团队共用一个 .sql 脚本,有人用 VS Code 保存为 UTF-8(无 BOM),有人用记事本保存为 UTF-8 with BOM,Navicat 默认不识别真实编码,读错一个字节,整个 INSERT 就全乱。
- 运行 SQL 文件前,右键连接 → 「运行 SQL 文件」→ 选文件 → 弹窗右上角点「编码」按钮 → 明确选
UTF-8或UTF-8 with BOM(不要选「自动检测」) - 脚本第一行必须加:
SET NAMES utf8mb4;(不是utf8,否则 emoji 和生僻字会丢) - 删掉脚本里所有
SET NAMES latin1、SET character_set_client = gbk这类覆盖性语句 - 脚本中建表语句必须显式声明字符集,例如:
CREATE TABLE `t` (`name` VARCHAR(100)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;,不能依赖库级默认值
协作场景下最易被忽略的点:没人会去检查别人建的表字段是否真带 CHARACTER SET utf8mb4 子句。SHOW CREATE TABLE 一眼就能看出,但多数人只扫 CREATE TABLE 开头,跳过末尾的 DEFAULT CHARSET 和字段后的 COLLATE。这个细节一旦漏掉,所有后续操作都是在错误元数据上打补丁。











