如何修复WordPress在phpMyAdmin中导入时的字符编码损坏？-phpMyAdmin-PHP中文网

mysql导入乱码或#1273错误源于字符集声明与实际字节流错位，需依hex结果分路径处理：e4b8ade69687表明数据实为utf-8只需改声明；c4e3bac3则属latin1乱码被误读，盲目convert会报废；#1273多因mysql版本过低不支持utf8mb4_unicode_ci。

导入时出现乱码或 #1273 – unknown collation 错误，根本不是“显示不全”或“字体问题”，而是 mysql 在解析 sql 文件时，对字符集声明和实际字节流的理解完全错位。必须按真实编码状态分路径处理，不能统一执行 convert to 或盲目替换。

执行 SELECT HEX(column_name) FROM wp_posts LIMIT 1; 看返回值：

如果结果是 E4B8ADE69687（长度为偶数、每两字节可转 UTF-8 字符），说明数据本体是 UTF-8 字节流，只是列被声明为 latin1 或 utf8，MySQL 错误地按单字节解释 —— 这种情况只需改声明，不碰数据
如果结果是 C4E3BAC3（短十六进制串，长度明显偏短），大概率是原始用 latin1 存的乱码，后来又被当 utf8mb4 读了一次，属于“二次错解” —— 此时直接 CONVERT TO utf8mb4 会让内容彻底报废
不确定？先备份整库，再在测试表上对 1–2 行跑 CONVERT 验证效果

这几乎 100% 是目标 MySQL 版本太低（phpMyAdmin 连接层没设 charset。解决顺序如下：

确认 MySQL 版本：SELECT VERSION();；若低于 5.5.3，升级是唯一干净方案
若无法升级，打开 .sql 文件，严格按顺序替换（顺序错会导致语法错误）：
→ 先全局把 utf8mb4_unicode_ci 替换为 utf8_general_ci
→ 再把 utf8mb4_unicode_520_ci 替换为 utf8_general_ci
→ 最后把所有 utf8mb4 替换为 utf8（注意：只换独立单词，避免误伤 utf8mb4_unicode_ci 这类已处理项）
导入时，在 phpMyAdmin 的【SQL 选项】里勾选 忽略校对规则（Ignore the collation）作为临时兜底

只改代码或只改数据库，一半工作等于白做：

PHP 8.5.5

PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。

下载

wp-config.php 中必须有且仅有一组有效定义：
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
删掉旧的 utf8 或空 DB_COLLATE 行
phpMyAdmin 的 config.inc.php 必须设：
$cfg['Servers'][$i]['charset'] = 'utf8mb4';
$cfg['Servers'][$i]['connection_charset'] = 'utf8mb4';
MySQL 服务端需在 my.cnf 的 [mysqld] 段加：
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

即使表结构已设为 utf8mb4_unicode_ci，如果当前连接（比如 phpMyAdmin 页面、PHP 脚本）仍以 latin1 连接，SELECT 出来的仍是乱码，UPDATE 也只会写入新乱码：

在 phpMyAdmin 执行任意 SQL 前，先运行：SET NAMES utf8mb4;，确保本次会话使用正确编码
检查当前连接 charset：SHOW VARIABLES LIKE 'character_set_client'; 和 SHOW VARIABLES LIKE 'collation_connection';，二者都应为 utf8mb4
对关键表如 wp_posts、wp_options 执行转换时，用：
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
—— 仅适用于真实编码已匹配的情况；否则先用 MODIFY 改列声明，不重编码字节