《C# 爬蟲 破境之道》：第二境 爬蟲應用 — 第三節：處理壓縮資料
續上一節內容，本節主要講解一下Web壓縮資料的處理方法。
在HTTP協議中指出，可以通過對內容壓縮來減少網路流量，從而提高網路傳輸的效能。
那麼問題來了，在HTTP中，採用的是什麼樣的壓縮格式和機制呢？
首先呢，先說壓縮格式，主要有三種：
- DEFLATE，是一種使用 Lempel-Ziv 壓縮演算法（LZ77）和哈夫曼編碼的資料壓縮格式。定義於 RFC 1951 : DEFLATE Compressed Data Format Specification；
- ZLIB，是一種使用 DEFLATE 的資料壓縮格式。定義於 RFC 1950 : ZLIB Compressed Data Format Specification；
- GZIP，是一種使用 DEFLATE 的檔案格式。定義於 RFC 1952 : GZIP file format specification；
我們這裡就不細琢磨了，格式裡面又有演算法，又有規則什麼的，我也搞不清楚，說多了，捱罵……理解上，就相當於我們常用的Zip、7Zip、RAR等壓縮格式；
但是需要注意的是，ZLIB和GZIP都是使用的DEFLATE，這就有點兒意思了，後面再說：）
說完壓縮格式，再來說機制，分為兩條路子（請求、回覆）：
- 請求：在request header中指定Accept-Encoding。例如：Accept-Encoding: gzip, deflate, compress, br；Accept-Encoding在Headers中是可選的，可以不指定；當然，其中還有一些規則，後面我們結合回覆一起給出；
- 回覆：在response header中指定Content-Encoding。例如：Content-Encoding: gzip；Content-Encoding在Headers中也是可選的，可以不指定；不過現在大多數站點都會對內容進行壓縮，不過通常不會對圖片及視訊等已經經過壓縮的資源進行壓縮，因為得不償失啊；
來解釋一下，首先客戶端（比如說瀏覽器）發出請求，我們在使用瀏覽器的過程中，一般就只是輸入一個網址或點選某個連線，不會刻意去填寫一下Accept-Encoding，但是瀏覽器會為我們新增；這個Accept-Encoding，就是告訴網站伺服器端，我（瀏覽器）可以解釋這幾種壓縮格式（一個列表），你（網站伺服器）要是壓縮，就給我這幾種格式，否則，就不要壓縮了；網站伺服器端收到請求後，進行解析，看看有沒有自己能夠使用的壓縮格式，如果有，那麼就進行壓縮，如果有多個可以使用，那就要看優先順序，選擇優先順序最高的格式進行壓縮（後面列出規則），並將使用的壓縮格式填入Content-Encoding中傳送回客戶端；客戶端（瀏覽器）收到回覆以後，就看Content-Encoding有沒有值，如果有並且自己也認識，那麼就可以正常解壓，顯示在介面上了。
這個就是壓縮的機制了，一切看起來那麼的和諧，但在網際網路的世界，總是不缺乏“驚喜”，即使客戶端不指定任何Accept-Encoding，伺服器端也會根據情況返回Content-Encoding，這就迫使瀏覽器，還必須得有兩把刷子，否則就傻眼了。
HTTP Header中Accept-Encoding 是瀏覽器發給伺服器,宣告瀏覽器支援的編碼型別[1] 常見的有 Accept-Encoding: compress, gzip //支援compress 和gzip型別 Accept-Encoding: //預設是identity Accept-Encoding: * //支援所有型別 Accept-Encoding: compress;q=0.5, gzip;q=1.0//按順序支援 gzip , compress Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 // 按順序支援 gzip , identity 伺服器返回的對應的型別編碼header是 content-encoding.伺服器處理accept-encoding的規則如下所示： 1. 如果伺服器可以返回定義在Accept-Encoding 中的任何一種Encoding型別, 那麼處理成功(除非q的值等於0, 等於0代表不可接受) 2. * 代表任意一種Encoding型別 (除了在Accept-Encoding中顯示定義的型別) 3. 如果有多個Encoding同時匹配, 按照q值順序排列 4. identity總是可被接受的encoding型別(除非明確的標記這個型別q=0) 如果Accept-Encoding的值是空, 那麼只有identity是會被接受的型別 如果Accept-Encoding中的所有型別伺服器都沒法返回, 那麼應該返回406錯誤給客戶端 如果request中沒有Accept-Encoding 那麼伺服器會假設所有的Encoding都是可以被接受的。 如果Accept-Encoding中有identity 那麼應該優先返回identity (除非有q值的定義,或者你認為另外一種型別是更有意義的) 注意: 如果伺服器不支援identity 並且瀏覽器沒有傳送Accept-Encoding,那麼伺服器應該傾向於使用HTTP1.0中的 "gzip" and "compress" , 伺服器可能按照客戶端型別傳送更適合的encoding型別 大部分HTTP1.0的客戶端無法處理q值 Accept-Encoding與Content-Encoding的規則Accept-Encoding 與 Content-Encoding 的對應規則
另外，需要額外說明的是，在Accept-Encoding中指定的delfate，可不一定是DEFLATE壓縮格式，按照官方的說法：
- gzip，一種由檔案壓縮程式「Gzip，GUN zip」產生的編碼格式，描述於 RFC 1952。這種編碼格式是一種具有 32 位 CRC 的 Lempel-Ziv 編碼（LZ77）；
- deflate，由定義於 RFC 1950 的「ZLIB」編碼格式與 RFC 1951 中描述的「DEFLATE」壓縮機制組合而成的產物；
也就是說，deflate其實對應的應該是ZLIB壓縮格式，而它的名字，又與DEFLATE格式重名（估計這位同仁會被祭天了吧），導致很多瀏覽器廠商不知道究竟該用哪種格式來解釋Content-Encoding: deflate，因為不論你選擇哪種，都會有例外發生，這就尷尬了。所以，儘管deflate的壓縮效果要比gzip好，但還是會被不少Web-Server放棄或者降低優先順序。這也就是為什麼我們會經常看到Content-Encoding: gzip而很少能看到Content-Encoding: deflate的原因；所以，我們在做爬蟲的時候，也應該儘量避免使用deflate，減少不必要的麻煩。
話鋒一轉，回到我們的爬蟲，也會遇到上面瀏覽器遇到的尷尬場面，所以，就必須得事先準備好常用的解壓縮方式，要不然，資料抓下來了，讀不出來，你說氣不氣~
本節中，我們就來繼續改造我們的爬蟲框架，讓它也有兩把刷子：）
[Code 2.3.1]
1 public static byte[] DecompressStreamData(Stream sourceStream, String contentEncoding)
2 {
3 var _stream = sourceStream;
4 switch ((contentEncoding ?? string.Empty).ToLower())
5 {
6 case "gzip":
7 _stream = new GZipStream(sourceStream, CompressionMode.Decompress);
8 break;
9 case "deflate":
10 _stream = new DeflateStream(sourceStream, CompressionMode.Decompress);
11 break;
12 default:
13 break;
14 }
15 using (var memory = new MemoryStream())
16 {
17 int length = 256;
18 Byte[] buffer = new Byte[length];
19 int bytesRead = _stream.Read(buffer, 0, length);
20 while (bytesRead > 0)
21 {
22 memory.Write(buffer, 0, bytesRead);
23 bytesRead = _stream.Read(buffer, 0, length);
24 }
25 return memory.ToArray();
26 }
27 }
DecompressStreamData 靜態方法
這是一個公共靜態方法，其目的就是將原資料流中的資料轉換為byte[]陣列，其中，如果指定了壓縮格式，就會使用適當的方法進行解壓。這裡只提供了最常見的gzip和不推薦的deflate兩種格式，可以自行擴充套件。
接下來，就是對工蟻（WorkerAnt）進行改造了。
[Code 2.3.2]
1 private void GetResponse(JobContext context)
2 {
3 context.Request.BeginGetResponse(new AsyncCallback(acGetResponse =>
4 {
5 var contextGetResponse = acGetResponse.AsyncState as JobContext;
6 using (contextGetResponse.Response = contextGetResponse.Request.EndGetResponse(acGetResponse))
7 using (contextGetResponse.ResponseStream = contextGetResponse.Response.GetResponseStream())
8 using (contextGetResponse.Memory = new MemoryStream())
9 {
10 // 此處省略N行……
11
12 if (TaskStatus.Running == contextGetResponse.JobStatus)
13 {
14 if (!String.IsNullOrEmpty(contextGetResponse.Response.Headers["Content-Encoding"]))
15 {
16 contextGetResponse.Memory.Seek(0, SeekOrigin.Begin);
17 contextGetResponse.Buffer = DecompressStreamData(contextGetResponse.Memory
18 , contextGetResponse.Response.Headers["Content-Encoding"]);
19 //contextGetResponse.Buffer = contextGetResponse.Memory.ToArray();
20 }
21 else
22 contextGetResponse.Buffer = contextGetResponse.Memory.ToArray();
23
24 contextGetResponse.JobStatus = TaskStatus.RanToCompletion;
25 NotifyStatusChanged(new JobEventArgs { Context = context, EventAnt = this, });
26 }
27
28 contextGetResponse.Buffer = null;
29 }
30 }), context);
31 }
改造WorkerAnt的GetResponse方法
註釋中是原來使用的方法，現在用上面的DecompressStreamData替換掉了。
這樣我們在收到採集完成事件通知時，就可以得到解壓縮後的資料了：
[Code 2.3.3]
1 switch (args.Context.JobStatus)
2 {
3 // 此處省略N行……
4 case TaskStatus.RanToCompletion:
5 if (null != args.Context.Buffer && 0 < args.Context.Buffer.Length)
6 {
7 Task.Factory.StartNew(oBuffer =>
8 {
9 var content = new UTF8Encoding(false).GetString((byte[])oBuffer);
10 richOutput.EndInvoke(richOutput.BeginInvoke(new MethodInvoker(() => { richOutput.Text = content; })));
11 }, args.Context.Buffer, TaskCreationOptions.LongRunning);
12 }
13 if (null != args.Context.Watch)
14 Console.WriteLine("/* ********************** using {0}ms / request ******************** */"
15 + Environment.NewLine + Environment.NewLine, (args.Context.Watch.Elapsed.TotalMilliseconds / 100).ToString("000.00"));
16 break;
17 // 此處省略N行……
18 default:/* Do nothing on this even. */
19 break;
20 }
改造應用中對事件的處理
至於為何在Complete事件的位置處理解壓縮，而不在Running事件的位置，這是gzip的限制，它具有CRC校驗位，CRC的演算法，大家可以在網上搜索，大體上說，就是遍歷一遍所有資料，進行與或計算，最終得到一個校驗位，來保證資料的完整性與正確性。這也導致我們無法對中間資料進行解壓，因為沒有校驗位，對末尾資料解壓，又因資料不全，CRC計算結果也不會對。
至此，我們就完成了對HTTP協議內容部分已壓縮資料的處理，拋磚引玉，可以實現更多種壓縮格式的處理；
節外生枝：
- 本節講述的資料壓縮，指的是HTTP協議中，對協議內容部分的壓縮，在HTTP 2.x的版本中，增加了對協議頭部的壓縮（更確切的說是快取）的機制，用空間換時間，由於2.x版本Schema為HTTPS，處理起來，另有蹊蹺，本節先不做深入介紹了，可作為延伸內容，有興趣的童鞋可以搜尋相關主題；
- 為了方便以後的做更多更好的案例，原始碼中增加了一個WinForm專案，這樣在切換Uri的時候，就更方便一些；
喜歡本系列叢書的朋友,可以點選連結加入QQ交流群(994761602)【C# 破境之道】
方便各位在有疑問的時候可以及時給我個反饋。同時，也算是給各位志同道合的朋友提供一個交流的平臺。
需要原始碼的童鞋，也可以在群檔案中獲取最新原始碼。