使用腾讯云平台 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；
