phpMyAdmin 不修复乱码,需同步配置 MySQL 服务端(character_set_server=utf8mb4)、phpMyAdmin 连接层(charset=‘utf8mb4’)、Laravel 数据库配置(charset=utf8mb4)及已有表字段编码,缺一不可。
直接说结论:phpMyAdmin 本身不修复乱码,它只是暴露问题的窗口。真正要动的是 MySQL 服务端配置、表结构、连接层设置三处,缺一不可。
这是绝大多数 Laravel 中文乱码的起点。哪怕你在 phpMyAdmin 里看到“简体中文”选项,如果 character_set_server 是 latin1 或 utf8(MySQL 的 3 字节伪 UTF-8),Laravel 插入 emoji 或生僻字就会报错 1366 Incorrect string value。
SHOW VARIABLES LIKE 'character_set_server';,确认返回值是 utf8mb4
/etc/mysql/my.cnf(Linux)或 my.ini(Windows),在 [mysqld] 段下添加:character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
systemctl restart mysql),否则配置不生效phpMyAdmin 默认用 SET NAMES utf8 初始化连接,但在 MySQL 8.0+ 中,utf8 是别名,实际指向 utf8mb3,导致 Laravel 写入的 4 字节字符被截断。
config.inc.php,找到对应服务器配置块($cfg['Servers'][$i])$cfg['Servers'][$i]['charset'] = 'utf8mb4';
$cfg['Servers'][$i]['connection_charset'] = 'utf8mb4';
default_charset(php.ini 中)是否为 UTF-8(注意是连字符,不是 utf8)改完服务端和连接层,旧表不会自动升级。直接跑 ALTER TABLE xxx CONVERT TO CHARACTER SET utf8mb4 很危险——如果数据原本就是乱码编码(比如被当 latin1 存的 UTF-8 字节),这条命令会二次损坏。
SELECT HEX(column_name) FROM table_name LIMIT 1; 看真实字节。返回类似 E4B8ADE69687(“中文”的 UTF-8 十六进制),说明数据本身正确,只是声明错了 → 改列定义:ALTER TABLE table_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
C4E3BAC3 这类短字节,大概率是 GBK 或 GB2312 编码 → 需按原始编码反向转换,不能硬转$table->string('title')->charset('utf8mb4');
很多人只改了 phpMyAdmin 和 MySQL,却忘了 Laravel 自己也有一套连接参数。即使数据库和界面都对了,Laravel 仍可能走默认 utf8 连接,导致写入失败。
config/database.php 中 mysql 配置:'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'options' => [PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci"]
.env 里的 DB_CHARSET=utf8mb4 —— Laravel 最新代码根本没读这个变量php artisan tinker 中执行 DB::connection()->getPdo()->getAttribute(PDO::ATTR_CLIENT_VERSION) 返回的连接字符集是 utf8mb4
最容易被忽略的点:phpMyAdmin 只是工具,它不决定字符流向;真正的控制权在 MySQL 服务端、连接初始化命令、表字段声明这三层。任何一层掉链子,中文或 emoji 就会出问题,而且症状可能完全不同——有的显示问号,有的直接报错,有的看起来正常但查不出来。动手前,先用 SHOW VARIABLES LIKE 'character_set%' 和 SHOW CREATE TABLE 把当前状态拍下来,比盲目改配置靠谱得多。