zip文档碎片恢复工具

hco168 · 发表于 2012-6-18 10:25:58

H-ZIP Recovery v1.4.rar (2.55 MB, 下载次数: 108)

此工具非破解版  只能当作研究碎片参考工具

由于新版office采用zip类型对修复office2007 2010 很有用

参考档：
A.  Local file header:

      local file header signature    4 bytes  (0x04034b50)
      version needed to extract    2 bytes
      general purpose bit flag       2 bytes
      compression method             2 bytes
      last mod file time             2 bytes
      last mod file date             2 bytes
      crc-32                         4 bytes
      compressed size                4 bytes
      uncompressed size             4 bytes
      file name length             2 bytes
      extra field length             2 bytes

      file name (variable size)
      extra field (variable size)

  B.  File data

   Immediately following the local header for a file
   is the compressed or stored data for the file.
   The series of [local file header][file data][data
   descriptor] repeats for each file in the .ZIP archive.

  C.  Data descriptor:

      crc-32                         4 bytes
      compressed size                4 bytes
      uncompressed size             4 bytes

   This descriptor exists only if bit 3 of the general
   purpose bit flag is set (see below).  It is byte aligned
   and immediately follows the last byte of compressed data.
   This descriptor is used only when it was not possible to
   seek in the output .ZIP file, e.g., when the output .ZIP file
   was standard output or a non-seekable device.  For ZIP64(tm) format
   archives, the compressed and uncompressed sizes are 8 bytes each.

   When compressing files, compressed and uncompressed sizes
   should be stored in ZIP64 format (as 8 byte values) when a
   files size exceeds 0xFFFFFFFF. However ZIP64 format may be
   used regardless of the size of a file.  When extracting, if
   the zip64 extended information extra field is present for
   the file the compressed and uncompressed sizes will be 8
   byte values.

   Although not originally assigned a signature, the value
   0x08074b50 has commonly been adopted as a signature value
   for the data descriptor record.  Implementers should be
   aware that ZIP files may be encountered with or without this
   signature marking data descriptors and should account for
   either case when reading ZIP files to ensure compatibility.
   When writing ZIP files, it is recommended to include the
   signature value marking the data descriptor record.  When
   the signature is used, the fields currently defined for
   the data descriptor record will immediately follow the
   signature.

   An extensible data descriptor will be released in a future
   version of this APPNOTE.  This new record is intended to
   resolve conflicts with the use of this record going forward,
   and to provide better support for streamed file processing.

   When the Central Directory Encryption method is used, the data
   descriptor record is not required, but may be used.  If present,
   and bit 3 of the general purpose bit field is set to indicate
   its presence, the values in fields of the data descriptor
   record should be set to binary zeros.

  D.  Archive decryption header:

   The Archive Decryption Header is introduced in version 6.2
   of the ZIP format specification.  This record exists in support
   of the Central Directory Encryption Feature implemented as part of
   the Strong Encryption Specification as described in this document.
   When the Central Directory Structure is encrypted, this decryption
   header will precede the encrypted data segment.  The encrypted
   data segment will consist of the Archive extra data record (if
   present) and the encrypted Central Directory Structure data.
   The format of this data record is identical to the Decryption
   header record preceding compressed file data.  If the central
   directory structure is encrypted, the location of the start of
   this data record is determined using the Start of Central Directory
   field in the Zip64 End of Central Directory record.  Refer to the
   section on the Strong Encryption Specification for information
   on the fields used in the Archive Decryption Header record.

  E.  Archive extra data record:

      archive extra data signature 4 bytes  (0x08064b50)
      extra field length             4 bytes
      extra field data             (variable size)

   The Archive Extra Data Record is introduced in version 6.2
   of the ZIP format specification.  This record exists in support
   of the Central Directory Encryption Feature implemented as part of
   the Strong Encryption Specification as described in this document.
   When present, this record immediately precedes the central
   directory data structure.  The size of this data record will be
   included in the Size of the Central Directory field in the
   End of Central Directory record.  If the central directory structure
   is compressed, but not encrypted, the location of the start of
   this data record is determined using the Start of Central Directory
   field in the Zip64 End of Central Directory record.

  F.  Central directory structure:

   [file header 1]
   .
   .
   .
   [file header n]
   [digital signature]

   File header:

      central file header signature 4 bytes  (0x02014b50)
      version made by                2 bytes
      version needed to extract    2 bytes
      general purpose bit flag       2 bytes
      compression method             2 bytes
      last mod file time             2 bytes
      last mod file date             2 bytes
      crc-32                         4 bytes
      compressed size                4 bytes
      uncompressed size             4 bytes
      file name length             2 bytes
      extra field length             2 bytes
      file comment length          2 bytes
      disk number start             2 bytes
      internal file attributes       2 bytes
      external file attributes       4 bytes
      relative offset of local header 4 bytes

      file name (variable size)
      extra field (variable size)
      file comment (variable size)

   Digital signature:

      header signature             4 bytes  (0x05054b50)
      size of data                   2 bytes
      signature data (variable size)

   With the introduction of the Central Directory Encryption
   feature in version 6.2 of this specification, the Central
   Directory Structure may be stored both compressed and encrypted.
   Although not required, it is assumed when encrypting the
   Central Directory Structure, that it will be compressed
   for greater storage efficiency.  Information on the
   Central Directory Encryption feature can be found in the section
   describing the Strong Encryption Specification. The Digital
   Signature record will be neither compressed nor encrypted.

  G.  Zip64 end of central directory record

      zip64 end of central dir
      signature                      4 bytes  (0x06064b50)
      size of zip64 end of central
      directory record             8 bytes
      version made by                2 bytes
      version needed to extract    2 bytes
      number of this disk          4 bytes
      number of the disk with the
      start of the central directory  4 bytes
      total number of entries in the
      central directory on this disk  8 bytes
      total number of entries in the
      central directory             8 bytes
      size of the central directory 8 bytes
      offset of start of central
      directory with respect to
      the starting disk number       8 bytes
      zip64 extensible data sector (variable size)

      The value stored into the "size of zip64 end of central
      directory record" should be the size of the remaining
      record and should not include the leading 12 bytes.

      Size = SizeOfFixedFields + SizeOfVariableData - 12.

      The above record structure defines Version 1 of the
      zip64 end of central directory record. Version 1 was
      implemented in versions of this specification preceding
      6.2 in support of the ZIP64 large file feature. The
      introduction of the Central Directory Encryption feature
      implemented in version 6.2 as part of the Strong Encryption
      Specification defines Version 2 of this record structure.
      Refer to the section describing the Strong Encryption
      Specification for details on the version 2 format for
      this record.

      Special purpose data may reside in the zip64 extensible data
      sector field following either a V1 or V2 version of this
      record.  To ensure identification of this special purpose data
      it must include an identifying header block consisting of the
      following:

         Header ID  -  2 bytes
         Data Size  -  4 bytes

      The Header ID field indicates the type of data that is in the
      data block that follows.

      Data Size identifies the number of bytes that follow for this
      data block type.

      Multiple special purpose data blocks may be present, but each
      must be preceded by a Header ID and Data Size field.  Current
      mappings of Header ID values supported in this field are as
      defined in APPENDIX C.

  H.  Zip64 end of central directory locator

      zip64 end of central dir locator
      signature                      4 bytes  (0x07064b50)
      number of the disk with the
      start of the zip64 end of
      central directory             4 bytes
      relative offset of the zip64
      end of central directory record 8 bytes
      total number of disks          4 bytes

  I.  End of central directory record:

      end of central dir signature 4 bytes  (0x06054b50)
      number of this disk          2 bytes
      number of the disk with the
      start of the central directory  2 bytes
      total number of entries in the
      central directory on this disk  2 bytes
      total number of entries in
      the central directory          2 bytes
      size of the central directory 4 bytes
      offset of start of central
      directory with respect to
      the starting disk number       4 bytes
      .ZIP file comment length       2 bytes
      .ZIP file comment    (variable size)

  J.  Explanation of fields:

   version made by (2 bytes)

      The upper byte indicates the compatibility of the file
      attribute information.  If the external file attributes
      are compatible with MS-DOS and can be read by PKZIP for
      DOS version 2.04g then this value will be zero.  If these
      attributes are not compatible, then this value will
      identify the host system on which the attributes are
      compatible.  Software can use this information to determine
      the line record format for text files etc.  The current
      mappings are:

      0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
      1 - Amiga                   2 - OpenVMS
      3 - UNIX                   4 - VM/CMS
      5 - Atari ST                6 - OS/2 H.P.F.S.
      7 - Macintosh                8 - Z-System
      9 - CP/M                   10 - Windows NTFS
      11 - MVS (OS/390 - Z/OS)    12 - VSE
      13 - Acorn Risc             14 - VFAT
      15 - alternate MVS          16 - BeOS
      17 - Tandem                18 - OS/400
      19 - OS/X (Darwin)          20 thru 255 - unused

      The lower byte indicates the ZIP specification version
      (the version of this document) supported by the software
      used to encode the file.  The value/10 indicates the major
      version number, and the value mod 10 is the minor version
      number.

   version needed to extract (2 bytes)

      The minimum supported ZIP specification version needed to
      extract the file, mapped as above.  This value is based on
      the specific format features a ZIP program must support to
      be able to extract the file.  If multiple features are
      applied to a file, the minimum version should be set to the
      feature having the highest value. New features or feature
      changes affecting the published format specification will be
      implemented using higher version numbers than the last
      published value to avoid conflict.

      Current minimum feature versions are as defined below:

      1.0 - Default value
      1.1 - File is a volume label
      2.0 - File is a folder (directory)
      2.0 - File is compressed using Deflate compression
      2.0 - File is encrypted using traditional PKWARE encryption
      2.1 - File is compressed using Deflate64(tm)
      2.5 - File is compressed using PKWARE DCL Implode
      2.7 - File is a patch data set
      4.5 - File uses ZIP64 format extensions
      4.6 - File is compressed using BZIP2 compression*
      5.0 - File is encrypted using DES
      5.0 - File is encrypted using 3DES
      5.0 - File is encrypted using original RC2 encryption
      5.0 - File is encrypted using RC4 encryption
      5.1 - File is encrypted using AES encryption
      5.1 - File is encrypted using corrected RC2 encryption**
      5.2 - File is encrypted using corrected RC2-64 encryption**
      6.1 - File is encrypted using non-OAEP key wrapping***
      6.2 - Central directory encryption
      6.3 - File is compressed using LZMA
      6.3 - File is compressed using PPMd+
      6.3 - File is encrypted using Blowfish
      6.3 - File is encrypted using Twofish