PHP中URL中的特殊字符引起的问题(+,,=)前言，在做某频道的过程中，发现了一个签名验证错误问题。但是当时两地的验签性能不一致，而且是同一套处理方式，我以为这是因为两地的请求方式不一样，一个是get方式，一个是get方式另一个自然是post方法。当然，问题一定是搞定了。GET和POSTGET请求方式，因为参数放在url中，传递时可能会受到浏览器端的一些policy问题，对参数进行urlencoded处理。所以，当你在服务器端拿到参数的时候，不一定是原来的数据。因此，如果不做任何处理，通过GET方式请求数据，签名验证可能会出现问题。这里的可能是当base64处理后不包含特殊字符+时，+在GET方法后不做任何处理得到一个空字符串。POST请求方式是将参数放在请求体中，在http传输过程中不会因为浏览器的一些策略问题而没有对参数进行处理。所以通过POST请求进行参数验签不会有问题，可以顺利进行验签。但是我们没有办法要求渠道商把get请求变成post请求，只能自己想办法了。urlencode和urldecodeurlencode：（PHP4、PHP5、PHP7）urlencode—对URL字符串进行编码传递到下一页。return返回一个字符串，其中除-_外的所有非字母数字字符。将替换为百分号(%)后跟两位十六进制数，空格编码为加号(+)。这个编码和WWW表单POST数据编码一样，还有application/x-www-form-urlencoded媒体类型编码urldecode:(PHP4,PHP5,PHP7)$str)解码给定编码字符串中的任何%##。加号('+')被解码为空格字符。返回解码后的字符串。似乎我们已经看到了曙光，一种处理+字符串变成空格的“完美方式”。即使用urlencode对签名串进行加密。然后，愉快的去验证，fxxk，false。还是失败了，然后给自己打耳光。base64加密后会有=这个补串，很蛋疼。于是想到了一个临时的解决办法。urlencode(substr($str,0,strlen($sign)-2)).substr($sign,strlen($sign)-2)当时考虑到base64最多有两个==，所以最后两个不进行urlencode处理。这样基本就可以处理了，但是可能会有一个问题，就是最后两位出现+是不能接受的。果然，这个计划说服不了自己，推翻了。并且在这个过程中，我还发现了一个问题，就是传递的签名串可能经过了urlencode的处理。这还是个小问题，先urldecode处理，因为decode不会造成误会。当时朋友提出了一个解决方案，就是直接把+号换掉不行吗？确实，这是一种方式。但我认为这种方法非常令人沮丧。如果以后加密算法变了或者加入了其他特殊字符怎么办，比如@#￥%...&**(等，我们不能全部匹配替换。所以，我同意临时解决方法，但是我keepthinking.rawurlencodeandrawurldecoderawurlencode:(PHP4,PHP5,PHP7)rawurlencode—根据RFC3986编码URLstringrawurlencode(string$str)根据?RFC3986.rawurldecode编码指定字符:(PHP4,PHP5、PHP7)rawurldecode——解码一个编码的URL字符串stringrawurldecode(string$str)返回一个由百分号（%）后跟两个十六进制数字组成的字符串序列将被文字字符替换。新的曙光出现了，了解rawurldecode，并替换为文字字符。因此，解决方案呼之欲出。rawurldecode(urlencode(urldecode($sign))));乍一看好像很臃肿或者为什么要绕那么多圈？事实上，你真的必须这样处理它。至于为什么，请看上面的吹牛。后记作为程序员，我们必须有两只手的准备和一只手的临时解决方案，可以快速解决当前的问题。在生产环境恢复正常，但从长远来看，必须有一个稳定可靠的解决方案。解决方案来自您的不断尝试和php.net。
