确定 JPEG 的结尾（与另一个文件合并时）答案

【问题标题】：Determining end of JPEG (when merged with another file)确定 JPEG 的结尾（与另一个文件合并时）
【发布时间】：2011-02-03 19:35:39
【问题描述】：

我正在创建一个在 JPEG 末尾“隐藏”加密文件的程序。问题是，当再次检索此加密文件时，我需要能够确定它存储的 JPEG 何时结束。起初我认为这不是问题，因为我可以通过文件检查 0xFF 和 0xD9，即 JPEG 用于结束图像的字节。但是......我注意到在相当多的 JPEG 中，这种字节组合是不是独有的......所以我的程序认为图像在中途随机结束。

我认为必须有一套表达 JPEG 已完成的方式，否则我在文件末尾添加大量字节显然会损坏它......有没有实用的方法来做到这一点？

【问题讨论】：

有很多更好的方法来实现steganography。例如，使用建议的方法，“隐藏”数据将在运行 grep 时显示。

标签： byte jpeg

【解决方案1】：

您应该阅读JFIF file format specifications

【讨论】：

虽然阅读这大大增加了我对 JPEG FIF 的理解 - 我真的不明白那里的任何东西可以用来解决我的问题吗？除非你的意思是第一个 0xFF 0xD9 是因为缩略图的结尾，所以我可以检查缩略图是否存在，如果存在，则运行该函数两次？
其实我的链接错了。我认为搜索字节序列是绝对错误的，它可能位于原始数据的中间。您应该知道字节代表什么，解码标头并提取原始数据的大小。
解码标题绝对是一个不错的方法，但我找不到任何（包括你发给我的）关于文件长度的标题值。或者任何推断它的方法。
是的，在 W3C 的网站上有一个 JPEG 常见问题解答（我找不到链接）
老问题，我知道，但对于任何人来说：JPEG FAQ Part1 和 JPEG FAQ Part2

【解决方案2】：

嗯，文件中总有两个地方可以 100% 可靠地找到。开始和结束。因此，当您添加隐藏文件时，添加 另一个 4 个字节来存储文件的原始长度和始终不同的特殊签名。回读时，首先寻找到结尾 - 8 并阅读该长度和签名。然后就去找那个位置。

【讨论】：

是的，我正在考虑这样做，我唯一担心的是，对于大图像文件，这将不起作用。而且我知道图像必须是 4GB（如果我的数学是正确的）这不起作用，但我想避免这种做法？并不是说我为了避免它而去了更好的地方，我想......
好吧，那就用 8 个字节，__int64。

【解决方案3】：

你应该阅读我对这个问题“Detect Eof for JPG images”的回答。

【讨论】：

【解决方案4】：

您可能会遇到标题中的缩略图，当您浏览文件时，您应该会发现大多数标记的片段都包含一个长度指示符，here 是哪个可以做和哪个不可以做的参考。您可以跳过这些段中的字节，因为真正的 eoi 标记不会在其中。

在实际的 jpeg 压缩数据中，任何 FF 字节后面都应该跟着 00（然后丢弃零字节），或者用 FE 来标记注释（它有一个长度指示符，并且可以如上所述跳过） .
理论上，在压缩数据中遇到错误 eoi 读数的唯一方法是在评论中。

【讨论】：