GZip頁腳中的流大小與實際流大小不匹配

從GzipStream解壓縮時，出現IO異常「GZip頁腳中的流大小與實際流大小不匹配」。此錯誤發生在多個文件的100％時間，所以我不認爲這是一個「真正的」損壞的文件問題。GZip頁腳中的流大小與實際流大小不匹配

壓縮代碼如下：

using (var fileStream = fileInfo.OpenRead()) 
      { 
       using (var outFile = File.Create(Path.Combine(backupLocation, backupFileName.ToString()))) 
       { 
        using (var gzCompressionStream = new GZipStream(outFile, CompressionMode.Compress)) 
        { 
         fileStream.CopyTo(gzCompressionStream); 
        } 
       } 
      }

被拋出異常的解壓縮代碼如下：

using (var fileStream = fileInfo.OpenRead()) 
      { 
       // remove the extension 
       var fileName = fileInfo.Name; 
       var originalName = fileName.Remove(fileName.Length - fileInfo.Extension.Length); 

       using (var outFile = File.Create(Path.Combine(transferLocation, originalName))) 
       { 
        using (var gzDecompressionStream = new GZipStream(fileStream,CompressionMode.Decompress)) 
        { 
         gzDecompressionStream.CopyTo(outFile); 
        } 
       } 
      }

來源

2012-05-14 Johnv2020

代碼看起來很合理。您是否已驗證文件名是否有效（即檢查一個文件是否使用硬編碼名稱壓縮 - >解壓縮）？ –

抱歉不太確定我是否關注你，文件名將如何影響解壓縮？ – Johnv2020

即，壓縮：「Source.txt」 - >「compressed.compr」，解壓縮：「random.file」（而不是「compressed.compr」） - >「Source.txt」（失敗，因爲「random.file」未壓縮所有）。 –

所有，感謝您的幫助 - 看起來像我發現問題。當壓縮文件大小大於4GB時，我只會收到一個錯誤，低於此一切正常， - 這應該不是問題，因爲MSDN指出GZipStream適用於文件大小高達8GB的.Net 4（其中I正在使用），最大文件大小將始終低於6GB（應用程序限制）。但以前版本的GZipStream只支持4GB - 看起來好像MSDN文檔在這種情況下不正確。

來源

2012-05-14 21:39:56 Johnv2020

這是GZipStream中的又一個錯誤。 gzip流的最後四個字節是未壓縮的（未壓縮的）長度的模2^32，作爲對數據的檢查。如果未壓縮的長度的低32位匹配，則檢查結果是好的。 –

我在這裏看到了GZipStream的許多其他問題。其中包括它沒有正確使用固定與動態與存儲塊，導致壓縮輸出對於短輸入而言太大，並且crc不匹配通常未被檢測到，導致在出現嚴重錯誤時沒有錯誤。我建議不要使用來自Microsoft的這個類。 –

GZip頁腳中的流大小與實際流大小不匹配

回答

相關問題