zip - Zip格式的JPG+Zip文件组合问题

Question

希望您听说过 neat hack它允许您将 JPG 和 Zip 文件合并为一个文件，并且它是两种格式的有效(或至少可读)文件。好吧，我意识到由于 JPG 在结尾允许任意内容，而在开头允许 ZIP，因此您可以在其中添加另一种格式 - 在中间。出于这个问题的目的，假设中间数据是保证不与 JPG 或 ZIP 格式冲突的任意二进制数据(意味着它不包含神奇的 zip header 0x04034b50)。插图:

0xFFD8 <- start jpg data end -> 0xFFD9 ... ARBITRARY BINARY DATA ... 0x04034b50 <- start zip file ... EOF

我是这样猫的:

cat "mss_1600.jpg" filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb "null.bytes" "randomzipfile.zip" > temp.zip

这将生成一个 6,318 KB 的文件。它 不在 7-Zip 中打开。但是，当我少一个“双倍”时(而不是 13 个 filea 和 b's，12 个):

cat "mss_1600.jpg" filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb filea fileb "null.bytes" "randomzipfile.zip" > temp.zip

它生成了一个 5,996 KB 的文件 在 7-Zip 中打开。

所以我知道我的任意二进制数据没有神奇的 Zip 文件头来搞砸。我有 working jpg+data+zip 的引用文件和 non-working jpg+data+zip (另存为因为浏览器认为它们是图像，并自己添加 zip 扩展名)。

我想知道为什么它在 13 个组合中失败而在 12 个组合中没有。对于奖励积分，我需要以某种方式解决这个问题。

Answer 1

实际上它真的是一个两部分的答案:)

首先，无论人们怎么说 zip 文件在技术上都不能逐字放在文件的末尾。中央目录记录的结尾有一个值，它表示从当前磁盘开始的字节偏移量(如果您只有一个 .zip 文件，则表示当前文件)。现在很多处理器都忽略了这一点，尽管 Windows 的 zip 文件夹没有，所以您需要更正该值以使其在 Windows 资源管理器中工作(不是您可能关心的；P)参见 Zip APPNOTE有关文件格式的信息。基本上，您可以在十六进制编辑器(或编写工具)中找到“相对于起始磁盘号的中央目录起始偏移量”值。然后找到第一个“中央文件头签名”(504b0102 的十六进制)并将值设置为该偏移量。

现在唉，这不能修复 7zip，但这是由于 7zip 试图猜测文件格式的方式。基本上它只会搜索二进制序列 504b0304 的第一个 ~4MiB，如果没有找到它，它会假设它不是 Zip 并尝试其他存档格式。这显然就是为什么再添加一个文件会破坏事情的原因，它会超过搜索的限制。

现在要修复它，您需要做的是将该十六进制字符串添加到 jpeg 中而不破坏它。一种方法是在 FFD8 JPEG SOI header 之后添加以下十六进制数据 FFEF0005504B030400 。这会为您的序列添加一个自定义块并且是正确的，因此 jpeg 标题应该忽略它。