...または0xFF 0xD8シーケンスを探しているデータストリームを詳しく調べる必要がありますか？データストリームの始めにJPEG SOIマーカーが必要ですか？
this Qから、私はAPPnがSOIにすぐに従う必要がないことを学びました。 SOIの位置！=ストリームの始まり？
明細書から引用（付録B、1.1.2条）：
マーカーは 圧縮データ形式の様々な構造部品を特定するのに役立ちます。ほとんどのマーカーは、関連するパラメーターグループ を含むマーカーセグメントを開始します。いくつかのマーカーは単独で立つ。すべてのマーカ には、X'FF 'バイトに続く でないバイトまたはX'FF'（表B.1を参照）が2バイトコードとして割り当てられます。任意のマーカは任意に、 の前に任意の数のフィルバイト（コード X'FF 'に割り当てられたバイト）を置くことができます。
libjpegは、SOIの前にゴミを許可していません：
/* Like next_marker, but used to obtain the initial SOI marker. */
/* For this marker, we do not allow preceding garbage or fill; otherwise,
* we might well scan an entire input file before realizing it ain't JPEG.
* If an application wants to process non-JFIF files, it must seek to the
* SOI before calling the JPEG library.
*/
など。 go implementationは先行するゴミも許可しません。あなたもしたくない、けれども
はあなたが
を送信するもので、あなたが受け入れるものにリベラルと保守的である：疑わしい場合
しかし、ポステルの法則にこだわります実際のJPEGをストリームから抽出するのではなく、埋め込まれたEXIFサムネイルなどを抽出することになります。
最初のランダムなガベージバイトがストリーム全体を無効にするのはかなり論理的ですが、私はスペックによって許可されているように見えるパディングバイトについて話していました（編集を参照）。 –
ええ、仕様はそうだと言えるかもしれませんが、リファレンス実装を含む多くの実装がSOIを異なって扱います（例としてlibjpegを与えました）。しかし、私が遭遇したほとんどの実装では、マーカーに先行する塗りつぶしバイト（および時にはランダムなガーベッジ）が他のすべてのマーカーに対して喜んで受け入れられます...少なくともある点まで。 – nmaier