不一樣版本PHP之間cURL的區別(-經驗之談)

文章已經放在這裏了！

不一樣PHP版本之間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" <url> 

但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明確指定頂層空間，防止代碼包裹在命名空間內的時候崩掉。

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

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

 

歡迎關注公衆號【phper的進階之路】，將不斷更新各類技術心得，免費提供各類學習資源！！！