如果他们不完全一样，有什么区别？MySQL 查询中值的分隔符'不是吗？或者，"但是也可以通过添加斜杠进行转义。
在我理解的其他数据库引擎中（肯定是在像 PDO 这样的数据库包装器中），但为什么这么多人如此坚持使用 mysql(i)_escape_string 而不是添加斜杠？
问问题
10949 次
4 回答
18
First of all: do not use mysql_escape_string, it is deprecated (for a reason)!
If you have to support a legacy application that connects to the database through the mysql extension (which has been deprecated), use mysql_real_escape_string instead. Otherwise switch immediately to mysqli, where prepared statements and bound parameters provide a more robust mechanism for escaping user input.
That said, the answer can be found by reading the description of mysql_real_escape_string and addslashes:
Difference #1
addslashes does not know anything about MySql connection encodings. If you pass it a string containing bytes representing an encoding other than the encoding used by the MySql connection, it will happily escape all bytes having the values of the characters ', ", \ and \x00. This may not be the same as all the characters ', ", \ and \x00 if you are using an encoding other than 8-bit encodings and UTF-8. The result will be that the string received by MySql will be corrupted.
To trigger this bug, try using iconv to convert your variable to UTF-16 and then escape it with addslashes. See what your database receives.
This is one reason why addslashes should not be used for escaping.
Difference #2
In contrast to addslashes, mysql_real_escape_string also escapes the characters \r, \n, and \x1a. It appears that these characters have to be escaped as well when talking to MySql, otherwise a malformed query may be the result
This is the other reason why addslashes should not be used for escaping.
于 2010-12-20T00:51:33.067 回答
5
Chris Shiflettaddslashes()演示了一个使用转义 SQL失败的真实案例，mysql_real_escape_string()这是唯一可行的方法。
这有什么帮助？如果我想尝试对 MySQL 数据库进行 SQL 注入攻击，用反斜杠转义单引号是一件很糟糕的事情。但是，如果您使用的是addslashes()，那么我很幸运。我需要做的就是注入类似 0xbf27 的东西，然后 addlashes() 将其修改为 0xbf5c27，一个有效的多字节字符后跟一个单引号。换句话说，尽管您转义，我仍可以成功注入单引号。那是因为 0xbf5c 被解释为一个字符，而不是两个。糟糕，反斜杠出现了。
……
尽管使用了addslashes()，但我可以在不知道有效用户名或密码的情况下成功登录。我可以简单地利用 SQL 注入漏洞。
为避免此类漏洞，请使用 mysql_real_escape_string()、prepared statements 或任何主要的数据库抽象库。
现在这无疑是一个罕见的边缘案例，但它证明了为什么人们如此坚持使用数据库特定的转义函数。只有数据库库才能确定需要什么样的转义。不同的包装器、字符集和 SQL 风格（如 MS SQL 服务器）需要不同的转义。忽略这个事实就是漏洞是如何产生的。
于 2010-12-20T00:39:30.893 回答
1
它们的相同之处在于您不应该使用它们，因为您应该使用占位符而不是从不受信任的数据构建 SQL。
请参阅http://bobby-tables.com/php.html了解如何以正确的方式进行操作。
于 2010-12-20T01:01:24.833 回答
0
这首先是一个字符集问题。如果数据是纯粹的ASCIIaddslashes()，那么转义与 SQL 命令混合的数据就足够了。但除了 UTF-8 编码变化之外，MySQL 在某些配置中还允许边缘字符集，如 UCS2 (UTF-16) 或 GB/Big5 中文字符集。仅仅转义into的原始 ascii 代码是不够的。然后 MySQL 转义字符串的方式从一开始就不太符合 SQL 标准。它可能会在 MySQL 服务器的未来版本中被弃用。'\'
于 2010-12-20T00:57:44.293 回答