时间戳

首页 > 解决方案 > 如何手动读取 zip 文件头

zip - 如何手动读取 zip 文件头

问题描述

我有一个文件，其中丢失了非常重要的 java 项目源代码。这是一个精灵文件。当我用编辑器打开它时，大部分内容是不可读的，但完整的 java 项目似乎作为未压缩的 zip 文件夹嵌入到具有文件夹结构和所有内容的文件中（不要问我为什么。我只是试图取回信息我不是负责任的）。

elf 文件中的相关信息片段如下所示：

PK
  Üi‰L§½kQ   Q   9   file/path/i/cant/show/contenttext
content
content

因为我不知道 zip 文件夹从哪里开始以及在哪里结束，并且因为所有内容都未压缩，所以我的想法是编写一个小脚本来从 elf 文件中抓取并从中创建完整的 javaproject。

为此，我想要标题中的文件名长度，因此很容易知道文件名结束的位置，结束文件内容的开始。

这PK Üi‰L§½kQ Q 9 似乎是 zipfile 的文件头。我将它转换为十六进制，它看起来像这样：504B03040A2020082020DC69894CA71E BD6B512020205120202039202020 我尝试使用来自wikipedia的信息对其进行格式化：

504B0304 //sig (this showed me i did something right)
0A20 // version
2008 // generalpurpose flag
2020 // compression method
DC69 // File last modification time 
894C // File last modification date 
A71EBD6B //CRC-32 of uncompressed data 
51202020 //Compressed size (or 0xffffffff for ZIP64) 
51202020 //Uncompressed size (or 0xffffffff for ZIP64) 
3920  //File name length (n) 
2020 //Extra field length (m)

和字节序开关：

04034B50 //sig
200A // version
0820 // generalpurpose flag
2020 // compression method
69DC // File last modification time 
4C89 // File last modification date 
6BBD1EA7 //CRC-32 of uncompressed data 
20202051 //Compressed size (or 0xffffffff for ZIP64) 
20202051 //Uncompressed size (or 0xffffffff for ZIP64) 
2039  //File name length (n) 
2020 //Extra field length (m)

但似乎有些不对劲。文件头的长度是正确的（30 个字节加上文件名），数字似乎在正确的位置有信息，但2020应该0000用于压缩。对我来说，转换为十六进制似乎只对了一半。我必须改变什么才能获得正确的数字？

标签： zipunzip

解决方案

我发现了我的错误。奇怪的 2020 而不是 0000 的问题是我的错误。我在 notepadd++ 中打开文件，将有趣的部分复制到一个新文件中，并将它们转换为十六进制。我认为复制改变了数据。当我直接在 hexeditor 中打开文件时，zipefile 标头就可以了。

推荐阅读