incorrect string value错误源于navicat定时同步未显式声明utf8mb4字符集，需同步配置连接初始化命令（set names utf8mb4）、目标表字段character set utf8mb4及日志解码编码三者一致。
定时同步任务执行失败时提示 Incorrect string value 怎么办
这不是同步逻辑出错，而是 Navicat 在后台执行 SQL 时，连接层未正确声明字符集，导致服务端用 latin1 或 utf8（即 utf8mb3）解析 utf8mb4 字节。定时任务不走交互式查询窗口，不会自动继承你手动设置的「查询 → 字符集 → UTF8」，必须显式固化编码协商过程。
- 编辑该定时任务所用的连接 →「高级」→ 勾选「使用初始化命令」，填入：
SET NAMES utf8mb4; - 若连接已用于其他人工操作，需确认该设置未被覆盖：执行
SELECT @@character_set_client, @@collation_connection;，返回值必须含utf8mb4 - 旧版 Navicat（v15 及更早）若无「初始化命令」选项，在「其他选项」里追加：
characterEncoding=utf8mb4（MySQL）或options=-c%20client_encoding%3DUTF8（PostgreSQL）
同步目标表字段仍显示 latin1_swedish_ci 但源表是 utf8mb4_unicode_ci 怎么办
Navicat 定时同步默认只比对数据内容，不校验字符集定义。即使源表用了 utf8mb4，目标表若建库时没指定，默认继承数据库级 latin1，同步时会把中文当作非法字节拒绝写入。
- 先查目标表真实字符集：
SHOW FULL COLUMNS FROM `target_table`;，重点看Collation列 - 逐字段修正比
CONVERT TO更可靠，尤其对TEXT类型：ALTER TABLE `target_table` MODIFY `content` LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 别信
ALTER DATABASE ... DEFAULT CHARACTER SET—— 这不会修改已有表和字段，只影响后续新建对象
定时任务日志里中文变成 ??? 或 \u5f97\u5230 怎么定位
这是 Navicat 日志模块自身解码错误，不是数据问题。它读取的是服务端返回的原始字节流，若连接初始化失败，日志就按系统 locale（如 Windows 的 GBK）硬解 UTF-8 字节，结果就是问号或 Unicode 转义序列。
- 打开任务日志前，先在对应连接的查询窗口中执行：
SELECT @@character_set_results;，确认返回utf8mb4 - 若返回
latin1，说明「初始化命令」根本没生效，检查是否勾选了「使用初始化命令」且语句末尾有分号 - 导出该次失败日志为文本文件，用 VS Code 打开 → 右下角点击编码 →「Reopen with Encoding」→ 试选
UTF-8和GBK，哪个能还原中文，就反推 Navicat 当前实际用了哪种编码解日志
为什么手动同步成功、定时同步却报错
手动同步走的是当前活动查询窗口的上下文，而定时同步使用独立连接会话，完全不共享窗口级设置。哪怕你在窗口里点了「查询 → 字符集 → UTF8」，定时任务也不会感知。
- 必须把所有字符集控制点都落到连接配置本身：连接属性里的「MySQL 字符集」选
utf8mb4（注意不是utf8）、初始化命令、以及目标表字段定义三者缺一不可 - MySQL 的
utf8是历史遗留 alias，实际是 utf8mb3，不支持 emoji 和部分生僻汉字；utf8mb4才是完整 UTF-8 实现 - PostgreSQL 用户特别注意：
client_encoding必须显式传参，Navicat 不会从系统 locale 自动推断，漏掉就会 fallback 到SQL_ASCII或GBK
