14

Web サーバーに HTTP 要求を送信し、image/jpeg タイプの応答が返された場合、バイナリ データは実際にどのようにエンコードされるのでしょうか? ネットワークを通過する画像の元のバイトレベルのコンテンツですか、それとも文字ベースの表現 (base64 など) ですか?

4

3 に答える 3

9

エンコードされた転送データは、HTTP応答ヘッダーによって指定されます（ RFC2616セクション14.11および3.5Content-EncodingのHTTP 1.1仕様を参照）。存在する場合は、、、または圧縮データのいずれかです（HTTP 1.1では他に定義されていません）。そうでない場合、データはHTTP応答ヘッダー（MIMEタイプ）に基づく元のエンコードになります。は、HTTPリクエストヘッダー値と、Webサーバーがリクエストされたエンコーディングをサポートしているかどうかによって決まります。gzipcompressdeflateContent-TypeContent-EncodingAccept-Encoding

あなたの場合、Content-EncodingHTTP応答ヘッダーがない場合、データはファイルの内容とまったく同じです。それ以外の場合は、指定されたエンコーディングで圧縮されます。例：GZipまたはDeflate。

于 2012-09-09T01:03:05.377 に答える
2

元のバイトはネットワーク経由で送信されます。

(少し設定すれば、Wireshark、tcp_dump などでこれを確認できます。)

ほとんどのサーバーはJPEG を圧縮しないように構成されていますが、通常、テキスト データは圧縮して送信されることに注意してください。

于 2012-09-09T00:30:01.093 に答える
0

不思議なことに、それは「ストレートスルー」ではありません。

MIMEヘッダーを追加する以外に、Webサーバーはすべてのjpegマーカー（0xFF、0xNN）を削除しているように見えますが、残りはそのまま残しています。Webブラウザが画像フレームの開始をどのように認識しているかわからないため、これは奇妙に思えます。

組み込みシステムで独自のシンプルなウェブサーバーを作成することでこれを見つけました-MIMEヘッダーを追加し、残りのjfif-jpegファイルをそのまま送信するだけでよいと思いましたが、ブラウザには「画像を表示できないため、画像を表示できません。エラーが含まれています」！

これが16進数の元のjpeg/jfifの始まりです

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

[SOI] [APP0] [length] JFIF NULL

仕様通り。

受信したファイルには、ヘッダーの後に次のものが含まれています。

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

最初の4バイトはヘッダーの最後のcr/lf / cr / lfであり、その後マーカーはありませんが、データフィールドが含まれています。フレームの開始など、他のマーカーについても同じことが繰り返されます。

奇妙なハァッ？データの残りの部分（データ内のFFを含む）は無傷に見えるため、MIMEエンコーディングの問題ではないと思います。

誰もがここで何が起こっているのか知っていますか？PSを詳しく見るには、パテなどを使用して任意のWebサイトに.jpgを要求し、取得したものを保存して、元のバージョンまたは保存済みバージョンと比較します。

于 2013-02-06T17:20:58.830 に答える