這篇“php curl獲取數(shù)據(jù)不完整的解決方法”除了程序員外大部分人都不太理解,今天小編為了讓大家更加理解“php curl獲取數(shù)據(jù)不完整的解決方法”,給大家總結(jié)了以下內(nèi)容,具有一定借鑒價值,內(nèi)容詳細步驟清晰,細節(jié)處理妥當,希望大家通過這篇文章有所收獲,下面讓我們一起來看看具體內(nèi)容吧。
創(chuàng)新互聯(lián)公司于2013年創(chuàng)立,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項目網(wǎng)站設(shè)計、成都網(wǎng)站設(shè)計網(wǎng)站策劃,項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命,1280元東昌做網(wǎng)站,已為上家服務(wù),為東昌各地企業(yè)和個人服務(wù),聯(lián)系電話:18980820575php是一個嵌套的縮寫名稱,指的是英文超級文本預處理語言(php:Hypertext Preprocessor)的縮寫,它的語法混合了C、Java、Perl以及php自創(chuàng)新的語法,主要用來做網(wǎng)站開發(fā),許多小型網(wǎng)站都用php開發(fā),因為php是開源的,從而使得php經(jīng)久不衰。
php curl獲取數(shù)據(jù)不完整的解決辦法:1、去掉“CURLOPT_RETURNTRANSFER=true”;2、修改數(shù)據(jù)源服務(wù)器的nginx緩存配置。
php curl 獲取數(shù)據(jù)不完整
curl獲取數(shù)據(jù)的時候,結(jié)果的字符串長度比較大。 相同的結(jié)果每次獲取的數(shù)據(jù)都不全,并且長度也不一樣。
試著把 HEADER信息修改為except: 但還是不行(這個可以解決的問題是數(shù)據(jù)量太大導致獲取結(jié)果為空的情況)。
去掉
CURLOPT_RETURNTRANSFER = true
可以打印出完整數(shù)據(jù)
解決方案:
修改數(shù)據(jù)源服務(wù)器的nginx緩存配置
fastcgi_buffers 由原來的 8*128k修改到8*1M
以下引自https://segmentfault.com/a/1190000007513677
Nginx的buffer機制,對于來自 FastCGI Server 的 Response,Nginx 將其緩沖到內(nèi)存中,然后依次發(fā)送到客戶端瀏覽器。緩沖區(qū)的大小由 fastcgi_buffers 和 fastcgi_buffer_size 兩個值控制。
比如如下配置:
fastcgi_buffers 8 4K;
fastcgi_buffer_size 4K;
fastcgi_buffers 控制 nginx 最多創(chuàng)建 8 個大小為 4K 的緩沖區(qū),而 fastcgi_buffer_size 則是處理 Response 時第一個緩沖區(qū)的大小,不包含在前者中。所以總計能創(chuàng)建的較大內(nèi)存緩沖區(qū)大小是 84K+4K = 36k。而這些緩沖區(qū)是根據(jù)實際的 Response 大小動態(tài)生成的,并不是一次性創(chuàng)建的。比如一個 8K 的頁面,Nginx 會創(chuàng)建 24K 共 2 個 buffers。
當 Response 小于等于 36k 時,所有數(shù)據(jù)當然全部在內(nèi)存中處理。如果 Response 大于 36k 呢?fastcgi_temp 的作用就在于此。多出來的數(shù)據(jù)會被臨時寫入到文件中,放在這個目錄下面。
內(nèi)存中緩沖了 36Kb,剩下的會寫入的文件中。而實際的情況是,運行 Nginx Process 的用戶并沒有 fastcgi_temp 目錄的寫權(quán)限,于是剩下的數(shù)據(jù)就丟失掉了。
感謝你的閱讀,希望你對“php curl獲取數(shù)據(jù)不完整的解決方法”這一關(guān)鍵問題有了一定的理解,具體使用情況還需要大家自己動手實驗使用過才能領(lǐng)會,快去試試吧,如果想閱讀更多相關(guān)知識點的文章,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道!