使用騰訊云平臺 IM 服務(wù)，調(diào)用 REST API编兄，其中要組裝 URL 中的 Query，今天竟大費(fèi)周折；
- 使用 PHP 的 http_build_query 函數(shù)是一個(gè)最常用的做法砚婆，但是騰訊 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
- 開發(fā)伙伴不知為何沒去查找錯誤原因突勇，就直接想到找 intl extension 擴(kuò)展庫装盯，使用其 Query::createFromPairs 函數(shù)，還竟然得到騰訊的正確返回了甲馋；
- 線上部署需要安裝 intl 擴(kuò)展埂奈；
問題：安裝 intl 擴(kuò)展雖然簡單，能想到找擴(kuò)展來解決問題也是一條路子定躏，但我總訝異账磺，這樣的一個(gè)小事情芹敌，還需要動用擴(kuò)展？覺得好奇垮抗，就探究了一下氏捞，結(jié)論：
1. http_build_query 函數(shù)是可靠的；
2. 騰訊 API 的實(shí)現(xiàn)是有缺陷的冒版；
3. intl 擴(kuò)展的實(shí)現(xiàn)看起來并不簡單液茎；
4. intl 擴(kuò)展的缺陷掩蓋了騰訊的缺陷；
根本原因在于辞嗡，對 urlencode 標(biāo)準(zhǔn)和實(shí)現(xiàn)機(jī)制的理解是存在差異性的捆等；對于 Base64，也存在這樣的問題欲间；
解釋
- urlencode 準(zhǔn)確地說是 Percent-encoding楚里，比如：
/會編碼為%2F； - query 的通常形式：k1=v1&k2=v2猎贴，這里 v1 和 v2 都應(yīng)當(dāng)是 percent-encoding 過的班缎；
- 騰訊的代碼是直接拼接字符串的，而 usersig 值中含有
*她渴，直接拼接的結(jié)果和 http_build_query 函數(shù)處理結(jié)果自然不一樣达址，從實(shí)際運(yùn)行中，本來也沒問題趁耗；可是騰訊服務(wù)端處理這個(gè)的時(shí)候沉唠，估計(jì)編解碼有問題（接口例子和服務(wù)端實(shí)現(xiàn)可能是由同一個(gè)同學(xué)寫的），導(dǎo)致返回錯誤苛败；
可是满葛，WebServer 的實(shí)現(xiàn)其實(shí)是自動處理 url 的編解碼的啊，不太明白罢屈； - 由于 intl 擴(kuò)展的實(shí)現(xiàn)也是直接拼接嘀韧，所以反而 API 正常通過（一個(gè)缺陷掩蓋了另一個(gè)缺陷）；
- 一個(gè)簡單缠捌、奇怪但有效的做法是：將 http_build_query 的結(jié)果進(jìn)行 urldecode 也能正常訪問 API锄贷；
相關(guān)函數(shù)
- PHP parse_url 函數(shù)解構(gòu) url；
- PHP parse_str 函數(shù)進(jìn)一步解構(gòu) query曼月；
- PHP urlencode 對字符串進(jìn)行編碼谊却，通常是用來單獨(dú)編碼 path 或者 query 的某個(gè) key 的值的；urlencode 是具有一定迷惑性的哑芹；
rawurlencode 函數(shù)炎辨，采用 RFC 3986 編碼方式；
urlencode 函數(shù)绩衷，采用 RFC1738 編碼方式蹦魔；
這兩者差別不大激率； -
intl 擴(kuò)展的做法并不符合 query 通常的實(shí)現(xiàn)約定；
采用 intl 擴(kuò)展的做法
intl extension
-
安裝勿决；
注意 ICU - International Components for Unicode 問題乒躺； - 修改 php.ini；
