php curl獲取數(shù)據(jù)不完整的解決方法

這篇“php curl獲取數(shù)據(jù)不完整的解決方法”除了程序員外大部分人都不太理解，今天小編為了讓大家更加理解“php curl獲取數(shù)據(jù)不完整的解決方法”，給大家總結(jié)了以下內(nèi)容，具有一定借鑒價值，內(nèi)容詳細步驟清晰，細節(jié)處理妥當，希望大家通過這篇文章有所收獲，下面讓我們一起來看看具體內(nèi)容吧。

php有什么用

php是一個嵌套的縮寫名稱，指的是英文超級文本預處理語言（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ù)源服務器的nginx緩存配置。

php curl 獲取數(shù)據(jù)不完整

curl獲取數(shù)據(jù)的時候，結(jié)果的字符串長度比較大。 相同的結(jié)果每次獲取的數(shù)據(jù)都不全，并且長度也不一樣。

試著把 HEADER信息修改為except: 但還是不行（這個可以解決的問題是數(shù)據(jù)量太大導致獲取結(jié)果為空的情況）。

去掉

 CURLOPT_RETURNTRANSFER = true

可以打印出完整數(shù)據(jù)

解決方案：

修改數(shù)據(jù)源服務器的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 目錄的寫權限，于是剩下的數(shù)據(jù)就丟失掉了。

感謝你的閱讀，希望你對“php curl獲取數(shù)據(jù)不完整的解決方法”這一關鍵問題有了一定的理解，具體使用情況還需要大家自己動手實驗使用過才能領會，快去試試吧，如果想閱讀更多相關知識點的文章，歡迎關注億速云行業(yè)資訊頻道！