如何解决跨服务器复制数据时的字符集乱码_链路编码对齐-phpMyAdmin-PHP中文网

MySQL跨服务器复制乱码主因是主从character_set_server不一致，须统一为utf8mb4并持久化配置；mysqldump导出导入需全程显式指定--default-character-set=utf8mb4，且应用连接必须初始化时设charset='utf8mb4'。

MySQL 跨服务器复制时 `character_set_server` 不一致导致的乱码

跨服务器复制出现中文变问号、 mojibake 或符号，大概率是主从的 character_set_server 值不一致，而非表或列的字符集本身有问题。mysql 复制默认不校验字符集兼容性，一旦主库用 utf8mb4 写入，从库以 latin1 或旧版 utf8 解析，就直接丢字节。

查主从当前值：SHOW VARIABLES LIKE 'character_set_server';
必须两端完全一致，推荐统一为 utf8mb4（不是 utf8）
修改需重启 MySQL 或动态设（仅对新连接生效）：SET GLOBAL character_set_server = 'utf8mb4';，但持久化必须改配置文件 my.cnf 的 [mysqld] 段落
注意：改完 character_set_server 不会自动转换已有表，需单独 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4;

mysqldump 导出导入链路中的编码断层

用 mysqldump 中转数据时，乱码往往发生在「导出 → 文件保存 → 导入」三步里任意一环编码没对齐。尤其容易忽略终端、SSH 客户端、文本编辑器本身的编码设置。

导出必须显式指定编码：mysqldump --default-character-set=utf8mb4 -u user db > dump.sql；漏掉 --default-character-set 会按客户端默认（常为 latin1）读取，即使表是 utf8mb4 也照样错
生成的 dump.sql 文件本身是二进制流，不是“UTF-8 文本”——它的编码由 mysqldump 决定，和你本地编辑器打开时用什么编码无关
导入时也要带参数：mysql --default-character-set=utf8mb4 -u user db ；否则 mysql 客户端可能用错误编码解析 SQL 流
如果用 source 命令导入，必须先在 mysql 会话里执行：SET NAMES utf8mb4;

SSH + 远程命令管道复制时的终端编码干扰

用 ssh user@host "mysqldump ..." | mysql ... 这类管道方式跨服务器同步，乱码通常不是 MySQL 层的问题，而是 SSH 会话的 LANG 和 LC_ALL 环境变量影响了 mysqldump 的输出编码。

柒源写作

柒源写作是一款面向论文、报告和公文材料的中文 AI 写作平台。

下载

远程执行前强制指定环境：ssh user@host "LANG=C.UTF-8 LC_ALL=C.UTF-8 mysqldump --default-character-set=utf8mb4 db"
本地终端的 LANG 若是 zh_CN.GB18030 或其他非 UTF-8，可能让管道中间截断多字节字符，表现为导入后字段开头或结尾缺字
避免在管道中用 sed、awk 处理 SQL 流——它们默认按字节处理，遇到 utf8mb4 四字节字符极易劈开，产生非法序列

应用层直连双库写入时的连接参数遗漏

有些业务逻辑绕过复制，直接用代码同时往主从写，这时乱码根源常在 JDBC/PHP/PDO 的连接字符串里没声明字符集，导致连接建立后默认用服务器旧值，而应用层又没执行 SET NAMES。

JDBC URL 必须含：?useUnicode=true&characterEncoding=utf8mb4（注意是 utf8mb4，不是 utf8）
PHP mysqli：连接后立刻执行 $mysqli->set_charset('utf8mb4');，不能只靠 mysqli_options($mysqli, MYSQLI_INIT_COMMAND, "SET NAMES utf8mb4");
Python PyMySQL：构造连接时传参 charset='utf8mb4'，且确保 init_command="SET NAMES utf8mb4" 也设上
关键点：字符集声明必须在连接建立时完成，不能等执行 SQL 前才临时 SET，因为某些驱动会把建连后的第一条语句当初始化命令，延迟生效