这是真的吗？如果是，如果您无法访问预处理语句，如何保护您的网站免受此影响？通过BIG5或GBK绕过mysql_real_escape_string()
"注入字符串"
に関する追加情報：上述字符为中文Big5编码
根据Stefan Esser的说法，当使用SET NAMES时，mysql_real_escape_string()是不安全的。
他在博客中解释道：
SET NAMES通常用于将编码从默认值切换到应用程序所需的编码。这是以一种mysql_real_escape_string不知道的方式完成的。这意味着，如果您切换到某些允许反斜杠作为第2、3、4...个字节的多字节编码，则会遇到问题，因为mysql_real_escape_string无法正确转义。UTF-8是安全的...更改编码的安全方法是使用
mysql_set_charset，但这仅适用于新的PHP版本。
他确实提到了UTF-8是安全的。
这是一个MySQL服务器的bug，据报告在2006年5月就已经修复。
请参阅：
该漏洞在MySQL 4.1.20、5.0.22和5.1.11中报告已修复。
如果您使用的是4.1.x、5.0.x或5.1.x，请确保您至少升级到小版本号。
作为解决方法，您还可以启用SQL模式NO_BACKSLASH_ESCAPES，该模式禁用反斜杠作为引号转义字符。
SELECT "O""Hare";。 - Bill KarwinNO_BACKSLASH_ESCAPES模式下，mysql_real_escape_string()仅会将'字符加倍，而不是"字符！ - eggyal' 作为字符串定界符。 - Bill KarwinANSI_QUOTES模式来强制执行这种行为。 - eggyal我相信只有在使用SQL更改字符编码时才会出现问题。
正如其他人所展示的那样，mysql_real_escape_string()在某些边缘情况下可能会被绕过。这是一个已知的绕过转义逻辑的策略，但可能还有其他未被发现的漏洞。
在PHP中预防SQL注入的简单而有效的方法是尽可能使用预处理语句，在不能使用时使用非常严格的白名单。
预处理语句，在实际使用并且不是PDO驱动程序模拟时，可以证明是安全的（至少在防止SQL注入方面），因为它们解决了应用程序安全的一个根本问题：将数据与操作数据的指令分离。它们被发送到单独的数据包中；参数化的值永远没有机会污染查询字符串。
现在已经是2015年了。不要再进行转义和连接。您仍然应根据应用程序（和业务）逻辑验证输入，但只需使用预处理语句即可。