关键要点：宽字节SQL注入的根本原因并非PHP层过滤不足，而是字符集设置与转义机制之间出现了脱节。许多开发者在维护GBK编码的老旧系统时，习惯直接使用SET NAMES 'gbk'，认为这样就能解决问题，但实际上却放大了安全漏洞。
为什么 set names gbk 会触发宽字节注入
问题在于，SET NAMES 'gbk'仅修改了客户端、结果集和连接的字符集变量，但并未告知MySQL连接层应使用何种编码解析输入内容。因此，PHP端的addslashes()仍然按照单字节规则处理——将'（%27）转义为\'（%5c%27）。当MySQL接收到%df%5c字节序列时，由于检测到GBK编码，会将两个字节合并为一个宽字符（例如“運”），导致反斜杠被“消耗”掉，后续的%27失去转义保护，从而成功注入。
简而言之，SET NAMES仅调整了若干会话变量，并未同步连接层面的字符编码上下文。转义函数与数据库解析机制各自独立运行，漏洞恰恰源于这一脱节。
mysql_set_charset() 和 mysqli_set_charset() 是必须替换的点
这两个函数不仅执行SET NAMES操作，还能同步配置连接层的字符集上下文，确保MySQL在接收数据时严格按照指定编码进行解析。这样一来，宽字节的“吞字”现象便得以消除。如果仅修改SET NAMES而未使用这两个函数，修复并不完整。
mysql_set_charset("gbk", $conn)（该函数已废弃，仅在旧版代码中仍需使用）mysqli_set_charset($conn, "gbk")（推荐使用，需在mysqli_real_escape_string()前调用）- 若采用PDO，必须显式设置
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"，且不能仅依赖DSN中的charset=gbk——后者仅影响客户端显示，不作用于连接层。
mysql_real_escape_string() 不能替代预编译，但它是宽字节场景下的兜底手段
该函数与addslashes()的关键区别在于：它内部会读取当前连接的实际字符集（即由mysqli_set_charset()设定的编码），然后依据该编码规则进行转义。例如，对于GBK编码，它能识别%df%5c为合法的双字节字符，不会错误地插入反斜杠。而addslashes()完全不考虑编码，仅按字节流操作，因此漏洞频发。
- 务必确保在调用
mysqli_real_escape_string()之前，连接已经通过mysqli_set_charset()正确设置了字符集。 - 若传入空连接或未初始化连接，函数会返回
false，容易因忽略而绕过——这一陷阱需特别注意。 - 它仅能防御字符串型注入，对于数字型参数仍需使用
intval()或参数化查询。
character_set_client=binary 是最硬核的防御方式
在执行查询前，通过mysqli_query($conn, "SET character_set_client = binary")将MySQL设置为将客户端输入视为原始字节流，而不是尝试按GBK解码。此时，%df%5c%27不会被解析为“運'”，而是三个独立的字节。MySQL可能会报错或截断数据，无法形成有效的SQL语法。
- 该设置仅影响当前查询，每次查询前都需要重新设置（或封装进统一的查询函数中）。
- 它无法解决乱码问题，但能彻底阻断宽字节注入的链路——堪称一招绝杀。
- 注意：不能与
SET NAMES混用，否则后者会覆盖前者，导致设置失效。
总而言之，修复宽字节注入的核心思路并非简单替换过滤函数，而是使连接层的编码上下文与转义逻辑保持一致。任何仅修改SQL拼接方式或更换过滤函数的方案，只要底层仍然是SET NAMES gbk配合addslashes()，漏洞实质上并未修复。
