php连接mysql中文乱码的根本原因是客户端、连接层、表结构三者编码不一致，须统一为utf8mb4：建库建表时显式指定，连接后立即执行SET NAMES utf8mb4或set_charset(‘utf8mb4’)，pdo需在DSN中写charset=utf8mb4并建议exec(“SET NAMES utf8mb4”)。
PHP 连接 MySQL 时中文显示为问号或乱码
根本原因通常是客户端、连接层、表结构三者编码不一致，而非单纯改 PHP 文件编码。重点不是 mb_internal_encoding() 或文件保存格式，而是连接建立时的字符集声明。
- 确认 MySQL 服务端默认编码（
SHOW VARIABLES LIKE 'character_set_server';），推荐设为utf8mb4 - 建库建表时显式指定字符集：
CREATE database db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - PHP 连接后**立即**执行
SET NAMES utf8mb4;（PDO 或 mysqli 均需） - mysqli 方式下，优先用
$mysqli->set_charset('utf8mb4');而非query("SET NAMES ...")，更可靠
PDO 连接字符串里加 charset 参数没生效？
常见于 PDO 构造时写了 charset=utf8 却仍乱码——因为 utf8 是 MySQL 的伪标准，实际只支持 3 字节 UTF-8；必须用 utf8mb4。
- 正确写法：
$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', $user, $pass); - 即使 DSN 中指定了 charset，仍建议显式调用
$pdo->exec("SET NAMES utf8mb4");防止某些驱动忽略 - 若使用持久连接（
PDO::ATTR_PERSISTENT => true），charset 设置可能被复用旧连接状态，务必在每次操作前检查
mysqli_real_escape_string() 处理中文失败报 Warning
该函数依赖当前连接的字符集。如果连接未正确设为 utf8mb4，它会对多字节字符截断或误判，直接导致 SQL 错误或注入风险。
- 必须在调用前确保连接已设置字符集：
$mysqli->set_charset('utf8mb4'); - 若用面向对象风格，
$mysqli->real_escape_string($str)才安全；过程式mysqli_real_escape_string($mysqli, $str)第一个参数不能是空或未初始化句柄 - 现代开发更推荐预处理语句（
prepare()+bind_param()），完全规避转义问题
phpMyAdmin 显示正常但 PHP 输出乱码
说明数据库和表结构编码没问题，问题出在 PHP 与 MySQL 的「通信协议层」。phpmyadmin 默认会发 SET NAMES utf8mb4，而你的 PHP 脚本没发。
立即学习“PHP免费学习笔记（深入）”；
- 检查是否漏掉连接后的字符集设置，尤其是用了封装类或框架时，可能隐藏了这一步
- 用
$mysqli->client_info和$mysqli->get_charset()实际验证当前连接使用的字符集 - 浏览器响应头也可能干扰：确保 PHP 没输出
Content-Type: text/html; charset=gbk类似语句，或 HTML meta 中声明了错误编码
实际调试时，最易忽略的是「连接复用场景」——比如连接池、长连接、框架自动管理的 PDO 实例，它们可能在首次连接后就没再重置 charset。每次获取连接后做一次 set_charset() 或 exec("SET NAMES ...") 是成本最低的保险做法。