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

【问题标题】：When a web server returns a JPEG image (mime type image/jpeg), how is that encoded?当 Web 服务器返回 JPEG 图像（mime 类型图像/jpeg）时，它是如何编码的？
【发布时间】：2012-09-02 08:48:12
【问题描述】：

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

【问题讨论】：

甚至基于字符的数据（HTML、CSS、JS 等）也以字节形式传输。无论如何，其他任何计算机和网络都无法理解的东西。
我们有同样的问题。我认为我们都不必要地区分一段文本的字节和图像的字节。在二进制级别，它们只不过是相同的位。我的问题在这里：stackoverflow.com/questions/20086460/…

标签： http mime-types

【解决方案1】：

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

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

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

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

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

[SOI][APP0][长度]J F I F NULL

按照规范。

接收到的文件包含这个，在标题之后：

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

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

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

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

【讨论】：

那将是一个损坏的服务器。
我也写了自己的网络服务器。我的也不行。我尝试了您上面提到的修复方法，但没有成功。但是我想知道您是否发现图片和标题之间需要更多的空白行。我将看看更改这些数据是否会有所帮助。

【解决方案2】：

原始字节通过网络发送。

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

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

【讨论】：

是的，压缩 JPEG 文件没有多大意义，因为它们已经通过了熵压缩阶段，你不会进一步压缩 ^^

【解决方案3】：

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

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

【讨论】：

一般来说，配置良好的 Web 服务器不会压缩 jpgs（尽管它肯定是可能的）。（除非我遗漏了什么？）
最终决定将始终在 Web 服务器上，无论是为了优化还是因为请求的编码不受支持（即：在 HTML 文件上请求 Base64） .虽然Accept-Encoding 标头可能会声明接受deflate 和其他不可接受的标头（即：deflate;q=1, *;q=0），但大多数服务器不会返回 HTTP 代码 406 并返回未编码的数据。请参阅第 14.3 节注释和第 3.9 节。使用alternativeto.net/about 测试该请求。
我认为你同意我所说的——但我并不完全清楚。无论如何，感谢您提供详细信息。