大家都知道，addslashes是过滤垃圾信息的函数，如果你的PHP环境打开了魔法函数，那么addslashes这个函数将自动运行对用户提交的信息进行过滤。但是addslashes函数在进行转义的时候，只对二进制字符串操作而不考虑字符集，结果产生BUG和漏洞。关于漏洞的产生，大家可以去百度搜索《PHP字符编码绕过漏洞总结》，注入 我不细说了，主要说说BUG。

首先要说明的是，此BUG只会在GBK字符集下会产生，GB2312无影响。我们来看GBK字符集的编码范围。

                 分区　　　　　　　　　　　　　高位　　　低位

●GBK/1:GB2312非汉字符号　: A1~A9 || A1~FE
●GBK/2:GB2312汉字　　　　   : B0~F7 || A1~FE
●GBK/3:扩充汉字　　　　　       : 81~A0 || 40~FE
●GBK/4:扩充汉字　　　　　       : AA~FE || 40~A0
●GBK/5:扩充非汉字　　　　      : A8~A9 || 40~A0

我们知道，addslashes函数一共要转义四个字符：'、"、/、NULL。NULL是字符串，不会产生问题，单引号 ' 和双引号 " 的ASCII码分别是27和22，不在GBK字符集的范围内，所以也不会产生问题。

而 / 的ASCII码是5C，在GBK扩充集的低位范围内，同时addslashes函数在运行是后不会考虑字符集，这样BUG就产生了。以5C结尾的繁体中文字，例如“躙”（0xDC5C）， 在运行addslashes函数过滤的时候，5C会被替换成5C5C，也就是说0xDC5C会被替换成0xDC5C5C，实际输出就是“躙/”。
同理，转义符剥离函数stripslashes也会出现BUG，造成乱码。
修正这个BUG的办法只有一个，就是自己写一个带有字符集效验的addslashes函数。

// 特殊字符转义函数 function gbk_addslashes($text) { for ( ; ; ) { $i = mb_strpos($text, chr(92), 0, "GBK"); if ($i === false) break; $T = mb_substr($text, 0, $i, "GBK") . chr(92) . chr(92); $text = substr($text, strlen($T) - 1); $OK .= $T; } $text = $OK . $text; $text = str_replace(chr(39), chr(92) . chr(39), $text); $text = str_replace(chr(34), chr(92) . chr(34), $text); return $text; } // 转义符剥离函数 function gbk_stripslashes($text) { $text = str_replace(chr(92) . chr(34), chr(34), $text); $text = str_replace(chr(92) . chr(39), chr(39), $text); for ( ; ; ) { $i = mb_strpos($text, chr(92) . chr(92), 0, "GBK"); if ($i === false) break; $T = mb_substr($text, 0, $i, "GBK") . chr(92); $text = substr($text, strlen($T) + 1); $OK .= $T; } $text = $OK . $text; return $text; }

在实际使用中，如果系统开启了魔法函数，那么先要用stripslashes对变量进行转义符剥离，然后在使用我们自己的gbk_addslashes进行转义。
经过测试，这种方法不但可以避免BUG产生，还可以避免注入漏洞的产生，因为此函数不会对不属于GBK的字符进行转移，因此0xbf27不会被转义为0xbf5c27。

显然，这种办法应用麻烦，而且相对系统addslashes函数来说，效率会降低。但是这是我唯一想到的GBK字符集BUG的解决办法。其实我还是建议大家应该放弃传统编程习惯，开始适应UTF-8编程。毕竟UTF-8是通用字符集，很多GBK下的BUG不会在UTF-8上产生。

另附一篇日文参考文章：http://www.shtml.jp/mojibake/sjis_cgi.html