WordPress网站迁移数据库编码乱码修复
WordPress迁移后出现中文乱码,多数是数据库字符集与表、字段或连接层不一致造成的。
修复前先完整备份,再统一为 utf8mb4,最后检查 wp-config.php 和 wp_posts 内容。
先判断乱码范围
迁移后乱码常见三种表现:页面显示“?
??
?”、显示“锟斤拷”或方块、后台编辑时正常但前台乱码。
打开 phpMyAdmin 或命令行查看表结构:
SHOW CREATE TABLE wp_posts;
重点看 CHARSET 是 utf8、latin1 还是 utf8mb4。
如果源站是 utf8mb4,目标库却是 latin1,中文就会损坏。
迁移前的准备与备份
操作前先备份数据库和网站文件,避免二次损坏:
mysqldump -u root -p --default-character-set=utf8mb4 wordpress > wordpress_backup.sql
宝塔面板用户可在“数据库”页面点击“备份”。
同时确认目标服务器 MySQL 版本支持 utf8mb4,一般 MySQL 5.5.3 以上即可。
修复数据库字符集
如果表结构仍是旧字符集,用命令逐库转换。
先进入 MySQL:
mysql -u root -p
然后执行:
ALTER DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
再批量转换表和字段。
以下命令会生成 ALTER 语句,复制结果执行:
SELECT CONCAT('ALTER TABLE ', TABLE_NAME, ' CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;') FROM information_schema.TABLES WHERE TABLE_SCHEMA='wordpress';
执行后再次用 SHOW CREATE TABLE wp_posts; 验证,CHARSET 应变为 utf8mb4。
检查 wp-config.php 连接配置
数据库字符集统一后,还要确保 WordPress 连接层一致。
编辑网站根目录 wp-config.php,在 DB_COLLATE 附近确认或添加:
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
如果原文件已有 DB_CHARSET,改为 utf8mb4 即可。
保存后重启 PHP-FPM 或清空缓存:
systemctl restart php-fpm
宝塔面板路径:网站 → 设置 → 配置文件,也可直接修改。
避坑与常见问题
不要直接导出再导入就完事:如果导出时未指定 --default-character-set=utf8mb4,导入后仍可能乱码。
表转换前必须备份:CONVERT TO CHARACTER SET 会重建表,数据量大时耗时较长,中途失败可能损坏表。
部分字段仍乱码:检查 wp_posts 的 post_content、post_title 字段,以及 wp_options 中的站点标题和 URL。
可单独转换:
ALTER TABLE wp_posts MODIFY post_content LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
主题或插件语言包乱码:确认文件本身是 UTF-8 无 BOM 编码,可用 file -i 检查。
验证修复结果
访问前台首页、文章页和后台编辑器,检查中文是否正常。
推荐用以下命令确认数据库连接字符集:
SHOW VARIABLES LIKE 'character_set%';
character_set_client、character_set_connection、character_set_results 都应为 utf8mb4。
如果仍有问号,检查浏览器编码是否被强制为 GBK。
最后,用 mysqldump 重新导出一份备份,确认导出文件编码正确:
mysqldump -u root -p --default-character-set=utf8mb4 wordpress > wordpress_fixed.sql
打开 SQL 文件查看中文是否正常,若正常说明修复完成。
修复WordPress迁移数据库编码乱码的核心是统一字符集为 utf8mb4,并确保连接层和文件编码一致。
按备份、检测、转换、验证的顺序操作,多数乱码问题可以解决。
如果表数据已损坏,建议从原始备份重新导入后再执行转换。