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

回答