小编给大家分享一下PHP URL中特殊字符引起的问题分析,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获、下面让我们一起去了解一下吧!
<强> PHP中URL中特殊字符引起的问题(+、=)
前言,在做某个渠道的过程中,发现一个验签错误的问题。但是,当时验签在两个地方表现不一致,同一套处理方法,想到了这是因为两个地方请求方式是不同的一个得到方法另外一个自然是发布方法。当然,出问题肯定就是。
<强> get和post
得到请求方式,由于是将参数放在URL中,所以在进行传递的时候可能会受到浏览器端的一些策略问题,对参数进行urlencode处理,所以,当你在服务端拿到参数的时候可能并不是原始的数据,因此,在通过得到方式请求拿到数据,如果不做任何处理的话去验签可能会存在问题。这边的可能就是当base64处理之后不含+这个特殊的字符,+在得到方式之后不做任何处理拿到的就是一个空白字符串。
文章请求方式,是将参数放在请求体中,在进行http传递的过程中不会存在由于浏览器的一些策略问题对参数进行任何的处理,因此,通过帖子请求进行参数验签的时候不会存在问题,能够很顺利的进行验签。但是,我们没有办法去要求渠道商将会请求变成帖子请求,因此我们只能自己想办法。
<强> urlencode和urldecode
此函数便于将字符串编码并将其用于URL的请求部分,同时它还便于将变量传递给下一页。
返返回回字符串,此字符串中除了_。之外的所有非字母数字字符都将被替换成百分号(%)后跟两位十六进制数,空格则编码为加号(+)。此编码与WWW表单的帖子数据的编码方式是一样的,同时与应用程序/x-www-form-urlencoded的媒体类型编码方式一样
urldecode -解码已编码的URL字符串
解码给出的已编码字符串中的任何% # #。加号(& # 39;+ & # 39;)被解码成一个空格字符。
返回解码后的字符串。
好像我们看到了曙光,对+这个会变成空格的字符串的“完美处理方式“。那就是,对签名字符串进行urlencode进行加密处理,然后,兴高采烈的去验证,混混回,假。还是不通过,然后甩自己一个耳光.base64加密之后会出现=这个补位字符串,很蛋疼。于是我就想了一个临时处理方式。
当时,考虑到base64最多出现两个==,所以在最后两个不进行urlencode处理。这个基本上能够处理,但是可能存在一个问题,那就是在最后两位出现+也是不行的,果然这个方案不能说服自己,推翻。并且在这个过程还发现一个问题就是,传过来的签名字符串还有可能会已经经过urlencode处理。这个还是一个小问题,先进行urldecode处理,因为解码不会引起误会。
当时,小伙伴提出一个解决办法,那就是直接替换+号不就可以了吗?的确,这是一个办法。但是我认为这个办法很挫,如果以后加密算法改变了或者增加了其他特殊字符呢,比如@ #￥%……,* *(等这些,我们不可能都去匹配替换什么的,所以,我同意临时方案处理,但是我继续想。
<强> rawurlencode和rawurldecode
rawurlencode -按照RFC 3986对URL进行编码
根据吗?RFC 3986编码指定的字符。
rawurldecode -对已编码的URL字符串进行解码
返回字符串,此字符串中百分号(%)后跟两位十六进制数的序列都将被替换成原义字符。
新的曙光出现了,理解rawurldecode,替换成原义字符。所以,解决方案呼之欲出了。
初看上去觉得还臃肿或者为什么要这么绕来绕去处理呢?其实你还真得这么处理,至于为什么,请看上上面的吹牛逼。
以上是PHP URL中特殊字符引起的问题分析的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注行业资讯频道!
