的Http CONTENTLENGTH大於實際文件大小

獲取的HttpResponse消息CONTENTLENGTH爲diifferent：的Http CONTENTLENGTH大於實際文件大小

var contentLength = response.Content.Headers.ContentLength; 
Console.WriteLine(contentLength);

獲取XML文件長度爲：

FileInfo f = new FileInfo(fileName); 
long filesize = f.Length;

現在打印兩種大小的時候，它給了我一個爲3970和其他3968. 我想比較兩者的大小，但由於這種差異，我沒有做到這一點。任何幫助？

來源

2017-09-22 ayushi

我會說這可能是字節順序標記但是這3個字節不是2. – Lloyd

你試圖做一個（自動）響應和文件內容的字節到字節比較以查看差異在哪裏？ – Sefe

@Lloyd BOM是UTF-16中的2個字節，UTF-32中的4個，以及3個字節（中斷）的UTF-8。破壞了，因爲UTF-8不需要BOM（事實上，它被Unicode標準禁止），但是一些編輯錯了，現在它是一個事實上的（破碎的）標準 –

檢查流與文件的前2個字節。 UTF-16具有2字節的BOM，它可能是：

http://www.opentag.com/xfaq_enc.htm#enc_default

First bytes  Encoding assumed 
----------------------------------------- 
EF BB BF   UTF-8 
FE FF    UTF-16 (big-endian) 
FF FE    UTF-16 (little-endian) 
00 00 FE FF  UTF-32 (big-endian) 
FF FE 00 00  UTF-32 (little-endian) 
None of the above UTF-8

來源

2017-09-22 08:53:59 CamW

這是一個UTF-8編碼。有什麼辦法可以避免contentLength和使用其他內容，因爲ContentLength是從Headers定義的，因此響應是以Header +內容（額外的2個字節）的形式出現的 – ayushi

我認爲這裏有一些混亂，你說ContentLength是Headers + Content。這不是真的，它被定義爲：「Content-Length實體頭字段指示實體主體的大小」它只是HTTP請求主體的大小。如果您可以將文件和響應流的前幾個（5）字節作爲十六進制字符串以及HTTP的所有響應標題發佈，可能是最好的。 – CamW

文件六角內容3c3f786d6c2076657273696f6e3d22312e302220656e636f64696e673d227574662d3822207374616e64616c6f6e653d22796573223f3ea3c6665656420786d6c3a626173653d22687474703a2f2f6465762d73656c6563742d73657276696365732e79746e696f702e636f6d2f70726f6475637472656769737472792f7365617263682f2220786d6c6e733a643d22687474703 – ayushi

的Http CONTENTLENGTH大於實際文件大小

回答

相關問題