ContentLength vs Actual File.Length

有沒有人有任何經驗，其中下載時請求的文件下載（HTTP）內容長度不等於下載時的實際文件長度（大小）？ContentLength vs Actual File.Length

2010-04-17 Jojo

，除了其中值爲-1的內容長度;或者在我的情況下（使用套接字）內容長度在接收到的頭文件中不可用。 – Jojo 2010-04-17 08:34:01

數據壓縮是否被自動解碼？什麼是標題？ – 2010-04-17 08:34:21

嗨馬克，情況是這樣的： 1.請求文件下載。 HTTP標頭包含的內容長度爲1000. 2.文件已下載。實際的File.Length == 1005. 這種情況可能嗎？我只想要確認。我正在處理PDF文件。 – Jojo 2010-04-17 08:42:48

內容長度標題是HTTP響應正文中的字節數。

這是在所有編碼階段後計算出來的，大多數編碼方法會改變長度。

內容長度標頭僅用於從套接字中讀取多少原始數據。它不會幫助分配一個緩衝區來保存已解碼的內容。

（我剛纔寫一些代碼來拉數據下來，但要讀響應流逐步擴大緩衝區，而不是一個大分配一個讀。）

2010-04-17 08:50:02 Richard

那麼有可能實際下載的文件長度不等於內容長度頭？ – Jojo 2010-04-17 08:55:49

Base64未在HTTP中使用。 – 2010-04-17 09:27:39

@Jojo：對。 – Richard 2010-04-17 10:17:03

的方式將短語問題是誤導。

當一個HTTP響應攜帶一個內容長度頭時，該消息的長度爲爲。期。那麼，除了HEAD的迴應。

如果服務器發送的數量多於此數量，則會發生故障。

2010-04-17 09:27:17

所以如果這是「消息」的長度（這裏的「消息」可能是一個PDF文件）。如果下載的文件大小（本地文件大小或FileInfo.Length）是否可能基於HTTP頭的內容長度值不等於該PDF文件的文件大小？ – Jojo 2010-04-17 09:35:20

如果我使用Content-Encoding（例如gzip）發送的文件，則Content-Length將引用* compressed *大小。如果收件人（如瀏覽器）自動解壓縮，則是的，生成的文件將會（大部分時間）更大。也許你應該詳細說明你爲什麼要問... – 2010-04-17 11:39:09

回答