如果您向Web服务器发出HTTP请求，并且它返回类型为image / jpeg的响应，那么二进制数据是如何实际编码的？它是通过线路的图像的原始字节级内容，还是它的一些基于字符的表示（例如base64）？
答案 0 :(得分：4)
编码的传输数据由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 。
答案 1 :(得分：2)
原始字节通过网络发送。
（通过一些设置，您可以使用Wireshark，tcp_dump等确认这一点。）
请注意，大多数服务器都配置为而非来压缩JPEG，但该文本数据通常是压缩的。
答案 2 :(得分：0)
除了添加MIME标头之外，网络服务器似乎剥离了所有jpeg标记（0xFF，0xNN），但其余部分保持不变。这看起来很奇怪，因为我不知道网页浏览器是如何识别图像框架的开始的。
我通过在嵌入式系统中编写自己的简单网络服务器来发现这一点 - 我想我只需要添加MIME标头并发送其余的jfif-jpeg文件，但浏览器说“图像不能显示，因为它包含错误“！
这是十六进制原始jpeg / jfif的开头
ff d8 ff e0 00 10 4a 46 49 46 00
[SOI] [APP0] [length] J F I F NULL
根据规范。
收到的文件在标题后面包含：
0d 0a 0d 0a 00 10 4a 46 49 46 00
前4个字节是标题末尾的cr / lf / cr / lf，然后是NO标记，但它确实包含数据字段。对于其他标记重复相同的事情，例如框架的开始。
奇怪吧？我不认为这是一个哑剧编码问题，因为其余的数据看起来完好无损 - 包括数据中的FF等。
任何人都知道这里发生了什么？ PS看起来更接近，只需要使用putty或类似的任何网站请求.jpg，并保存你得到的，并将其与原始版本，甚至保存为版本进行比较。