之前在做一個采集的工具,實現采集回來的文章,圖片保存起來.文章內容是保存在數據庫,圖片是先需要上傳到圖片服務器,再返回圖片地址,替換掉文章的圖片地址.
問題來了:都能成功采集都東西,但是,本地測試是正常的,圖片也可以上傳成功,但是生產環境就是一直沒有圖片.然後自己就一步一步調試,,發現數據都有,但為什麼偏偏生產上沒有成功上傳圖片呢.
後來折騰了幾天,經過一步步的看代碼,調試,百度,終於找到答案了.真是一個大坑.
上傳到圖片服務器是用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_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
明確指定頂層空間,防止代碼包裹在命名空間內的時候崩掉。
好了,這坑挖得好深,跳出來就分享下.
(以上解決方法是轉載網站的,感謝讓我找到了你這篇東西!)