今天采集的时候发生了一个mysql INSERT INTO 语句错误,我代码写的是采回来后加addslashes然后入库,按理说不会有问题的,而且采回来的这行字也没有英文和符号,用strlen检查长度也是正常,然后我再加上addslashes输出一看就发现问题了,后面竟然无端端的多了个 \ ,难怪mysql报错了,从网上搜了一下原来addslashes真的存在这样的问题,原因是这样的,addslashes函数在进行转义的时候,只对二进制字符串操作而不考虑字符集,当你的网页是gbk时, ' " NULL 这三个字符都不会有问题,因为他们的ascii码不在gbk的范围内,但是 \ 的ascii码 5c 却包含在gbk内,所以当以 5C 结尾的繁体中文字,例如“躙”(0xDC5C),在运行addslashes函数过滤的时候,5C会被替换成5C5C,也就是说0xDC5C会被替换成0xDC5C5C,实际输出就是“躙\”。刚好我的那行文字就是繁体,以“好運”结尾的,而“運”字就是以 5c 结尾的,所以就被转义了。要测试很简单,新建一个gbk的网页,直接运行
echo addslashes("運好");
输出的结果却是 運\好 ,在utf-8下面是没问题的,我的php是5.4.4版本。

解决方案 »

  1.   

    确实有这样的问题哦。
    暂无好的对策。建议mysql_real_escape_string等函数处理。
      

  2.   

    不是BUG,addslashes 只用于单字节字符。况且他并没有说是二进制可靠的
    你可以用 mysql_real_escape_string
    也可以 str_replace("'", "\\'", ...其实这一点在 php.ini 的注释中已经输的很清楚了
      

  3.   

    str_replace试过还是不行,一样被检测到有一个反斜杠存在。
      

  4.   

    那才是奇了怪了!
    $s =<<< TXT
    '躙
    TXT;
    echo $s, PHP_EOL;
    $s = str_replace("'", "\\'", $s);
    echo $s, PHP_EOL;
    print_r(unpack('H*', $s));
    '躙
    \'躙
    Array
    (
        [1] => 5c27dc5c
    )
      

  5.   

    所以有时候UTF-8能省去很多麻烦...