我有一個C＃應用程序與基於PHP的SOAP Web服務進行通信以獲取更新和許可。PHP可以解壓縮使用.NET GZipStream類壓縮的文件嗎？
我現在正在開發反饋系統，供用戶通過軟件自動提交錯誤和tracelogs。基於之前發佈的一個問題，我覺得Web服務是最好的方式（最有可能以最少的配置正常工作）。
我目前的想法是使用.NET內置gzip壓縮來壓縮文本文件，轉換爲base64，發送到Web服務，並讓PHP腳本轉換爲二進制文件並解壓縮數據。
PHP解壓縮的數據可以用GZipStream壓縮，如果是的話，怎麼樣？
我居然試過這個。 GZipStream不起作用。另一方面，在.NET端使用DeflateStream進行壓縮，並在PHP端使用gzinflate進行解壓縮。你的里程可能會有所不同...
是的，PHP可以解壓GZIP壓縮的字符串，帶或不帶標頭。
我因爲我不熟悉.NET GZipStream，所以不確定你會想要哪一個。這聽起來有點像gzuncompress，因爲ZLIB格式是一種「流式」格式，但嘗試所有三種格式。
由於服務器正在接受Web請求，所以您應該檢查HTTP標頭以確定是否有客戶端接受GZIP編碼，而不是隻是每次都進行猜測和gzip。
如果PHP客戶端可以執行gzip itll設置標題，您的代碼將根據並做出正確的反應。假設或猜測是爲您的代碼提供設施以瞭解客戶端功能時的糟糕選擇。
我不認爲這適用。客戶端是C＃應用程序，服務器是基於PHP的。客戶端正在啓動到服務器的連接，因此頭文件將由客戶端（C＃）應用程序生成，而不是服務器生成。 – 2009-05-25 07:52:04
@Chris您錯過了這一點，客戶需要告訴服務器什麼以及它想要什麼。就像它使用URL來標識資源一樣，標題的理由是包含各種元數據，包括客戶希望接收的編碼格式。 您不知道標題背後的全部原因，它們允許客戶端發送額外的信息，其中服務器可以定製響應。 – 2009-05-26 02:47:57
例如theres一個頭可以檢查查詢有關用戶首選語言權重告訴你他們想要什麼語言。你的服務器的東西應該自然地檢查這一點，並有可能定製你的迴應。如果你寫一個國際應用程序，那麼檢查和迎合這一點是有道理的......當服務人員想要西班牙語或德語時，不是每個人都會說英語和發送英語會很愚蠢。 – 2009-05-26 02:49:33
如果http級庫實現它（客戶端和服務器），http has support for gzip-compression，在這種情況下，沒有任何理由手動壓縮任何東西。你應該檢查這是否已經發生，然後再冒險。
我寫了一篇文章，我最近發佈的文章展示瞭如何在C＃中進行壓縮/解壓縮。我用它幾乎相同的情況。我想將日誌文件從客戶端傳輸到服務器，而且它們通常很大。但在我的情況下，我的web服務在.NET中運行，所以我可以使用解壓縮方法。但看起來像PHP確實支持一種名爲gzdecode的方法。
以供將來參考：gzinflate是將解壓縮壓縮GZipStream數據的方法。 – 2011-01-14 09:17:44