.NET WebClient 類下載部分文件會錯誤?可能是解壓縮的鍋
- 2020 年 3 月 5 日
- 筆記
.NET WebClient 類下載部分文件會錯誤?可能是解壓縮的鍋
2020-03-03 08:26
一直在使用 WebClient
下載文件,.NET 已經封裝好,所以用起來代碼非常簡潔;但直到今天發現有一個文件一直不能正確下載下來。
本文介紹這個問題的原因和解決方法,更重要的是給出調查方法。
本文所涉及到的域名已經過敏感信息處理,所以實際上你是無法訪問到的;但這不影響本文對調查方法的描述。
問題
我原本是使用如下的代碼去下載任意文件的(參數經過簡化)。
private static async Task DownloadFileAsync() { var url = "http://localhost:5000/walterlv-icon.svg"; var fileName = @"C:UserslvyiDesktopTESTwalterlv-icon.svg"; using var webClient = new WebClient(); webClient.DownloadFile(new Uri(url), fileName); }
現在,下載一個 svg 的時候,原本應該是如下的圖片:
然而實際上下載下來之後卻是這樣的:
原本大小是 992 位元組,實際下載下來後是 508 位元組,而且固定是 508 位元組。你可以通過右鍵複製圖片地址,然後分別把兩張圖下載下來看。
調查
顯然,WebClient
沒有拋出任何異常,而且每次下載下來都是固定的 508 位元組,說明肯定不是網絡不通或程序提前退出導致的,也不是線程安全相關的問題。基本可以認定為問題出在服務器的配置,或者客戶端的請求上。
使用其他「正常」下載器嘗試
拿 Chrome 跑以上地址,拿專用下載工具跑以上地址,甚至是拿 Postman 跑以上地址,都可以成功顯示或者下載到正確的圖片。
這幾乎可以肯定,問題出在 .NET 的 WebClient 上,可能是請求不對,或者對響應的後續處理不對。
使用 Postman 和 WebClient 對比測試
為了對比請求和響應,我使用的是 Fiddler 抓包。
WebClient
請求:
GET http://localhost:5000/walterlv-icon.svg HTTP/1.1 Host: localhost:5000 Connection: Keep-Alive
WebClient
響應:
HTTP/1.1 200 OK Date: Tue, 03 Mar 2020 07:54:53 GMT Content-Type: image/svg+xml Transfer-Encoding: chunked Connection: keep-alive Expires: Tue, 02 Mar 2021 09:16:30 GMT Server: JSP3/2.0.14 Content-Encoding: gzip ETag: W/"Fid8uZXkFIrQWqDgx84YL_8PPqIi" Last-Modified: Wed, 08 Jan 2020 04:20:14 GMT Accept-Ranges: bytes Cache-Control: public, max-age=31536000 Access-Control-Allow-Origin: * Access-Control-Expose-Headers: X-Log, X-Reqid Access-Control-Max-Age: 2592000 Content-Disposition: inline; filename="walterlv-icon.svg"; filename*=utf-8''walterlv-icon.svg Content-MD5: +6J/pVyMK4cWQf8n3gMnbQ== Content-Transfer-Encoding: binary X-Log: X-Log X-M-Log: QNM:xs441;SRCPROXY:xs1756;SRC:39;SRCPROXY:39;QNM3:40 X-M-Reqid: wgIAAAiVtix6zucV X-Qiniu-Zone: 0 X-Qnm-Cache: Miss X-Reqid: ttYAAAAPpS16zucV X-Svr: IO Ohc-File-Size: 992 Timing-Allow-Origin: * Ohc-Cache-HIT: suz2ct85 [3], njctcache85 [1], qdix85 [1] Age: 81503 X-Via: 1.1 PShbhgdx4pn187:2 (Cdn Cache Server V2.0)[0 200 0], 1.1 PS-FOC-01tho70:12 (Cdn Cache Server V2.0)[0 200 0] Access-Control-Allow-Methods: GET,OPTIONS Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: * 1fc S]o 0}Τ ;4 1 V- & k u 4 ɯ m i a 9 k_ aW ! d 61b " *m n <FM ? } K O?o@ }u e ! _ <% *** FIDDLER: RawDisplay truncated at 128 characters. Right-click to disable truncation. ***
Postman 請求:
GET http://localhost:5000/walterlv-icon.svg HTTP/1.1 Content-Type: application/json User-Agent: PostmanRuntime/7.22.0 Accept: */* Cache-Control: no-cache Postman-Token: 05bb3d80-d7a7-4c0d-bdd1-9cd65d79ecab Host: localhost:5000 Accept-Encoding: gzip, deflate, br Connection: keep-alive
Postman 響應:
HTTP/1.1 200 OK Date: Tue, 03 Mar 2020 07:58:26 GMT Content-Type: image/svg+xml Transfer-Encoding: chunked Connection: keep-alive Expires: Tue, 02 Mar 2021 09:16:30 GMT Server: JSP3/2.0.14 Content-Encoding: gzip ETag: W/"Fid8uZXkFIrQWqDgx84YL_8PPqIi" Last-Modified: Wed, 08 Jan 2020 04:20:14 GMT Accept-Ranges: bytes Cache-Control: public, max-age=31536000 Access-Control-Allow-Origin: * Access-Control-Expose-Headers: X-Log, X-Reqid Access-Control-Max-Age: 2592000 Content-Disposition: inline; filename="walterlv-icon.svg"; filename*=utf-8''walterlv-icon.svg Content-MD5: +6J/pVyMK4cWQf8n3gMnbQ== Content-Transfer-Encoding: binary X-Log: X-Log X-M-Log: QNM:xs441;SRCPROXY:xs1756;SRC:39;SRCPROXY:39;QNM3:40 X-M-Reqid: wgIAAAiVtix6zucV X-Qiniu-Zone: 0 X-Qnm-Cache: Miss X-Reqid: ttYAAAAPpS16zucV X-Svr: IO Ohc-File-Size: 992 Timing-Allow-Origin: * Ohc-Cache-HIT: suz2ct85 [3], njctcache85 [1], qdix85 [1] Age: 81716 X-Via: 1.1 PShbhgdx4pn187:2 (Cdn Cache Server V2.0)[0 200 0], 1.1 PS-FOC-01tho70:12 (Cdn Cache Server V2.0)[0 200 0] Access-Control-Allow-Methods: GET,OPTIONS Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: * 1fc S]o 0}Τ ;4 1 V- & k u 4 ɯ m i a 9 k_ aW ! d 61b " *m n <FM ? } K O?o@ }u e ! _ <% *** FIDDLER: RawDisplay truncated at 128 characters. Right-click to disable truncation. ***
請求和響應貼得很長,這可以讓比較感興趣的小夥伴仔細比較。但這裡我直接給出我比較後的結論:
- Postman 的請求會發送比較多的頭
- 兩者的響應幾乎相同(包括文件大小和內容)
由於響應幾乎相同,所以實際上前面請求頭的不同可以忽略了(至少說明返回的內容沒有因為請求的不同而有所變化),我們能夠拿到完整的整個文件。
那麼問題基本確定就是在 WebClient 對這個響應的處理上了。
可以注意到 Postman 的請求中有 Accept-Encoding
,兩折的響應中都有 Content-Encoding
,指定了 gzip
。然而這是 Linux 中用來壓縮文件的命令。響應中指定了內容編碼方式為 gzip
是否意味着我們下載下來的文件實際上是一個 gzip 壓縮文件呢?
於是我將下載下來的文件擴展名改為 gzip,用壓縮文件打開,於是真的可以解壓出來真實的圖片。
於是確認問題的原因是 WebClient
在處理響應的時候沒有根據 Content-Encoding
的值解壓縮下載下來的文件。
解決
解決的思路:
- 使
WebClient
支持下載文件後解壓縮
使 WebClient
支持下載文件後解壓縮
各種檢查後發現,WebClient
竟然沒有提供設置解壓縮相關的屬性。慶幸的是,在網上搜索 WebClient
和 gzip
關鍵字後,找到了這一篇答案:.net – Automatically decompress gzip response via WebClient.DownloadData – Stack Overflow。
我們需要重寫 WebClient.GetWebRequest
方法,然後改寫 AutomaticDecompression
屬性。此屬性可以改成 gzip
、deflate
和 br
或者它們的組合,這與 Postman 發請求時聲明支持的值是完全一樣的。
class AutoDecompressionWebClient : WebClient { protected override WebRequest GetWebRequest(Uri address) { var baseRequest = base.GetWebRequest(address); if (baseRequest is HttpWebRequest httpWebRequest) { httpWebRequest.AutomaticDecompression = DecompressionMethods.All; } return baseRequest; } }
另外,也可以在拉取到響應的流後自己去做解壓,可以參見:
參考資料
- .net – Automatically decompress gzip response via WebClient.DownloadData – Stack Overflow
- c# – WebClient.DownloadFile File Corrupt – Stack Overflow
- Download file using Webclient shows Wrong Data – CodeProject
- [Solved] WebClient DownloadFile method downloads damaged PDF files – CodeProject