GZipStream實現壓縮以及出現的問題

2021-04-20 14:53:05 字數 963 閱讀 3989

在抓取頁面的過程中,在儲存抓取到的頁面內容的時候我需要先將頁面壓縮再儲存,為了使用上的方便,採用了2.0下的gzipstream來進行壓縮。

引用如下:

using system.io;

using system.io.compression;

......

public

static

byte compress(byte data)

public

static

byte decompress(byte data)

return stream.toarray();

}上 面的**使用起來似乎是沒有什麼問題的(如果你不仔細做測試的話),但是當我對各種大小的頁面進行測試後,發現如果壓縮後byte長度<4k, 那麼問題出來了:沒法解壓,解壓函式中read返回結果總是0。聞一多先生曾經在演講中說「鬱悶啊,鬱悶,這是某集團的鬱悶,恰恰是微軟的光榮(筆者注: 我覺得應該屬於微軟bug)」。

我一度懷疑是不是decompress函式中的bytes陣列長度設定長了,後來把長度設定的很小,但是解壓後還是那樣,返回0。真想去和蓋茨理論理論。

不過幸運的是,我測試發現了這個4k下限制,所以google了下「gzipstream  4k」,哈哈,在國外的一論壇(http://www.dotnetmonster.com/uwe/forum.aspx/dotnet-framework/19787/problem-with-the-gzipstream-class-and-small-streams)裡面終於找到了答案:原來gzipstream訪問資料的時候是以4k為塊進行訪問的。所以在壓縮的時候,在返回stream.toarray()前應該先gzipstream.close()(也就是上面俺賣關子的那裡),原因是gzipstream是在dispose的時候把資料完全寫入。你說冤嗎?我明明已經write了,竟然還要我再close才可以。。。

繼續鬱悶......還不知道會出現什麼更加有意思東西哦

使用GZipStream實現壓縮和解壓縮

之前做專案,涉及到存入到資料庫或者http傳輸的資料量比較大,這個時候,就需要考慮在存入資料庫或者傳送傳輸之前,將資料壓縮下,當從資料庫中取出時,再解壓還原資料。特地找了下發現有gzipstream可以實現這個功能。此類表示gzip資料格式,該格式使用行業標準演算法進行無損檔案壓縮和解壓縮。該格式包...

GZipStream實現壓縮以及出現的問題

在抓取頁面的過程中,在儲存抓取到的頁面內容的時候我需要先將頁面壓縮再儲存,為了使用上的方便,採用了2.0下的gzipstream來進行壓縮。引用如下 using system.io using system.io.compression public static byte compress byt...

GZipStream實現壓縮以及出現的問題

在抓取頁面的過程中,在儲存抓取到的頁面內容的時候我需要先將頁面壓縮再儲存,為了使用上的方便,採用了2.0下的gzipstream來進行壓縮。引用如下 usingsystem.io usingsystem.io.compression public static bytecompress byteda...