我是否应该在数据流的最开始处期待 JPEG SOI 标记？

...或者我应该深入数据流寻找0xFF 0xD8顺序？

From this Q https://stackoverflow.com/questions/5413022/is-the-2nd-and-3rd-byte-of-a-jpeg-image-always-the-app0-or-app1-marker，我了解到APPn不必立即遵循SOI。是否存在符合规范的 JPEG 情况，其中 SOI 位置！= 流的开头？

引用规范（附录 B，第 1.1.2 节）：

标记用于识别不同的结构部分 压缩数据格式。大多数标记开始标记段包含 一组相关参数；有些标记是独立的。所有标记 分配了两字节代码：一个 X'FF' 字节，后跟一个字节，该字节是 不等于 0 或 X’FF’（见表 B.1）。任何标记都可以可选地 前面有任意数量的填充字节，这些字节是分配代码的字节 X'FF'。

libjpegSOI 之前不允许有垃圾：

/* 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.
*/

From: 随机libjpeg镜像 https://github.com/LuaDist/libjpeg/blob/b1dc50aefb40e62d4bb08356e414e785b23a3a5c/jdmarker.c#L957-L964.

例如。这go执行 http://golang.org/src/pkg/image/jpeg/reader.go?s=10732:10777#L238也不允许前面的垃圾。

然而，如果有疑问，请遵循波斯特尔定律：

接受的内容要自由，发送的内容要保守

不过，您不想太自由，否则您可能最终不会从流中提取实际的 JPEG，而是提取嵌入的 EXIF 缩略图或类似的内容。