根本原因是MySQL服务端、连接层、表结构、WordPress配置四者字符集不一致；必须确保character_set_server为utf8mb4，phpMyAdmin连接层设utf8mb4，WordPress配置DB_CHARSET='utf8mb4'，修复旧表时先用HEX()确认真实编码再选择MODIFY或CONVERT。
phpMyAdmin 管理 WordPress 数据库时出现乱码，根本原因不是界面显示问题，而是 MySQL 服务端、连接层、表结构、WordPress 配置四者字符集不一致，其中任意一环是 latin1 或旧版 utf8（即 utf8mb3），都会导致中文或 emoji 显示为问号、方块或 æ–‡ 类乱码。
检查 MySQL 服务端默认字符集是否为 utf8mb4
这是最常被忽略的底层前提。即使你在 phpMyAdmin 里选了中文、建库时选了 utf8mb4_unicode_ci，只要 character_set_server 是 latin1，新表默认仍会继承错误编码。
- 登录 MySQL 命令行，执行
SHOW VARIABLES LIKE 'character_set_server';—— 必须返回utf8mb4 - 若不是，编辑
/etc/mysql/my.cnf（Linux）或my.ini（Windows），在[mysqld]段下添加：[mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci
- 重启 MySQL：
sudo systemctl restart mysql（或对应服务名） - 注意：MySQL 5.5.3 以下版本不支持
utf8mb4，必须升级；5.7+ 和 8.0 默认已是utf8mb4，但需确认未被配置覆盖
强制 phpMyAdmin 连接层使用 utf8mb4
phpMyAdmin 默认执行 SET NAMES utf8，而 MySQL 8.0+ 已将 utf8 别名禁用，实际等价于 utf8mb3，无法存取 emoji 或部分生僻字。
- 打开
config.inc.php，找到对应服务器配置段（通常是$cfg['Servers'][$i]） - 显式设置两处：
$cfg['Servers'][$i]['charset'] = 'utf8mb4'; $cfg['Servers'][$i]['connection_charset'] = 'utf8mb4';
- 确保 PHP 的
default_charset在php.ini中设为UTF-8（注意是连字符，不是utf8） - 若用 Nginx + PHP-FPM，还需检查
fastcgi_param PHP_VALUE "default_charset = UTF-8";是否生效
修复已有 WordPress 表的字符集（别用 CONVERT TO）
直接对已乱码数据执行 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 是高危操作，会把本就错解的字节二次转码，造成不可逆损坏。
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
立即学习“PHP免费学习笔记（深入）”；
- 先确认字段真实编码：运行
SELECT HEX(column_name) FROM wp_options WHERE option_name = 'blogname' LIMIT 1; - 若返回类似
E4B8ADE69687（UTF-8 编码的“中文”），说明数据本身完好，只是被当latin1解释了 → 正确做法是改列声明：ALTER TABLE wp_options MODIFY option_value LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
- 若返回
D6D0CEC4（GBK 编码的“中文”），则需按原始编码反向转换，不能硬套utf8mb4 - WordPress 核心表如
wp_posts、wp_postmeta、wp_options需逐个处理，不要跳过MODIFY直接CONVERT
同步修正 WordPress 自身配置
phpMyAdmin 只是数据库入口，WordPress 应用层若仍用旧编码连接，写入数据时就会再次出错。
- 检查
wp-config.php是否有且仅有一行：define('DB_CHARSET', 'utf8mb4');（不是utf8） - 确认
DB_COLLATE为空或设为''（让 MySQL 自动匹配） - 所有 WordPress 文件（尤其
wp-config.php）必须保存为UTF-8 无 BOM格式；用 VS Code 或 Notepad++ 检查并转换 - 导入 SQL 文件前，务必确认导出文件本身不含 BOM，且第一行没有空白或注释干扰
CREATE DATABASE语句
真正容易被忽略的是「旧数据的真实编码状态」——它决定了你该用 MODIFY 还是 CONVERT，而这个判断只能靠 HEX() 结果反推，没法靠肉眼或猜测。一旦跳过这步直接批量转换，恢复成本远高于从备份重来。
