本文详解如何识别并修复PHP脚本中因双重URL编码导致的Cyrillic字符串（如“тест123”）被错误转义为%d1%82...的问题，确保UTF-8字符原样传入MySQL全文查询。
本文详解如何识别并修复php脚本中因双重url编码导致的cyrillic字符串（如“тест123”）被错误转义为`%d1%82...`的问题，确保utf-8字符原样传入mysql全文查询。
在PHP与MySQL协作处理国际化文本（尤其是俄文等Cyrillic字符）时，一个常见但隐蔽的陷阱是：本应直接用于SQL查询的原始字符串，意外变成了URL编码格式（如 %d1%82%d0%b5%d1%81%d1%82+123）。这并非MySQL连接编码（如 utf8mb4）配置错误所致——题中已正确调用 mysqli_set_charset($connect, 'utf8mb4')，说明数据库层完全支持Unicode。问题根源在于数据在进入PHP业务逻辑前已被URL编码，且未及时解码。
典型诱因包括：
- 表单提交使用了
GET方法，且未对$_GET参数做清洗； - 前端JavaScript调用了
encodeURIComponent()后，后端又误将结果再次编码； - 某些框架或中间件自动对输入进行URL编码（尤其在API网关或代理层）；
-
最常见情况：字符串被
urlencode()处理了两次，而仅用一次urldecode()无法完全还原。
✅ 正确做法是在构造SQL前，对可能被编码的变量显式执行 urldecode()：
// 假设 $searchTerm 来自 $_GET['q'] 或其他外部输入
$searchTerm = $_GET['q'] ?? '';
// 安全解码（支持多次编码场景，可嵌套调用）
$decoded = urldecode($searchTerm);
// 若怀疑双重编码，可安全重复解码（urldecode 是幂等的，对已解码字符串无副作用）
$decoded = urldecode($decoded);
// 验证是否恢复为原始Unicode
if (mb_detect_encoding($decoded, 'UTF-8', true) !== 'UTF-8') {
throw new InvalidArgumentException('解码后字符编码异常，请检查输入源');
}
// 构造安全SQL（推荐进一步使用预处理语句）
$query = "SELECT text, MATCH(text) AGAINST (? IN NATURAL LANGUAGE MODE) AS score FROM temp_text";
$stmt = $mysqli->prepare($query);
$stmt->bind_param('s', $decoded);
$stmt->execute();⚠️ 重要注意事项：
立即学习“PHP免费学习笔记（深入）”；
- 永远不要拼接未经校验的用户输入到SQL中 —— 即使已解码，也应优先采用预处理语句（如上例），避免SQL注入；
-
urldecode()不会改变合法UTF-8字节序列，但若输入本身不是有效URL编码（如含乱码），会返回原字符串，需配合mb_check_encoding()校验； - 确保PHP文件自身以UTF-8无BOM保存，且Web服务器（如Apache/Nginx）响应头声明
Content-Type: text/html; charset=utf-8； - MySQL表字段、连接、服务端均需统一设置为
utf8mb4（而非过时的utf8），例如建表语句应包含CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci。
总结：Cyrillic字符串在查询中显示为百分号编码，本质是HTTP传输层的编码残留，而非数据库或PHP内部编码问题。通过在数据消费端（即SQL构建前）主动、稳健地 urldecode()，并辅以预处理机制和编码验证，即可彻底解决该类问题，保障多语言全文检索的准确性和安全性。
