Navicat 16跨字符集连接乱码需在三处显式设置：源库与目标库连接属性中的Character Set、数据传输向导中勾选Convert character set并手动指定目标字符集（如gbk→utf8mb4），且必须使用Data Transfer功能而非备份还原。
Navicat 16 连接不同字符集数据库时乱码怎么办
直接连上就导，大概率出错。navicat 本身不自动转码，utf8mb4 和 gbk 库之间如果没显式指定连接字符集，select 结果会变形，插入时更可能报 incorrect string value 错误。
关键不是“能不能对调”，而是“在哪一环控制编码”。必须在三处分别确认并显式设置：
- 源库连接属性里的
Character Set（不是服务器默认值，是连接级） - 目标库连接属性里的
Character Set - 数据传输向导中勾选
Convert character set并手动选目标库实际支持的字符集（比如从gbk→utf8mb4，这里填utf8mb4）
用数据传输向导做跨字符集对调的实操要点
别用“备份/还原”，那会原样复制表结构和字符集定义，起不到转换作用。必须走 Data Transfer 功能，且注意几个硬性限制：
- 源表和目标表结构需一致（字段名、类型、长度），否则传输会跳过或报错；
VARCHAR(255)在gbk下最多存 255 字节，在utf8mb4下可能只够存 63 个汉字，要提前检查 - 目标库必须已存在，且字符集设为你要转成的目标（如
CREATE DATABASE db2 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci） - 传输前关闭
Auto-commit，否则中途失败无法回滚；勾选Continue on error可让非关键错误（如重复主键）不停止整个流程
遇到 “Data too long” 或 “Illegal mix of collations” 怎么办
这不是 Navicat 的 bug，是 MySQL 层面的字符集冲突暴露出来了。典型场景：源库字段是 CHAR(10) CHARSET gbk，目标库同名字段是 CHAR(10) CHARSET utf8mb4，但 Navicat 按字节长度校验，发现 utf8mb4 下 10 字节存不下原来 gbk 的 10 个汉字（因为一个汉字在 gbk 占 2 字节，在 utf8mb4 最多占 4 字节）。
解决路径只有两条：
- 改目标表字段长度：比如把
CHAR(10)改成CHAR(20)或直接用VARCHAR，再运行传输 - 提前在源库用
CONVERT(col USING utf8mb4)做一次清洗，再导出中间 SQL 文件，手动替换CHARSET gbk为CHARSET utf8mb4，最后导入
为什么不能靠 Navicat 自动识别字符集
Navicat 读取 information_schema.COLUMNS 里的 character_set_name，但这只是字段定义，不反映实际存储内容的真实编码。如果某张 gbk 表里混入了 utf8 编码的脏数据（常见于程序写入未指定连接 charset），Navicat 会按 gbk 解码，显示为乱码，再以 utf8mb4 写入目标库——结果就是双倍乱码。
所以真正安全的做法是：
- 先用
SHOW CREATE TABLE确认源表定义 - 用
SELECT HEX(col) FROM t LIMIT 1看真实字节，比对是否符合预期编码 - 必要时用
CONVERT(... USING ...)或CAST(... AS ...)在 SQL 层做显式转换，再进 Navicat 传输
跨字符集对调从来不是点几下就能完的事，核心在于你得清楚每个字节从哪来、到哪去、中间经过几次解码/编码。Navicat 只是管道，堵在哪，得自己查。
