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。这个细节一旦漏掉，所有后续操作都是在错误元数据上打补丁。
