http - 当 Web 服务器返回 JPEG 图像（mime 类型图像/jpeg）时，它是如何编码的？

Question

如果您向 Web 服务器发出 HTTP 请求，它返回类型为 image/jpeg 的响应，那么二进制数据实际上是如何编码的？是通过网络传输的图像的原始字节级内容，还是它的一些基于字符的表示（例如base64）？

Answer 1

编码后的传输数据由Content-EncodingHTTP 响应标头指定（请参阅RFC2616第 14.11 和 3.5 节中的 HTTP 1.1 规范）。如果存在，它可以是gzip、compress或deflate压缩数据（HTTP 1.1 中未定义其他数据）。如果不是，则数据采用基于Content-TypeHTTP 响应标头（MIME 类型）的原始编码。这Content-Encoding取决于Accept-EncodingHTTP 请求标头值和 Web 服务器是否支持请求的编码。

在您的情况下，如果Content-EncodingHTTP 响应标头不存在，则数据与文件内容完全相同。否则，将使用指定的编码对其进行压缩。例如：GZip或Deflate。

Answer 2

原始字节通过线路发送。

（通过一些设置，您可以使用 Wireshark、tcp_dump 等来确认这一点。）

请注意，大多数服务器都配置为不压缩 JPEG，但文本数据通常以压缩方式发送。

Answer 3

奇怪的是，这不是“直通”。

除了添加 MIME 标头外，网络服务器似乎删除了所有 jpeg 标记（0xFF、0xNN），但其余部分保持不变。这似乎很奇怪，因为我不知道网络浏览器是如何识别图像帧的开始的。

我通过在嵌入式系统中编写自己的简单网络服务器发现了这一点 - 我认为我只需要添加 MIME 标头并发送 jfif-jpeg 文件的其余部分不受影响，但浏览器显示“无法显示图像，因为它包含错误”！

这是十六进制原始 jpeg/jfif 的开头

ff d8 ff e0 00 10 4a 46 49 46 00

[SOI][APP0][长度]JFIF NULL

根据规范。

收到的文件在标题之后包含以下内容：

0d 0a 0d 0a 00 10 4a 46 49 46 00

前 4 个字节是标头末尾的 cr/lf/cr/lf，然后是 NO 标记，但它确实包含数据字段。对其他标记重复同样的事情，例如帧的开始。

奇怪吧？我认为这不是 MIME 编码问题，因为其余数据看起来完好无损 - 包括数据中的 FF 等。

有人知道这里发生了什么吗？PS 仔细观察，只需使用 putty 或类似工具从任何网站请求 .jpg 并保存您获得的内容，并将其与原始版本甚至另存为版本进行比较。