同样的数据ie发送后服务器返回的情况不一样

Question

echo $par['foldername'];
看看是什么

Answer 1

在ie下打印下unescape前后的 $par['foldername'];看下结果

Answer 2

代码中的$res.sql就是送给前台alert用的（不要在意sql这个名字了）
在后台没有使用unescape的时候，是%xxxx，在后台使用uneacape的时候，是“已删除”
（所以我要疯了……）
使用ff看的话，没有在前台强制使用escape的时候是“已删除”，送回的数据一样，而且也能进入if true

Answer 3

$res['sql'].=' AA'.$par['foldername'];  //debug2这样的写法很怪

Answer 4

这里的$res['sql']只是为了测试在前台alert临时使用的，所以就随手写了

Answer 5

重新调试发现一个原因：
但是仍然百思不得其解
前台ie用escape传递过来的是%u5DF2%u5220%u9664%20，用encodeURI传递过来的是%E5%B7%B2%E5%88%A0%E9%99%A4%20，这两者貌似后面都多了一个空格
这是第一个没搞明白的地方，为什么会多一个空格出来？
第二个是在php中用unescape解码后出来的是“已删除 这一点通过
$par['foldername']=unescape($par['foldername']);
$res['sql']=$par['foldername'].$par['foldername'];
可以看出，返回的是“已删除 已删除”（后面有没有空格，在ie的alert下看不出来，但是中间有一个空格是非常明显的），也就是说经过解码后我的$par['foldername']就是“已删除 ”后台有一个语句是
$sql='select * from `mail_folder` where `owner` = '.$par['uid'].' and `name` = "'.$par['foldername'].'" limit 1';
打印出来就是
select * from `mail_folder` where `owner` = 142 and `name` = "已删除 " limit 1
而在mysql库中name就是“已删除”，没有空格，这条语句却能返回结果

Answer 6

$par['foldername'] = trim($par['foldername']);至于是如何多出的，需要看到你的页面代码

Answer 7

sql1=select * from `mail_folder` where `owner` = 142 and `name` = "已删除 " limit 1
这里的name是“已删除 ”（后面有一个空格），但是实际上库里面并没有空格，可是它却能查询出期望的结果出来
而使用
sql2=select * from `mail_folder` where `owner` = 142 and `name` like "已删除 " limit 1
则无法查询出来，求解mysql中=和like的区别，按道理说=是精确匹配，sql1不应该能查到结果才对啊

Answer 8

如果字段是char或varchar类型，那么在字符串比较的时候MySQL使用PADSPACE校对规则，会忽略字段末尾的空格字符，若想做到精确匹配可以使用下面几种方法：
方法1：使用like语句；
方法2：使用binary类型，例如，select binary 'a' = 'a   '
方法3：再添加一个length()条件，例如，select col from table where col = 'a   ' and LENGTH(col) = LENGTH('a   ')官方手册说明（5.0版本）：
http://dev.mysql.com/doc/refman/5.0/en/char.html
11.1.6.1. The CHAR and VARCHAR Types
 All MySQL collations are of type PADSPACE. This means that all CHAR, VARCHAR, and TEXT values in MySQL are compared without regard to any trailing spaces. “Comparison” in this context does not include the LIKE pattern-matching operator, for which trailing spaces are significant. 

Answer 9

哦，谢谢，的确是用的varchar