今天做点个小东西,生成一个随机字符串(ascii码的33-126的字符)。在通过url传递时,问题来了。
参数传递很自然的会urlencode。php接受到参数后,我做了一遍urldecode。虽然php会自动进行urldecode。不过我习惯性的做了一般。因为记得之前在哪里看过,urldecode多次执行不影响。这个可领教了,不能这么做。
原因:
浏览器和服务器对"空格"和"+"号的处理不一致。
浏览器端:浏览器对空格处理成%20,对+号不做处理。
服务器端:如果在web.xml配置了一个含有"+"号的路径,那么服务器端对提交的+号和%2B都能找到这个路径。
从浏览器的角度,按照URL编码规则,把空格编码成+号,把+号编码成%2B很容易,但从服务器来 看,就不太好处理,如果收到一个含有+号的URL,到底把这个URL看成编码前的还是编码后的呢? 个人感觉在这点上URL编码是有缺陷的,所以几款浏览器把URL中的空格编码成了%20,但是为什么不一鼓作气把+也编码成%2B? 这样服务器不就彻底解脱了。
所以如果多次做urldecode就会将+号变成空格。 当然了如果你的参数中没有+号,就无所谓了。
其实这个之前也知道,但是这次用了很多特殊字符,所以还是出问题了。
为了避免+的影响,我将随机字符改为(48-126),但是有出现了一个问题。
当字符串中有/字符时,php得到的参数中是//。
例如传递的参数为: WL?FQrC`wT/gE2Hz
服务端php得到的参数为: WL?FQrC`wT//gE2Hz
查了一下,原因是:
php默认是打开 magic_quotes_gpc 。其作用是:所有的 ' (单引号)," (双引号),/ (反斜线)和 NULL 字符都会被自动加上一个反斜线进行转义。这和 addslashes() 作用完全相同。
所以当参数传递到server端后,自动解码,然后在magic_quotes的作用下,反斜线,被转义了。就出现上面的情况,magic_quotes之前基本了解了,但是基本不会遇到大问题,这次算是搞明白了。
在传递参数时,要先弄清楚当前的配置情况。