本文實(shí)例分析了PHP5.0~5.6 各版本兼容性cURL文件上傳功能。分享給大家供大家參考，具體如下：

最近做的一個(gè)需求，要通過PHP調(diào)用cURL，以multipart/form-data格式上傳文件。踩坑若干，夠一篇文章了。

重要警告

沒事不要讀PHP的官方中文文檔！版本跟不上坑死你！

不同版本PHP之間cURL的區(qū)別

PHP的cURL支持通過給CURL_POSTFIELDS傳遞關(guān)聯(lián)數(shù)組（而不是字符串）來生成multipart/form-data的POST請求。

傳統(tǒng)上，PHP的cURL支持通過在數(shù)組數(shù)據(jù)中，使用“@+文件全路徑”的語法附加文件，供cURL讀取上傳。這與命令行直接調(diào)用cURL程序的語法是一致的：

1. curl_setopt(ch, CURLOPT_POSTFIELDS, array( 
2.   'file' => '@'.realpath('image.png'), 
3. )); 

equals

$ curl -F "file=@/absolute/path/to/image.png" <url>

但PHP從5.5開始引入了新的CURLFile類用來指向文件。CURLFile類也可以詳細(xì)定義MIME類型、文件名等可能出現(xiàn)在multipart/form-data數(shù)據(jù)中的附加信息。PHP推薦使用CURLFile替代舊的@語法：

1. curl_setopt(ch, CURLOPT_POSTFIELDS, [ 
2.   'file' => new CURLFile(realpath('image.png')), 
3. ]); 

PHP 5.5另外引入了CURL_SAFE_UPLOAD選項(xiàng)，可以強(qiáng)制PHP的cURL模塊拒絕舊的@語法，僅接受CURLFile式的文件。5.5的默認(rèn)值為false，5.6的默認(rèn)值為true。

但是坑的一點(diǎn)在于：@語法在5.5就已經(jīng)被打了deprecated，在5.6中就直接被刪除了（會產(chǎn)生 ErorException: The usage of the @filename API for file uploading is deprecated. Please use the CURLFile class instead）。

對于PHP 5.6+而言，手動設(shè)置CURL_SAFE_UPLOAD為false是毫無意義的。根本不是字面意義理解的“設(shè)置成false，就能開啟舊的unsafe的方式”——舊的方式已經(jīng)作為廢棄語法徹底不存在了。PHP 5.6+ == CURLFile only，不要有任何的幻想。

我的部署環(huán)境是5.4(僅@語法)，但開發(fā)環(huán)境是5.6(僅CURLFile)。都沒有壓在5.5這個(gè)兩者都支持過渡版本上，結(jié)果就是必須寫出帶有環(huán)境判斷的兩套代碼。

現(xiàn)在問題來了……

環(huán)境判斷：小心魔法數(shù)字！

我見過這種環(huán)境判斷的代碼：

if (version_compare(phpversion(), '5.4.0') >= 0)

我對這種代碼的評價(jià)只有一個(gè)字：屎。

這個(gè)判斷掉入了典型的魔法數(shù)字陷阱。版本號莫名其妙的出現(xiàn)在代碼之中，不查半天PHP手冊和更新歷史，很難明白作者被卡在了哪個(gè)功能的變更上。

代碼應(yīng)該回歸本源。我們的實(shí)際需求其實(shí)是：有CURLFile就優(yōu)先采用，沒有再退化到傳統(tǒng)@語法。那么代碼就來了：

1. if (class_exists('/CURLFile')) { 
2.   $field = array('fieldname' => new /CURLFile(realpath($filepath))); 
3. } else { 
4.   $field = array('fieldname' => '@' . realpath($filepath)); 
5. } 

建議明確指定的退化選項(xiàng)

從可靠的角度，推薦指定CURL_SAFE_UPLOAD的值，明確告知php是容忍還是禁止舊的@語法。注意在低版本PHP中CURLOPT_SAFE_UPLOAD常量本身可能不存在，需要判斷：

1. if (class_exists('/CURLFile')) { 
2.   curl_setopt($ch, CURLOPT_SAFE_UPLOAD, true); 
3. } else { 
4.   if (defined('CURLOPT_SAFE_UPLOAD')) { 
5.     curl_setopt($ch, CURLOPT_SAFE_UPLOAD, false); 
6.   } 
7. } 

cURL選項(xiàng)設(shè)置的順序

不管是curl_setopt()單發(fā)還是curl_setopt_array()批量，cURL的選項(xiàng)總是設(shè)置一個(gè)生效一個(gè)，而設(shè)置好的選項(xiàng)立刻就會影響cURL在設(shè)置后續(xù)選項(xiàng)時(shí)的行為。

例如CURLOPT_SAFE_UPLOAD就和CURLOPT_POSTFIELDS的行為有關(guān)。如果先設(shè)置CURLOPT_POSTFIELDS再設(shè)置CURLOPT_SAFE_UPLOAD，那么后者的約束作用就不會生效。因?yàn)樵O(shè)置前者時(shí)cURL就已經(jīng)把數(shù)據(jù)實(shí)際的識讀處理完畢了！

cURL有那么幾個(gè)選項(xiàng)存在這種坑，務(wù)必小心。還好這種存在“依賴關(guān)系”的選項(xiàng)不多，機(jī)制也不復(fù)雜，簡單處理即可。我的方法是先批量設(shè)置所有的選項(xiàng)，然后直到curl_exec()的前一刻才用curl_setopt()單發(fā)設(shè)置CURLOPT_POSTFIELDS。

實(shí)際上在curl_setopt_array()用的數(shù)組中，保證CURLOPT_POSTFIELDS的位置在后邊也是可靠的。PHP的關(guān)聯(lián)數(shù)組是有順序保障的，我們也可以假設(shè)curl_setopt_array()內(nèi)部的執(zhí)行順序一定是從頭到尾按順序（好吧我知道assume不是件好事，不過有些實(shí)在過分淺顯的事實(shí)，就容我下個(gè)最低限度的斷言吧），所以盡可放心。

我的做法只是在代碼表現(xiàn)上加個(gè)多余的保險(xiǎn)，突出強(qiáng)調(diào)順序的重要性防以后手賤。

命名空間

PHP 5.2或以下的版本沒有命名空間。代碼中用到了空間分隔符就會引發(fā)解析器錯(cuò)誤。要照顧PHP 5.2其實(shí)容易想，放棄命名空間即可。

要注意的反倒是有命名空間的PHP 5.3+。無論是調(diào)用CURLFile還是用class_exists()判斷CURLFile的存在性，都推薦寫成CURLFile明確指定頂層空間，防止代碼包裹在命名空間內(nèi)的時(shí)候崩掉。