防止SQL注入的输入转义函数选择

选输入转义函数，本质不是在挑“哪个函数最安全”，而是在挑“哪个函数与当前上下文最匹配”。脱离上下文谈安全，是SQL注入防护中最常见的错误。很多人以为只要用了mysql_real_escape_string或者addslashes就万事大吉，实际上转义逻辑一旦与数据库编码、SQL模式或参数边界发生错位，攻击者依然能绕过。

SQL注入发生的根本原因，是用户输入的数据被解析器当成了代码执行。转义函数要做的就是给特殊字符加上反斜杠或进行编码转换，让数据库引擎在词法分析阶段把这些字符识别为普通数据的一部分，而不是SQL语法元素。以最经典的单引号为例，输入' OR '1'='1，转义后变成\' OR \'1\'=\'1，闭合引号的意图就被破坏了。

但这个逻辑成立的前提是：转义函数和数据库解析器对“特殊字符”的定义完全一致。一旦出现认知差异，保护就会失效。比如GBK编码下的宽字节注入，就是因为MySQL在启用GBK编码时，某些字节组合会被当作一个双字节字符处理，反斜杠的十六进制值0x5c恰好可以被“吃掉”，导致转义失效。这不是转义函数本身有bug，而是字符集驱动的解析逻辑与转义逻辑产生了冲突。

在PHP的MySQL扩展时代，mysql_real_escape_string被奉为标准答案。它比addslashes高明的地方在于，它会参考当前数据库连接的字符集设置，根据字符集特性决定哪些字符需要转义。它转义的对象包括：反斜杠、单引号、双引号、NULL字节、回车、换行等。在正确设置连接字符集的前提下，它能有效防御绝大多数转义型注入。

但问题恰恰出在“正确设置连接字符集”这个前提上。很多老代码的习惯是先连接数据库，再执行SET NAMES来设置字符集。mysql_real_escape_string在调用时并不知道后续SET NAMES会改变字符集，它只能根据当前连接状态来判断。如果调用转义函数时连接刚建立、字符集还是默认的latin1，而后续SQL执行时字符集变成了GBK，宽字节注入的窗口就打开了。正确的做法是在建立连接后立即用mysql_set_charset设置字符集，这个函数会同时更新客户端和连接层的字符集信息，让mysql_real_escape_string能感知到正确的编码环境。

addslashes是PHP原生函数，设计初衷根本不是为SQL安全服务的，而是为了给字符串转义以便在PHP字符串字面量中使用。它只转义单引号、双引号、反斜杠和NULL字节，完全不关心数据库字符集。在UTF-8环境下，addslashes对付普通的引号闭合注入是够用的，因为UTF-8编码不会产生宽字节问题。但一旦数据库使用GBK、Big5等多字节编码，addslashes就形同虚设。

更致命的是，addslashes对数字型注入完全无效。如果SQL语句是SELECT * FROM users WHERE id=$id，而$id直接来自用户输入且未加引号包裹，那么即使用addslashes处理了$id，攻击者直接输入1 UNION SELECT...就能完成注入，因为数字上下文根本不需要闭合引号。转义函数只保护字符串上下文，这是很多人忽略的边界。

PDO::quote的行为类似mysql_real_escape_string，它会根据当前驱动和连接字符集进行转义，并在字符串两端自动加上引号。很多开发者把它当作“手动转义+手动拼接SQL”的安全方案。但PHP官方文档明确警告：如果驱动支持原生预处理语句，应该优先使用prepare和execute，而不是quote拼接。

quote的问题在于，它把转义和引号包裹耦合在一起，对于需要部分拼接的复杂SQL场景（比如动态表名、列名、LIMIT子句）反而会造成困扰。而且不同数据库驱动的quote实现细节有差异，某些驱动对特定字符的处理可能不完全一致。把安全寄托在quote上，等于把防护逻辑分散到了每次手动拼接中，只要有一次忘记调用quote，整个应用就暴露在风险之下。

预处理语句（Prepared Statement）是当前公认最有效的SQL注入防护手段。它的工作原理不是转义，而是将SQL结构和数据彻底分离：先把SQL模板发送给数据库解析、编译、优化，然后把数据作为参数单独传递。数据库在收到参数时，已经完成了SQL语句的语法分析，参数值无论如何都不会被当作SQL代码执行。

这种机制从根本上消除了转义不完整、字符集不一致、上下文误判等问题。无论数据中包含什么特殊字符，都不会影响SQL语句的结构。以PDO为例：

$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username');
$stmt->execute(['username' => $userInput]);

$userInput中的任何字符都只是username字段的值，不会被解析器当作SQL语法元素。这种安全性不依赖于开发者是否记得调用转义函数，也不依赖于字符集配置是否正确，它是架构层面的安全。

但预处理语句也有边界。大多数数据库驱动只允许绑定数据值，不允许绑定表名、列名、LIMIT参数、ORDER BY方向等SQL结构元素。这些场景下，开发者被迫回到字符串拼接的老路上。此时必须使用白名单校验，而不是依赖转义函数。比如对于ORDER BY的排序方向，只允许ASC和DESC两个值，任何其他输入都直接拒绝。

不同数据库的转义规则并不完全相同。PostgreSQL使用反斜杠转义，但它的标准转义字符串语法是E'...'，且可以通过standard_conforming_strings参数控制反斜杠是否被当作转义字符。PostgreSQL提供的PQescapeLiteral、PQescapeIdentifier等函数能正确处理这些细节。在PostgreSQL环境下，直接用PHP的addslashes或通用的MySQL转义逻辑是危险的，因为转义语义可能不匹配。

SQLite的情况更特殊。SQLite的转义规则相对简单，主要是对单引号进行双写处理（''代表一个单引号）。但SQLite允许通过PRAGMA配置改变引号转义行为，不同版本的SQLite在转义细节上也有差异。使用SQLite时，最稳妥的方案仍然是预处理语句，其次是用SQLite原生的sqlite_escape_string函数，而不是跨数据库套用MySQL的转义经验。

很多人认为只要统一使用UTF-8编码，宽字节注入就不存在了。UTF-8确实没有GBK那种反斜杠被“吃掉”的问题，但UTF-8本身也有潜在风险。MySQL的utf8字符集最多只支持3字节的UTF-8字符，对于4字节的emoji表情等字符会截断或报错。如果应用层使用了utf8mb4而数据库连接设置了utf8，字符截断可能导致转义反斜杠丢失。这不是传统意义上的宽字节注入，但原理类似——编码不一致导致转义逻辑被绕过。

更隐蔽的是，某些数据库在遇到无效的UTF-8字节序列时，会进入一种容错模式，尝试按其他编码解释数据。这种边界情况极其罕见，但在高安全场景下值得关注。确保整个链路（应用层、连接层、数据库存储层）使用完全一致的编码，并且使用utf8mb4而不是utf8，是消除这类风险的根本方法。

对于新项目，答案非常明确：优先使用预处理语句，配合参数绑定。这是安全性和可维护性最优的方案。ORM框架如Doctrine、Eloquent等底层都基于预处理语句，开发者基本不需要手动处理转义。

对于需要动态拼接SQL结构元素的场景，建立严格的白名单机制。表名、列名从预定义的合法集合中选取，绝不直接拼接用户输入。对于LIMIT和OFFSET等数值型参数，先强制转换为整数再拼接。对于必须拼接字符串型结构元素的极端情况，使用数据库官方提供的标识符转义函数（如PDO::quote对标识符的处理因驱动而异，需查阅具体驱动的文档）。

对于维护遗留系统、无法大规模重构的情况，如果必须使用转义函数，按以下优先级选择：数据库扩展原生提供的转义函数（如mysqli_real_escape_string）> PDO::quote > addslashes。同时必须确保连接字符集在转义前就已正确设置，且与数据库实际字符集一致。对于使用GBK等宽字节编码的系统，要么迁移到UTF-8，要么在转义后对反斜杠进行额外的安全检查。

对于多数据库兼容的场景，不要假设所有数据库的转义规则相同。使用数据库抽象层提供的统一接口，让底层驱动处理差异。如果自行封装，必须为每种数据库编写对应的转义逻辑。

无论选择了哪种方案，都需要用实际的攻击向量进行验证。构造包含单引号、反斜杠、NULL字节、Unicode特殊字符的测试用例，在非生产环境中实际执行，观察SQL语句的最终形态和数据库的解析结果。很多看起来正确的转义逻辑，在实际测试中会暴露出字符集、驱动版本、数据库配置带来的微妙差异。安全不能靠假设，只能靠验证。