至於為什麽是四個字節，非固定塊加密時（固定塊表示每塊長度固定），壹般要說明其塊長度，而這個壹般使用的是4個字節的整數（.net中的Int32/int)，不同語言的可能定義也不同，但這個4個字符來源於GZip的規定用四個字節來說明長度（低位在前，高位在後）。所以不管是哪個語言，不管4個字節是叫int(.net）還是叫long(C++）都必須使用4個字節的。
但從頭到尾均沒有出現在前邊有四個字節的說法！且我也沒有聽說過，因為GZip是壹種壓縮算法，這種算法是否在前邊存在有字節長度的說明，是算法規定好的！所以我的第壹反應就是不可能的——GZip有自己的標準，難道某個語言實現時不按標準來嗎？
那麽是不是有可能出現兩種語言無法解壓的情況呢？標準之所以稱之為標準，兩種語言實現時必須按相同的標準，換句話來說標準本身就必須在不同的語言實現達到壹個統壹轉換的過程。不可能用.net的MD5到Java中驗證不了，也不可能.net的GZip壓縮到Java中解壓不了！
那麽為什麽會出現某些人說的無法解壓的情況呢？因為死讀書的程序員導致的！標準是標準，但標準中也往往有不同的選擇！比如在GZip壓縮中就有快速/優化兩種壓縮方式，當然這兩處方式。而不在同語言中所使用的默認壓縮方式不同，另壹種語言中的默認解壓方式不同，就會出現無法匹配的情況。
我舉個例子吧，好多人在問DES加解密Java與.net不對稱，我覺得不可能，後來才知道，壹邊默認壓縮，另壹連默認解壓，問題在於.net默認是CBC格式，而Java中恰恰不是！這就導致加解密錯誤的原因。事實上我即使在不跨語言時也會經常指明格式，所以我倒是沒有遇到這種情況。
比如 GZipStream stream = new GZipStream(baseStream, CompressLevel.Faster,true);試試這個，但不管怎麽說，妳若去掉四個字節，在Android中的出錯就表示，其實妳去錯了！