先看常用的校验请求合法性的一个方式
function createToken($params) {
$secretKey = 'secretKey';
ksort($params);
$query = http_build_query($params);
$token = md5($query . $secretKey);
return $token;
}
function createQuery($params) {
$params['token'] = createToken($params);
$query = http_build_query($params);
return $query;
}
function checkQuery($params) {
$token = $params['token'];
unset($params['token']);
return $token == createToken($params);
}
$params = [
'k1' => 'v1',
'k2' => 'v2',
'time' => time()
];
$query = createQuery($params);
echo $query, PHP_EOL;
parse_str($query, $result);
var_dump(checkQuery($result));
输出
k1=v1&k2=v%202&time=1537806711&token=e088ac85569f9eb5266026bb8da989b2
bool(true)
client 每个请求都携带一个 token ，token 是由请求参数和一个 secret key 一起md5之后计算出来的， 然后 server 端使用同样的算法计算token（一般还会校验time，给 token 一个有效期，我这里简化了），然后对比 token ，保证请求的合法性。
乍一看，这个算法几乎天衣无缝，恩，我之前也是这么认为的，直到我用这个算法和一个 java 的服务交互时，才发现这个写法有些问题。
我在和 java 的同事连调时，有个请求总是报 token 校验错误，但是其他请求却没这个问题，我俩百思不得其解，互相 review 对方代码，也没有发现问题，然后和 java 的同事加了很多 log，终于发现了端倪。
我请求的参数里，有一个参数的值带有空格，然后我这边 url encode 之后
echo urlencode(" ");
// +
但是他那边 url encode 之后是
// 假装这里有 java url encode 的代码
%20
这样，问题就很清晰了，不是算法问题，而是 url encode 的编码标准的问题。
php的 http_build_query （urlencode也一样）默认使用的 RFC 1738 （http://php.net/manual/zh/function.http-build-query.php）
默认使用 PHP_QUERY_RFC1738，如果 enc_type 是 PHP_QUERY_RFC1738，则编码将会以 RFC 1738 标准和 application/x-> www-form-urlencoded 媒体类型进行编码，空格会被编码成加号（+），如果 enc_type 是 PHP_QUERY_RFC3986，将根据 RFC 3986 编码，空格会被百分号编码（%20）。
而他那边用的是 RFC 3986 。
那么怎么规避这个问题呢？
常见的无非就是这两种方案，第一，两边使用同样的编码标准，第二，生成 token 的算法改一下，不要使用 url encode 之后的字符串加密（建议）。
更多架构、PHP、GO相关踩坑实践技巧请关注我的公众号：PHP架构师 ![]()
