mysql_real_escape_string（）是否完全防止SQL注入？
在http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-这个 ，有一个部分声称你可以绕过mysql_real_escape_string与某些亚洲字符编码
用BIG5或GBK绕过mysql_real_escape_string（）
“注射串”
に关する追加情报：上述字符是中国Big5
这是真的吗？ 如果是这样，如果你没有准备好的陈述，你将如何保护你的网站？
根据Stefan Esser的说法， “使用SET NAMES时 ， mysql_real_escape_string() [is]不安全。
他的博客解释：
SET NAMES通常用于将编码从默认值切换到应用程序所需的值。 这是以
mysql_real_escape_string不知道的方式完成的。 这意味着如果你切换到一些允许反斜杠作为2nd 3rd 4th …字节的多字节编码，你会遇到麻烦，因为mysql_real_escape_string不能正确地转义。 UTF-8是安全的…安全的方式来改变编码是
mysql_set_charset，但只有在新的PHP版本
但他提到UTF-8是安全的。
这是一个MySQL服务器漏洞，据报道在2006年5月被修复。
看到：
- MySQL错误＃8303 ：多字节字符包含\的string文字不正确
- MySQL错误＃8317 ：查询中的字符集introducer无法覆盖连接字符集
- MySQL错误＃8378 ：string错误地与客户端字符集'gbk'
- MySQL 5.1.11更新日志 。
这个bug在MySQL 4.1.20,5.0.22,5.11中被报告。
如果您使用4.1.x，5.0.x或5.1.x，请确保您已升级至less修订版本号。
作为一种解决方法，您还可以启用SQL模式NO_BACKSLASH_ESCAPES ，该模式禁用反斜杠作为引号转义字符。
我非常确定，如果你使用SQL来改变字符编码，这只会是行不通的。
正如其他人已经certificate， mysql_real_escape_string()可以绕过在不明确的边缘情况 。 这是绕过转义逻辑的一种已知策略，但可能还有其他尚未发现的未知漏洞。
在PHP中防止SQL注入的简单而有效的方法是在您可以使用准备好的语句以及不能使用的非常严格的白名单中使用。
当实际使用并且不被PDO驱动程序模拟时，准备好的语句可certificate是安全的（至less在SQL注入方面），因为它们解决了应用程序安全性的基本问题：它们将数据与操作数据的指令分开。 它们是分开发送的。 参数化的值从来没有机会污染查询string。
现在是2015年，不要再逃避和连结了。 您仍然应该根据应用程序（和业务）逻辑validation您的input，但只使用预准备语句。
