Image 我应该在数据流的最开始使用JPEG SOI标记吗？

。。。或者我应该深入数据流寻找

0xFF 0xD8

序列吗

从中，我了解到APPn不必立即跟随SOI。是否存在符合规范的JPEG情况，其中SOI位置！=溪流的源头

---

规范中的引用（附录B，§1.1.2）：

标记用于识别建筑物的各个结构部分 压缩数据格式。大多数标记从包含以下内容的标记段开始 一组相关的参数；有些标记是独立的。所有标记 被分配了两个字节码：一个X'FF'字节，后跟一个 不等于0或X'FF'（见表B.1）。任何标记都可以是可选的 前面有任意数量的填充字节，这些字节是分配给代码的字节 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.
*/

发件人：

例如，也不允许前面的垃圾

但是，如果有疑问，请遵守波斯特定律：

在你接受的东西上要自由，在你发送的东西上要保守

---

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

如果开始时随机垃圾字节使整个流无效，这是非常合乎逻辑的，但我说的是填充字节，这似乎是规范允许的（参见编辑）。是的，规范可能会这么说，但包括参考实现在内的许多实现处理SOI的方式不同（我给出了libjpeg，go作为示例）。但是，填充字节（有时甚至是随机垃圾）在我遇到的大多数实现中，前面的标记对于所有其他标记都被欣然接受……至少在某一点上是这样。