什么文件格式有这种魔力 Header？
What File Format Has This Magic Header?
我有一堆文件，从元数据中我可以看出它们应该是 PDF。其中一些确实是完整的 PDF。其中一些似乎是 PDF 文件的第一部分，尽管它们缺少 %%EOF 和其他页脚值。
其他似乎是 PDF 文件的最后一部分（它们没有任何 PDF 的 header，但它们确实有 %%EOF 内容）。奇怪的是，它们以以下 16 字节魔法开始 header:
0x50, 0x4B, 0x57, 0x41, 0x52, 0x45, 0x00, 0x00, 0x00, 0x00, 0x00, 0x57, 0x49, 0x4E, 0x33, 0x32 (PKWARE WIN32).
我正在做很多可能会产生误导的推论，但它似乎不是压缩方案（%%EOF 的东西是明文）并且在我去过的几个文件中允许深入观察从这个魔法开始和看起来像 PDF 二进制文件的最后一段之间存在相关性。
有没有人对此处可能使用的文件格式有任何提示？
更新：我现在观察到 PKWARE WIN32 也发生在 non-PDF 文件上。推测还表明这些文件以类似的方式拆分。
更新2：原来这个PKWARE WIN32 header实际上是重复出现的，其位置可以通过紧接在前的一些字节来预测header.
我还收到了一些间接的传闻，这些传闻表明这些文件被压缩并且没有分成多个部分，尽管在我被告知输出文件大小的 3 个案例中有 2 个是我的二进制文件小得可以忽略不计。
谜团还在继续。
好吧，这最终变成了一种非常奇怪的格式。总的来说，这是一种压缩方案，但它的应用不一致，并且以一种混淆问题的方式轻轻包裹。
这些文件中的任何一个的前 8 个字节都将以其自身的魔法开始，接下来的 8 个字节可以作为 long 读取，以告诉我们输出文件的最终大小。
然后是一个 16 字节的“部分”（四个整数），其第一个数字只是一个增量计数器，其第二个 int 表示直到下一个“部分”中断的字节数，其第三个 int 有点像对我来说是个谜，它的第四个 int 不是 0 就是 1。如果那个 int 是 0，只读下一个（不管多少）字节 as-is。它们是有效载荷。
如果它是 1，那么接下来您将获得这些 PKWARE header 之一。老实说，我知道如何解释它们 least-well 除了它们以原始问题中的魔法开头并且它们总共有 42 个字节长。
如果您有 PKWARE header，请从要读取的字节数中减去 42，然后使用 PKWARE 的“内爆”算法将剩余字节视为已压缩字节。这意味着您可以使用 zlib 的“分解”实现来解压缩它们。
遍历文件，将所有这些 header 考虑在内，并将压缩和未压缩的部分拼凑在一起，直到 运行 超出字节，最终得到输出文件。
我不知道为什么只有部分文件被压缩，也不知道为什么它们被分成这样的块，但它似乎适用于我拥有的有限样本数据。也许稍后我会发现实际上已经沿着这些边界分割的文件或使用某种花哨的重复数据删除，但至少现在我可以解释为什么它看起来像我看到的部分 PDF——文件只是部分压缩。
我有一堆文件，从元数据中我可以看出它们应该是 PDF。其中一些确实是完整的 PDF。其中一些似乎是 PDF 文件的第一部分，尽管它们缺少 %%EOF 和其他页脚值。
其他似乎是 PDF 文件的最后一部分（它们没有任何 PDF 的 header，但它们确实有 %%EOF 内容）。奇怪的是，它们以以下 16 字节魔法开始 header:
0x50, 0x4B, 0x57, 0x41, 0x52, 0x45, 0x00, 0x00, 0x00, 0x00, 0x00, 0x57, 0x49, 0x4E, 0x33, 0x32 (PKWARE WIN32).
我正在做很多可能会产生误导的推论，但它似乎不是压缩方案（%%EOF 的东西是明文）并且在我去过的几个文件中允许深入观察从这个魔法开始和看起来像 PDF 二进制文件的最后一段之间存在相关性。
有没有人对此处可能使用的文件格式有任何提示？
更新：我现在观察到 PKWARE WIN32 也发生在 non-PDF 文件上。推测还表明这些文件以类似的方式拆分。
更新2：原来这个PKWARE WIN32 header实际上是重复出现的，其位置可以通过紧接在前的一些字节来预测header.
我还收到了一些间接的传闻，这些传闻表明这些文件被压缩并且没有分成多个部分，尽管在我被告知输出文件大小的 3 个案例中有 2 个是我的二进制文件小得可以忽略不计。
谜团还在继续。
好吧，这最终变成了一种非常奇怪的格式。总的来说，这是一种压缩方案，但它的应用不一致，并且以一种混淆问题的方式轻轻包裹。
这些文件中的任何一个的前 8 个字节都将以其自身的魔法开始，接下来的 8 个字节可以作为 long 读取，以告诉我们输出文件的最终大小。
然后是一个 16 字节的“部分”（四个整数），其第一个数字只是一个增量计数器，其第二个 int 表示直到下一个“部分”中断的字节数，其第三个 int 有点像对我来说是个谜，它的第四个 int 不是 0 就是 1。如果那个 int 是 0，只读下一个（不管多少）字节 as-is。它们是有效载荷。
如果它是 1，那么接下来您将获得这些 PKWARE header 之一。老实说，我知道如何解释它们 least-well 除了它们以原始问题中的魔法开头并且它们总共有 42 个字节长。
如果您有 PKWARE header，请从要读取的字节数中减去 42，然后使用 PKWARE 的“内爆”算法将剩余字节视为已压缩字节。这意味着您可以使用 zlib 的“分解”实现来解压缩它们。
遍历文件，将所有这些 header 考虑在内，并将压缩和未压缩的部分拼凑在一起，直到 运行 超出字节，最终得到输出文件。
我不知道为什么只有部分文件被压缩，也不知道为什么它们被分成这样的块，但它似乎适用于我拥有的有限样本数据。也许稍后我会发现实际上已经沿着这些边界分割的文件或使用某种花哨的重复数据删除，但至少现在我可以解释为什么它看起来像我看到的部分 PDF——文件只是部分压缩。