PHP urlencode 方法可以算是使用率比较高的一个方法了。特别是在 API 接口设计的领域或使用其他第三方 API 的时候，经常会碰到使用 urlencode 的场景。

在几年前设计过一套 API 接口提供给 App 客户端调用。Android 客户端使用 Java 开发，他们会把参与按照文档定义的规则把参数名与值进行拼接之后再 urlencode 编码，然后再拼接上一个密钥 KEY 再 MD5 再转换为大写得到一个签名。服务器端收到这个请求之后，也会按照这个规则进行签名生成与客户端提交的签名进行判断。

结果问题就出来了。

// Android 客户端提交的信息如下：
$params = [
    'method'   => 'user.register',  // 注册接口。
    'v'           => '1.0.0',        // APP 版本号。
    'mobile'   => '14812345678',    // 注册手机号。
    'code'     => '123456',        // 短信验证码。
    'password' => 'abcde fg'        // 账号密码。注意这里带了一个空格。
];

// 按照键名自然排序(升序)。
ksort($params);

// 把键名与值拼接。
$str = '';
foreach ($params as $key => $value) {
    $str .= "{$key}{$value}";
}

$key  = 'abckey';         // 密钥 KEY。
$str  = urlencode($str);     // URL encode 转码。
$sign = md5($str . $key);    // 生成签名。
$sign = strtoupper($sign);    // 签名转成大写。

echo $sign; // 输出结果：80ADC8A5878776D971E4ED444FB8386B

上面这一套规则其实非常简单。可问题出就出在上面的 password 参数存在一个空格。而我们使用 urlencode 转码之后，这个空格会被转码成 + 号。

$str = 'xxx xxx';
echo urlencode($str); // 输出：xxx+xxx

而 Java 或者其他的语言，它们的 urlencode 会把空格转码为 %20。很显然 + 与 %20 是完全不相同的字符串。在进行 MD5 签名生成的时候，很显然签名是不对等。

我们查阅 PHP urlencode 的文档获知，它存在历史的原因，并未遵循 RFC3986 标准导致。所以，PHP 提供了另一个遵守 RFC3986 标准的 urlencode 方法：rawurlencode。

该方法与其他语言的 urlencode 方法保持一致的转码规则。

结论：接口设计的时候不要使用 urlencode，而要使用 rawurlencode 方法。

以上是最近对接多家 API 接口之后，重新唤醒了我几年前接口设计时的一些踩坑回忆。于是，今天特意整理并分享给大家。