防止SQL注入中不同数据库的字符串转义函数差异

防止SQL注入攻击时，不同数据库使用的字符串转义函数完全不同，这是开发者最容易踩的坑。MySQL用的是mysql_real_escape_string()或mysqli_real_escape_string()，PostgreSQL用的是pg_escape_string()或pg_escape_literal()，SQL Server用的是没有内置的转义函数而是通过参数化查询来规避，Oracle则依赖dbms_assert.enquote_name()和dbms_assert.enquote_literal()。搞混了这些函数，轻则报错，重则直接被注入攻破。下面我把主流数据库的转义方案逐一拆开讲清楚，包括函数用法、注意事项和替代方案。

很多开发者习惯在一个项目里只写一套转义逻辑，然后迁移到不同数据库时直接复用，这是非常危险的。每个数据库的SQL语法、字符集、转义规则都不一样。MySQL默认用反斜杠\作为转义符，PostgreSQL用单引号 doubling（两个单引号表示一个），SQL Server用方括号和参数化机制，Oracle有自己的一套断言包。用错了函数，不仅转义失效，还可能引入新的漏洞。所以，针对不同数据库必须使用对应的转义函数，或者更好的做法是统一使用参数化查询（Prepared Statement），从根本上绕开转义这个问题。

MySQL是使用最广泛的开源数据库之一，它提供了两个主要的转义函数。第一个是mysql_real_escape_string()，这是旧版MySQL扩展（已废弃）中的函数；第二个是mysqli_real_escape_string()，这是MySQLi扩展中的函数，也是目前推荐使用的。两者的核心逻辑一样：对特殊字符如单引号、双引号、反斜杠、NULL字符等进行转义处理。

// MySQLi 方式使用转义函数
$conn = new mysqli("localhost", "user", "password", "database");
$user_input = $conn->real_escape_string($_POST['username']);
$sql = "SELECT * FROM users WHERE username = '{$user_input}'";
$result = $conn->query($sql);

需要特别注意的是，mysql_real_escape_string()必须在建立数据库连接之后才能使用，因为它依赖连接的字符集信息来判断如何转义。如果连接字符集是GBK，而你用了UTF-8的方式处理输入，就可能出现宽字节注入漏洞。这是历史上最经典的MySQL注入案例之一。另外，从PHP 5.5开始，mysql扩展已经被移除，必须使用MySQLi或PDO。

PDO方式下，MySQL的转义可以通过quote()方法实现，但更推荐直接用预处理语句：

// PDO 预处理方式（推荐）
$pdo = new PDO("mysql:host=localhost;dbname=test;charset=utf8mb4", "user", "pass");
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute([':username' => $_POST['username']]);

PostgreSQL的转义机制和MySQL完全不同。它没有类似mysql_real_escape_string()这样的函数，而是提供了pg_escape_string()和pg_escape_literal()两个函数。pg_escape_string()转义的是普通字符串，pg_escape_literal()转义的是可以直接嵌入SQL语句的字面量（会自动加上单引号）。

// PostgreSQL 转义示例
$conn = pg_connect("host=localhost dbname=test user=postgres password=pass");
$user_input = pg_escape_string($conn, $_POST['username']);
$sql = "SELECT * FROM users WHERE username = '{$user_input}'";
$result = pg_query($conn, $sql);

// 或者使用 pg_escape_literal（自动加引号）
$literal = pg_escape_literal($conn, $_POST['username']);
$sql = "SELECT * FROM users WHERE username = {$literal}";

PostgreSQL还有一个容易被忽略的点：它支持标准SQL的E''语法和美元符号引用（$$...$$），在处理包含大量特殊字符的字符串时，使用dollar quoting可以避免层层转义的麻烦。但在实际防注入场景中，依然强烈建议使用pg_prepare()和pg_execute()进行参数化查询。

// PostgreSQL 参数化查询（推荐）
$stmt = pg_prepare($conn, "user_query", "SELECT * FROM users WHERE username = $1");
$result = pg_execute($conn, "user_query", [$_POST['username']]);

SQL Server（MSSQL）比较特殊，它没有一个像MySQL那样的内置字符串转义函数。微软官方的态度很明确：不要自己做转义，直接用参数化查询。在PHP中，可以使用sqlsrv_prepare()和sqlsrv_execute()，或者在.NET中使用SqlCommand的Parameters集合。

// PHP sqlsrv 参数化查询
$conn = sqlsrv_connect("server=localhost;Database=test", ["uid" => "sa", "pwd" => "pass"]);
$sql = "SELECT * FROM users WHERE username = ?";
$params = [$_POST['username']];
$stmt = sqlsrv_prepare($conn, $sql, $params);
sqlsrv_execute($stmt);

如果你非要在SQL Server里做转义，只能手动把单引号替换为两个单引号，但这种做法极其不推荐，因为容易遗漏其他危险字符，而且维护成本高。SQL Server还有一个特殊风险：它支持堆叠查询（多条语句用分号隔开），所以即使你转义了字符串，如果拼接方式不对，攻击者仍然可以注入额外的语句。参数化查询是唯一可靠的方案。

Oracle数据库没有直接的"转义字符串"函数，但提供了dbms_assert包，里面有enquote_literal()和enquote_name()两个函数。enquote_literal()用于转义字符串字面量，enquote_name()用于转义数据库对象名（如表名、列名）。

-- Oracle PL/SQL 中使用 dbms_assert
DECLARE
    v_input VARCHAR2(100) := :user_input;
    v_safe VARCHAR2(200);
BEGIN
    v_safe := dbms_assert.enquote_literal(v_input);
    EXECUTE IMMEDIATE 'SELECT * FROM users WHERE username = ' || v_safe;
END;

在PHP的OCI8扩展中，Oracle推荐使用oci_bind_by_name()进行绑定变量：

// PHP OCI8 参数化查询
$conn = oci_connect("user", "pass", "localhost/XE");
$sql = "SELECT * FROM users WHERE username = :username";
$stmt = oci_parse($conn, $sql);
oci_bind_by_name($stmt, ":username", $_POST['username']);
oci_execute($stmt);

Oracle的dbms_assert包是从10g版本开始引入的，低版本Oracle没有这个包，那时候只能靠手动替换或者使用DBMS_SQL包来处理，非常麻烦。所以如果你维护的是老系统，升级数据库版本或者迁移到参数化查询是当务之急。

SQLite虽然轻量，但也有自己的转义方式。在PHP的PDO SQLite驱动中，可以使用quote()方法：

// SQLite PDO 转义
$pdo = new PDO("sqlite:test.db");
$safe = $pdo->quote($_POST['username']);
$sql = "SELECT * FROM users WHERE username = {$safe}";

但同样，SQLite官方推荐使用预处理语句。SQLite的prepare()和execute()机制和其他数据库类似，绑定参数后完全不需要手动转义。

必须强调一个核心观点：字符串转义函数只是防SQL注入的最后一道防线，不是首选方案。转义函数的局限性包括：第一，它依赖正确的字符集设置，字符集配置错误会导致转义失效；第二，它只能处理字符串类型的参数，对于数字型、日期型参数如果也用字符串转义来处理，会增加出错概率；第三，不同数据库的转义规则不同，跨数据库项目维护成本极高。

最佳实践的优先级排序如下：第一，使用参数化查询（Prepared Statement / Parameterized Query），这是最安全、最通用的方案，所有主流数据库都支持；第二，如果必须拼接SQL，使用对应数据库的转义函数，并且确保字符集正确；第三，使用ORM框架（如Hibernate、Eloquent、Django ORM），它们内部已经处理了转义问题；第四，做输入验证和白名单过滤，在数据进入业务逻辑之前就拦截非法输入。

如果你的项目需要同时支持MySQL、PostgreSQL、SQL Server等多种数据库，千万不要为每种数据库写一套转义逻辑。正确的做法是使用数据库抽象层（DBAL）或者ORM，让框架来处理底层差异。例如PHP的Doctrine DBAL、Python的SQLAlchemy、Java的MyBatis，它们都会根据当前连接的数据库类型自动选择正确的参数绑定方式。

// 使用 Doctrine DBAL 统一处理（PHP示例）
use Doctrine\DBAL\DriverManager;

$conn = DriverManager::getConnection([
    'driver' => 'pdo_mysql',
    'host' => 'localhost',
    'dbname' => 'test',
    'user' => 'root',
    'password' => 'pass',
]);

// 不管底层是什么数据库，都用参数化
$stmt = $conn->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute(['username' => $_POST['username']]);

这样做的好处是：代码只写一次，底层自动适配，既安全又可维护。如果未来要从MySQL迁移到PostgreSQL，只需要改配置文件中的driver参数，业务代码完全不用动。

防止SQL注入中不同数据库的字符串转义函数差异，本质上是一个数据库兼容性和安全意识的问题。MySQL用mysqli_real_escape_string()，PostgreSQL用pg_escape_string()，SQL Server没有内置转义函数靠参数化，Oracle用dbms_assert包。但无论哪种数据库，参数化查询都是最优解。开发者应该把精力放在架构层面的统一防护上，而不是纠结于某个数据库的转义细节。记住一句话：能用参数化就别用转义，能用框架就别自己拼SQL。