使用騰訊云平臺 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；
