binary - 什么文件格式有这个神奇的标题?
问题描述
我有一堆从元数据中可以看出应该是 PDF 的文件。其中一些确实是完整的 PDF。其中一些似乎是 PDF 文件的第一部分,尽管它们缺少 the%%EOF
和其他页脚值。
其他似乎是 PDF 文件的最后一部分(它们没有任何 PDF 的标题,但它们确实有这些%%EOF
东西)。奇怪的是,它们从以下 16 字节的魔术头开始:
0x50, 0x4B, 0x57, 0x41, 0x52, 0x45, 0x00, 0x00, 0x00, 0x00, 0x00, 0x57, 0x49, 0x4E, 0x33, 0x32
( PKWARE WIN32
)。
我做了很多可能会产生误导的推论,但它似乎不是一种压缩方案(这些%%EOF
东西是纯文本的),并且在我被允许深入研究的几个文件中,开始之间存在相关性有了这种魔力,看起来就像 PDF 二进制文件的最后一段。
有人对这里可能使用的文件格式有任何提示吗?
更新:我现在观察到PKWARE WIN32
非 PDF 文件也会发生这种情况。推测还表明这些文件以类似的方式拆分。
更新 2:事实证明,此PKWARE WIN32
标头实际上以重复的间隔出现,其位置可以通过紧接在标头之前的一些字节来预测。
我还收到了一些间接的传闻,这些传闻表明这些文件被压缩并且没有分成多个部分,尽管在 3 个案例中有 2 个告诉我输出文件大小我的二进制文件只小到可以忽略不计。
谜团还在继续。
解决方案
好的,所以这最终成为一种非常奇怪的格式。总的来说,它是一种压缩方案,但它的应用不一致,并且以一种混淆问题的方式轻轻包裹。
任何这些文件的前 8 个字节都会以它自己的魔法开始,接下来的 8 个字节可以读取为 long 来告诉我们输出文件的最终大小。
然后有一个 16 字节的“节”(四个整数),其第一个数字只是一个增量计数器,其第二个整数表示直到下一个“节”中断的字节数,其第三个整数对我来说有点神秘,并且其第四个 int 为 0 或 1。如果该 int 为 0,则按原样读取下一个(无论多少)字节。它们是有效载荷。
如果它是 1,那么接下来您将获得这些PKWARE
标题之一。老实说,我知道如何以最差的方式解释它们,而不是从原始问题中的魔法开始,它们总共有 42 个字节长。
如果您有 PKWARE 标头,请从要读取的字节数中减去 42,然后使用 PKWARE 的“内爆”算法将剩余字节视为压缩。这意味着您可以使用 zlib 的“explode”实现来解压缩它们。
遍历文件并考虑所有这些标头并将压缩和未压缩的部分拼凑在一起,直到用完字节并最终得到输出文件。
我不知道为什么只有部分文件被压缩,也不知道为什么它们被分成这样的块,但它似乎适用于我拥有的有限样本数据。也许稍后我会发现实际上已经沿着这些边界分割的文件,或者采用了某种奇特的重复数据删除,但至少现在我可以解释为什么它看起来像我看到了部分 PDF——这些文件只是部分压缩了。
推荐阅读
- tkinter - 如何将窗口应用程序 python/tkinter 放置在屏幕上的特定位置?
- google-bigquery - 如何从 bigquery 中的另一个表中获取短语列表的表字段中的匹配计数?
- jenkins - 詹金斯是否有一个选项可以通过传递一个键从控制台输出中找到一个特定的值并将其发布到松弛通道中?
- angular - 在 HTML(角度组件)上使用 setter 和 getter 变量
- python - python3 rpy2 ggplot2 组合多个数据帧图
- c - 点(图表)。使用顶点和边缘位置进行序列化
- docker - 尝试设置运行器时,安装在 Kubernetes 上的 Gitlab 运行器未显示在 Gitlab UI 中
- windows-10 - Logstash 不产生输出或插入弹性搜索
- sql - 列出从事“计算机化”项目的所有员工的姓氏、薪水和部门名称
- angular - 为什么以下“路线”构造有效?