内容长度与实际文件长度

发布于 2024-08-28 21:11:33 字数 55 浏览 3 评论 0原文

有谁有过这样的经历:标头中请求下载的文件(HTTP)内容长度不等于下载时的实际文件长度(大小)?

Does anyone has any experience wherein the requested file to download (HTTP) content length in the header does not equal to the actual file length (size) when downloaded?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

半窗疏影 2024-09-04 21:11:33

内容长度标头是 HTTP 响应正文中的字节数。

这是在所有编码阶段之后计算的,大多数编码方法都会改变长度。

  • 压缩会缩小它,
  • Base 64 会增加它。

内容长度标头仅在从套接字读取多少原始数据时有用。分配缓冲区来保存解码的内容无济于事。

(我刚刚编写了一些代码来拉取数据,但必须读取响应流以增量扩展缓冲区,而不是一次大的分配读取。)

The content length header is the number of bytes in the body of the HTTP response.

This is calculated after all encoding stages, most encoding methods will change the length.

  • Compression will shrink it
  • Base 64 will increase it.

The content length header is only useful in terms of how much raw data to read from the socket. It will not help will allocating a buffer to hold the decoded content.

(I have just written some code to pull data down, but have to read the response stream incrementally expanding the buffer rather than one big allocate an read.)

阿楠 2024-09-04 21:11:33

您提出问题的方式具有误导性。

当 HTTP 响应携带内容长度标头时,该标头就是消息的长度。时期。好吧,除了 HEAD 响应。

如果服务器发送的数据超过此数量,则服务器已损坏。

The way you phrase the question is misleading.

When an HTTP response carries a content-length header, that is the length of the message. Period. Well, except for HEAD responses.

If a server sends more than that, it's broken.

对风讲故事 2024-09-04 21:11:33

您可以改用 WebClient.DownloadTaskAsync(...)。文件大小将相同。

You can use WebClient.DownloadTaskAsync(...) instead. There file size will be the same.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文