爲什麼gzip/deflate壓縮一個小文件會導致很多尾隨零？

Question

我正在使用下面的代碼來壓縮C＃中的一個小（〜4kB）HTML文件。

byte[] fileBuffer = ReadFully(inFile, ResponsePacket.maxResponsePayloadLength); // Read the entire requested HTML file into a memory buffer 
inFile.Close();                 // Close the requested HTML file 

byte[] payload; 
using (MemoryStream compMS = new MemoryStream())          // Create a new memory stream to hold the compressed HTML data 
{ 
    using (GZipStream gzip = new GZipStream(compMS, CompressionMode.Compress))   // Create a new GZip object pointing to the empty memory stream 
    { 
     gzip.Write(fileBuffer, 0, fileBuffer.Length);         // Compress the file buffer and write it to the empty memory stream 
     gzip.Close();                 // Close the GZip object 
    } 
    payload = compMS.GetBuffer();           // Write the compressed file buffer data in the memory stream to a byte buffer 
} 

生成的壓縮數據大約是2k，但其中大約一半隻是零。這是對帶寬敏感的應用程序（這就是爲什麼我首先壓縮4kB的原因），所以額外的1kB零浪費了寶貴的空間。我最好的猜測是壓縮算法將數據填充到塊邊界。如果是這樣，有沒有辦法來覆蓋這種行爲或更改塊大小？我用vanilla .NET GZipStream和zlib的GZipStream以及DeflateStream獲得了相同的結果。

Answer 1

錯誤的MemoryStream方法。 GetBuffer（）返回底層緩衝區，它總是比流中的數據更大（或完全一樣大）。非常高效，因爲不需要複製。

但是你需要這裏的ToArray（）方法。或者使用Length屬性。