在抓取頁面的過程中，在儲存抓取到的頁面內容的時候我需要先將頁面壓縮再儲存，為了使用上的方便，採用了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...