mysql_real_escape_string一般而言，或mysql_扩展名的主要缺点是，与其他更现代的API（尤其是准备好的语句）相比，要正确地应用它比较困难。
mysql_real_escape_string应该仅在一种情况下使用：转义用作引号之间SQL语句中的值的文本内容。例如：
$value = mysql_real_escape_string($value, $link);$sql = "... `foo` = '$value' ..."; ^^^^^^
mysql_real_escape_string确保
$value上述上下文中的不会弄乱SQL语法。它不起作用，您可能会在这里想到：
$sql = "... `foo` = $value ...";
或在这里：
$sql = "... `$value` ...";
或在这里：
$sql = mysql_real_escape_string("... `foo` = '$value' ...");如果将其应用于在除SQL语句中带引号的字符串之外的任何上下文中使用的值，它将被错误地使用，并且可能会或可能不会干扰所得的语法和/或允许某些人提交可能启用SQL注入攻击的值。的用例
mysql_real_escape_string非常狭窄，但很少能正确理解。
使自己陷入困境的另一种方法
mysql_real_escape_string是使用错误的方法设置数据库连接编码。你应该做这个：
mysql_set_charset('utf8', $link);您 也 可以这样做：
mysql_query("SET NAMES 'utf8'", $link);问题是后者绕过了mysql_
API，后者仍然认为您正在使用
latin1（或其他方式）与数据库进行通信。
mysql_real_escape_string现在使用时，它将假定错误的字符编码和转义字符串与数据库稍后解释它们的方式不同。通过运行
SETNAMES查询，您在mysql_客户端API如何处理字符串与数据库如何解释这些字符串之间创建了一条裂痕。这可以用于某些多字节字符串情况下的注入攻击。
mysql_real_escape_string我知道， 如果正确应用 ， 则 没有基本的注入漏洞 。
同样，主要问题是，错误地应用它非常容易，这会带来漏洞。
