PHP中URL中特殊字符引起的问题(+,,=)

前言，在做某个渠道的过程中，发现一个验签错误的问题。但是，当时验签在两个地方表现不一致，同一套处理方法，想到了这是因为两个地方请求方式是不同的一个get方法另外一个自然是post方法。当然，出问题肯定就是get。

GET和POST

GET请求方式，由于是将参数放在URL中，所以在进行传递的时候可能会受到浏览器端的一些策略问题，对参数进行urlencode处理。所以，当你在服务端拿到参数的时候可能并不是原始的数据。因此，在通过GET方式请求拿到数据，如果不做任何处理的话去验签可能会存在问题。这边的可能就是当base64处理之后不含+这个特殊的字符，+在GET方式之后不做任何处理拿到的就是一个空白字符串。

POST请求方式，是将参数放在request body中，在进行http传递的过程中不会存在由于浏览器的一些策略问题对参数进行任何的处理。因此，通过POST请求进行参数验签的时候不会存在问题，能够很顺利的进行验签。但是，我们没有办法去要求渠道商将get请求变成post请求，因此我们只能自己想办法。

urlencode和urldecode

urlencode:
(PHP 4, PHP 5, PHP 7)
urlencode — 编码 URL 字符串
string urlencode ( string $str )

此函数便于将字符串编码并将其用于 URL 的请求部分，同时它还便于将变量传递给下一页。

return

返回字符串，此字符串中除了 -_. 之外的所有非字母数字字符都将被替换成百分号（%）后跟两位十六进制数，空格则编码为加号（+）。此编码与 WWW 表单 POST 数据的编码方式是一样的，同时与 application/x-www-form-urlencoded 的媒体类型编码方式一样

urldecode:
(PHP 4, PHP 5, PHP 7)

urldecode — 解码已编码的 URL 字符串

string urldecode ( string $str )

解码给出的已编码字符串中的任何 %##。 加号（'+'）被解码成一个空格字符。

返回解码后的字符串。

好像我们看到了曙光，对+这个会变成空格的字符串的"完美处理方式"。那就是，对签名字符串进行urlencode进行加密处理。然后，兴高采烈的去验证，fxxk，false。还是不通过，然后甩自己一个耳光。base64加密之后会出现=这个补位字符串，很蛋疼。于是我就想了一个临时处理方式。

urlencode(substr($str,0,strlen($sign)-2)).substr($sign,strlen($sign)-2)

当时，考虑到base64最多出现两个==，所以在最后两个不进行urlencode处理。这个基本上能够处理，但是可能存在一个问题，那就是在最后两位出现+也是不行的，果然这个方案不能说服自己，推翻。并且在这个过程还发现一个问题就是，传过来的签名字符串还有可能会已经经过urlencode处理。这个还是一个小问题，先进行urldecode处理，因为decode不会引起误会。

当时，小伙伴提出一个解决办法，那就是直接替换+号不就可以了吗？的确，这是一个办法。但是我认为这个办法很挫，如果以后加密算法改变了或者增加了其他特殊字符呢,比如@#￥%……&**（ 等这些，我们不可能都去匹配替换什么的。所以，我同意临时方案处理，但是我继续想。

rawurlencode和rawurldecode

rawurlencode:
(PHP 4, PHP 5, PHP 7)

rawurlencode — 按照 RFC 3986 对 URL 进行编码

string rawurlencode ( string $str )

根据 » RFC 3986 编码指定的字符。

rawurldecode:
(PHP 4, PHP 5, PHP 7)

rawurldecode — 对已编码的 URL 字符串进行解码

string rawurldecode ( string $str )

返回字符串，此字符串中百分号（%）后跟两位十六进制数的序列都将被替换成原义字符。

新的曙光出现了，理解rawurldecode,替换成原义字符。所以，解决方案呼之欲出了。

rawurldecode(urlencode(urldecode($sign))));

初看上去觉得还臃肿或者为什么要这么绕来绕去处理呢？其实你还真得这么处理，至于为什么，请看上上面的吹牛逼。