使用腾讯云平台 IM 服务，调用 REST API，其中要组装 URL 中的 Query，今天竟大费周折；

• 使用 PHP 的 http_build_query 函数是一个最常用的做法，但是腾讯 API 返回错误；

<?php
$data=array('foo'=>'bar',
    'baz'=>'boom',
    'cow'=>'milk*&k=5',
    'php'=>'hypertext processor');
    echo http_build_query($data)."\n";
?>
foo=bar&baz=boom&cow=milk%2A%26k%3D5&php=hypertext+processor

• 开发伙伴不知为何没去查找错误原因，就直接想到找 intl extension 扩展库，使用其 Query::createFromPairs 函数，还竟然得到腾讯的正确返回了；
• 线上部署需要安装 intl 扩展；

问题：安装 intl 扩展虽然简单，能想到找扩展来解决问题也是一条路子，但我总讶异，这样的一个小事情，还需要动用扩展？觉得好奇，就探究了一下，结论：
1. http_build_query 函数是可靠的；
2. 腾讯 API 的实现是有缺陷的；
3. intl 扩展的实现看起来并不简单；
4. intl 扩展的缺陷掩盖了腾讯的缺陷；

根本原因在于，对 urlencode 标准和实现机制的理解是存在差异性的；对于 Base64，也存在这样的问题；

解释

• urlencode 准确地说是 Percent-encoding，比如：/ 会编码为%2F；
• query 的通常形式：k1=v1&k2=v2，这里 v1 和 v2 都应当是 percent-encoding 过的；
• 腾讯的代码是直接拼接字符串的，而 usersig 值中含有 *，直接拼接的结果和 http_build_query 函数处理结果自然不一样，从实际运行中，本来也没问题；可是腾讯服务端处理这个的时候，估计编解码有问题（接口例子和服务端实现可能是由同一个同学写的），导致返回错误；
  可是，WebServer 的实现其实是自动处理 url 的编解码的啊，不太明白；
• 由于 intl 扩展的实现也是直接拼接，所以反而 API 正常通过（一个缺陷掩盖了另一个缺陷）；
• 一个简单、奇怪但有效的做法是：将 http_build_query 的结果进行 urldecode 也能正常访问 API；

相关函数

• PHP parse_url 函数解构 url；
• PHP parse_str 函数进一步解构 query；
• PHP urlencode 对字符串进行编码，通常是用来单独编码 path 或者 query 的某个 key 的值的；urlencode 是具有一定迷惑性的；
  rawurlencode 函数，采用 RFC 3986 编码方式；
  urlencode 函数，采用 RFC1738 编码方式；
  这两者差别不大；

• intl 扩展的做法并不符合 query 通常的实现约定；

  
  
  采用 intl 扩展的做法

intl extension

• 安装；
  注意 ICU - International Components for Unicode 问题；
• 修改 php.ini；