phpMyAdmin 本身不参与业务SQL拼接，字符集注入根源在于PHP应用与MySQL连接层编码不一致；需确保PHP连接、数据库表、文件编码均为utf8mb4，并禁用mysql_*函数。
phpMyAdmin 本身不处理字符集注入，真正出问题的是你用它管理的 PHP 应用 + MySQL 组合。所谓“非标准字符集注入”，本质是宽字节注入（如 GBK）或编码不一致导致 mysqli_real_escape_string() 失效，让单引号、反斜杠等绕过转义。phpMyAdmin 只是数据库操作界面，它不参与你的业务 SQL 拼接逻辑——所以防护点不在 phpMyAdmin 配置里，而在你连它的那套 PHP 代码中。
为什么 phpMyAdmin 的字符集设置不能防注入
你在 phpMyAdmin 界面看到的 $cfg['DefaultCharset'] 或「操作 → 字符集」选项，只影响它自己渲染 SQL 查询结果时的显示编码，和后端 PHP 应用执行的 SQL 完全无关。即使你把 phpMyAdmin 设成 utf8mb4，如果 PHP 脚本用 SET NAMES gbk 连接 MySQL，且又用了 mysql_real_escape_string()（已废弃）或没配对的 mysqli_set_charset()，宽字节漏洞依然存在。
常见错误现象：
- 输入
%df%27（GBK 编码下的非法字节 + 单引号）绕过转义，触发 SQL 注入 - phpMyAdmin 显示乱码，但业务页面却能查出数据——说明应用层和数据库层编码实际不一致
- 用 phpMyAdmin 手动执行
SELECT * FROM users WHERE name = 'admin' OR 1=1-- '成功，但这只是验证了 SQL 语法，不是注入入口点
真正要检查的三个连接层编码是否对齐
MySQL 注入能否利用宽字节，取决于客户端、连接、表三者是否统一。只要其中一层是 GBK / BIG5 等多字节编码，而你的 PHP 转义函数没同步适配，就可能出事。必须确保：
立即学习“PHP免费学习笔记（深入）”；
- PHP 连接时显式设置字符集：
mysqli_set_charset($conn, 'utf8mb4')（不是靠SET NAMES） - 数据库表和字段默认字符集为
utf8mb4_unicode_ci（建表语句带CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci） - PHP 文件保存为 UTF-8 无 BOM，HTML 页面声明
<meta charset="UTF-8"> - 禁用所有
mysql_*函数（已移除），避免残留的mysql_escape_string()调用
在 phpMyAdmin 环境下快速验证编码一致性
别只看界面设置。登录 phpMyAdmin 后，直接执行以下 SQL 查当前连接实际生效的编码：
SHOW VARIABLES LIKE 'character_set%';<br>SHOW VARIABLES LIKE 'collation%';
重点关注这三项是否都是 utf8mb4：
character_set_clientcharacter_set_connectioncharacter_set_database
如果不是，说明你的 PHP 连接没设对，或者 web 服务器（如 Apache）配置了全局 init_connect 强制改了连接编码。此时即使 phpMyAdmin 界面选了 UTF-8，也救不了业务代码。
唯一需要改 phpMyAdmin 自身配置的地方
如果你确实要用 phpMyAdmin 执行自定义 SQL（比如调试），且担心粘贴进来的 SQL 包含不可见的 BOM 或混合编码字符，可以强制它用 UTF-8 解析输入：
- 编辑
config.inc.php，添加：$cfg['DefaultCharset'] = 'utf8mb4'; - 确保
$cfg['ForceSSL'] = true;，防止中间人篡改 POST 数据编码 - 但注意：这仅影响 phpMyAdmin 表单提交内容的解析，不影响你 PHP 应用的任何行为
真正危险的永远是你 PHP 里那行 $sql = "SELECT * FROM user WHERE name = '" . $_GET['name'] . "'"; ——只要它还存在，改 phpMyAdmin 设置毫无意义。
