不同版本PHP之間cURL的區別(-經驗之談)，不同版本curl_PHP教程

不同版本PHP之間cURL的區別(-經驗之談)，不同版本curl

之前在做一個採集的工具,實現採集回來的文章,圖片儲存起來.文章內容是儲存在資料庫,圖片是先需要上傳到圖片伺服器,再返回圖片地址,替換掉文章的圖片地址.

問題來了:都能成功採集都東西,但是,本地測試是正常的,圖片也可以上傳成功,但是生產環境就是一直沒有圖片.然後自己就一步一步調試,,探索資料都有,但為什麼偏偏生產上沒有成功上傳圖片呢.

後來折騰了幾天,經過一步步的看代碼,調試,百度,終於找到答案了.真是一個大坑.

上傳到圖片伺服器是用curl post過去的,

PHP的cURL支援通過給CURL_POSTFIELDS傳遞關聯陣列（而不是字串）來產生multipart/form-data的POST請求。

傳統上，PHP的cURL支援通過在數組資料中，使用“@+檔案全路徑”的文法附加檔案，供cURL讀取上傳。這與命令列直接調用cURL程式的文法是一致的：

curl_setopt(ch, CURLOPT_POSTFIELDS, array(    'file' => '@'.realpath('image.png'), )); equals$ curl -F "file=@/absolute/path/to/image.png" 

但PHP從5.5開始引入了新的CURLFile類用來指向檔案。CURLFile類也可以詳細定義MIME類型、檔案名稱等可能出現在multipart/form-data資料中的附加資訊。PHP推薦使用CURLFile替代舊的@文法：

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

PHP 5.5另外引入了CURL_SAFE_UPLOAD選項，可以強制PHP的cURL模組拒絕舊的@文法，僅接受CURLFile式的檔案。5.5的預設值為false，5.6的預設值為true。

但是坑的一點在於：@文法在5.5就已經被打了deprecated，在5.6中就直接被刪除了（會產生 ErorException: The usage of the @filename API for file uploading is deprecated. Please use the CURLFile class instead）。

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

我的部署環境是5.4(僅@文法)，但開發環境是5.6(僅CURLFile)。都沒有壓在5.5這個兩者都支援過渡版本上，結果就是必須寫出帶有環境判斷的兩套代碼。

現在問題來了……

環境判斷：小心魔法數字！

我見過這種環境判斷的代碼：

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

我對這種代碼的評價只有一個字：屎。

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

代碼應該迴歸本源。我們的實際需求其實是：有CURLFile就優先採用，沒有再退化到傳統@文法。那麼代碼就來了：

if (class_exists('\CURLFile')) {    $field = array('fieldname' => new \CURLFile(realpath($filepath)));} else {    $field = array('fieldname' => '@' . realpath($filepath));}

建議明確指定的退化選項

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

if (class_exists('\CURLFile')) {    curl_setopt($ch, CURLOPT_SAFE_UPLOAD, true);} else {    if (defined('CURLOPT_SAFE_UPLOAD')) {        curl_setopt($ch, CURLOPT_SAFE_UPLOAD, false);    }}

cURL選項設定的順序

不管是curl_setopt()單發還是curl_setopt_array()批量，cURL的選項總是設定一個生效一個，而設定好的選項立刻就會影響cURL在設定後續選項時的行為。

例如CURLOPT_SAFE_UPLOAD就和CURLOPT_POSTFIELDS的行為有關。如果先設定CURLOPT_POSTFIELDS再設定CURLOPT_SAFE_UPLOAD，那麼後者的約束作用就不會生效。因為設定前者時cURL就已經把資料實際的識讀處理完畢了！

cURL有那麼幾個選項存在這種坑，務必小心。還好這種存在“依賴關係”的選項不多，機制也不複雜，簡單處理即可。我的方法是先大量設定所有的選項，然後直到curl_exec()的前一刻才用curl_setopt()單發設定CURLOPT_POSTFIELDS。

實際上在curl_setopt_array()用的數組中，保證CURLOPT_POSTFIELDS的位置在後邊也是可靠的。PHP的關聯陣列是有順序保障的，我們也可以假設curl_setopt_array()內部的執行順序一定是從頭到尾按順序[注A]，所以盡可放心。

我的做法只是在代碼錶現上加個多餘的保險，突出強調順序的重要性防以後手賤。

命名空間

PHP 5.2或以下的版本沒有命名空間。代碼中用到了空間分隔字元\就會引發解析器錯誤。要照顧PHP 5.2其實容易想，放棄命名空間即可。

要注意的反倒是有命名空間的PHP 5.3+。無論是調用CURLFile還是用class_exists()判斷CURLFile的存在性，都推薦寫成\CURLFile明確指定頂層空間，防止程式碼封裝裹在命名空間內的時候崩掉。

好了,這坑挖得好深,跳出來就分享下.

(以上解決方案是轉載網站的,感謝讓我找到了你這篇東西!)

http://www.bkjia.com/PHPjc/1126175.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/1126175.htmlTechArticle不同版本PHP之間cURL的區別(-經驗之談)，不同版本curl 之前在做一個採集的工具,實現採集回來的文章,圖片儲存起來.文章內容是儲存在資料庫...

