appnote.txt

来自「SharpZipLib之前叫做NZipLib」· 文本 代码 · 共 1,467 行 · 第 1/5 页

          file. The local-header and central-header versions are identical.

          Value         Size        Description
          -----         ----        -----------
  (Mac2b) 0x2705        Short       tag for this extra block type
          TSize         Short       total data size for this block (12)
          "ZPIT"        beLong      extra-field signature
          FileType      Byte[4]     four-byte Mac file type string
          Creator       Byte[4]     four-byte Mac creator string
          fdFlags       beShort     attributes from FInfo.frFlags,
                                    may be omitted
          0x0000        beShort     reserved, may be omitted


         -ZipIt Macintosh Extra Field (short, for directories) (0x2805):

          The following is the layout of a shortened variant of the
          ZipIt extra block for Macintosh used only for directory
          entries. This variant is used by ZipIt 1.3.5 and newer to 
          save some optional Mac-specific information about directories.
          The local-header and central-header versions are identical.

          Value         Size        Description
          -----         ----        -----------
  (Mac2c) 0x2805        Short       tag for this extra block type
          TSize         Short       total data size for this block (12)
          "ZPIT"        beLong      extra-field signature
          frFlags       beShort     attributes from DInfo.frFlags, may
                                    be omitted
          View          beShort     ZipIt view flag, may be omitted


          The View field specifies ZipIt-internal settings as follows:

          Bits of the Flags:
              bit 0           if set, the folder is shown expanded (open)
                              when the archive contents are viewed in ZipIt.
              bits 1-15       reserved, zero;


         -FWKCS MD5 Extra Field (0x4b46):

          The FWKCS Contents_Signature System, used in
          automatically identifying files independent of file name,
          optionally adds and uses an extra field to support the
          rapid creation of an enhanced contents_signature:

              Header ID = 0x4b46
              Data Size = 0x0013
              Preface   = 'M','D','5'
              followed by 16 bytes containing the uncompressed file's
              128_bit MD5 hash(1), low byte first.

          When FWKCS revises a .ZIP file central directory to add
          this extra field for a file, it also replaces the
          central directory entry for that file's uncompressed
          file length with a measured value.

          FWKCS provides an option to strip this extra field, if
          present, from a .ZIP file central directory. In adding
          this extra field, FWKCS preserves .ZIP file Authenticity
          Verification; if stripping this extra field, FWKCS
          preserves all versions of AV through PKZIP version 2.04g.

          FWKCS, and FWKCS Contents_Signature System, are
          trademarks of Frederick W. Kantor.

          (1) R. Rivest, RFC1321.TXT, MIT Laboratory for Computer
              Science and RSA Data Security, Inc., April 1992.
              ll.76-77: "The MD5 algorithm is being placed in the
              public domain for review and possible adoption as a
              standard."

         -Microsoft Open Packaging Growth Hint (0xa220):

          Value         Size        Description
          -----         ----        -----------
          0xa220        Short       tag for this extra block type
          TSize         Short       size of Sig + PadVal + Padding
          Sig           Short       verification signature (A028)
          PadVal        Short       Initial padding value
          Padding       variable    filled with NULL characters


      file comment: (Variable)

          The comment for this file.

      number of this disk: (2 bytes)

          The number of this disk, which contains central
          directory end record. If an archive is in ZIP64 format
          and the value in this field is 0xFFFF, the size will 
          be in the corresponding 4 byte zip64 end of central 
          directory field.


      number of the disk with the start of the central
      directory: (2 bytes)

          The number of the disk on which the central
          directory starts. If an archive is in ZIP64 format
          and the value in this field is 0xFFFF, the size will 
          be in the corresponding 4 byte zip64 end of central 
          directory field.

      total number of entries in the central dir on 
      this disk: (2 bytes)

          The number of central directory entries on this disk.
          If an archive is in ZIP64 format and the value in 
          this field is 0xFFFF, the size will be in the 
          corresponding 8 byte zip64 end of central 
          directory field.

      total number of entries in the central dir: (2 bytes)

          The total number of files in the .ZIP file. If an 
          archive is in ZIP64 format and the value in this field
          is 0xFFFF, the size will be in the corresponding 8 byte 
          zip64 end of central directory field.

      size of the central directory: (4 bytes)

          The size (in bytes) of the entire central directory.
          If an archive is in ZIP64 format and the value in 
          this field is 0xFFFFFFFF, the size will be in the 
          corresponding 8 byte zip64 end of central 
          directory field.

      offset of start of central directory with respect to
      the starting disk number:  (4 bytes)

          Offset of the start of the central directory on the
          disk on which the central directory starts. If an 
          archive is in ZIP64 format and the value in this 
          field is 0xFFFFFFFF, the size will be in the 
          corresponding 8 byte zip64 end of central 
          directory field.

      .ZIP file comment length: (2 bytes)

          The length of the comment for this .ZIP file.

      .ZIP file comment: (Variable)

          The comment for this .ZIP file.  ZIP file comment data
          is stored unsecured.  No encryption or data authentication
          is applied to this area at this time.  Confidential information
          should not be stored in this section.

      zip64 extensible data sector    (variable size)

          (currently reserved for use by PKWARE)


  K.  Splitting and Spanning ZIP files

          Spanning is the process of segmenting a ZIP file across 
          multiple removable media. This support has typically only 
          been provided for DOS formatted floppy diskettes. 

          File splitting is a newer derivative of spanning.  
          Splitting follows the same segmentation process as
          spanning, however, it does not require writing each
          segment to a unique removable medium and instead supports
          placing all pieces onto local or non-removable locations
          such as file systems, local drives, folders, etc...

          A key difference between spanned and split ZIP files is
          that all pieces of a spanned ZIP file have the same name.  
          Since each piece is written to a separate volume, no name 
          collisions occur and each segment can reuse the original 
          .ZIP file name given to the archive.

          Sequence ordering for DOS spanned archives uses the DOS 
          volume label to determine segment numbers.  Volume labels
          for each segment are written using the form PKBACK#xxx, 
          where xxx is the segment number written as a decimal 
          value from 001 - nnn.

          Split ZIP files are typically written to the same location
          and are subject to name collisions if the spanned name
          format is used since each segment will reside on the same 
          drive. To avoid name collisions, split archives are named 
          as follows.

          Segment 1   = filename.z01
          Segment n-1 = filename.z(n-1)
          Segment n   = filename.zip

          The .ZIP extension is used on the last segment to support
          quickly reading the central directory.  The segment number
          n should be a decimal value.

          Spanned ZIP files may be PKSFX Self-extracting ZIP files.
          PKSFX files may also be split, however, in this case
          the first segment must be named filename.exe.  The first
          segment of a split PKSFX archive must be large enough to
          include the entire executable program.

          Capacities for split archives are as follows.

          Maximum number of segments = 4,294,967,295 - 1
          Maximum .ZIP segment size = 4,294,967,295 bytes
          Minimum segment size = 64K
          Maximum PKSFX segment size = 2,147,483,647 bytes
          
          Segment sizes may be different however by convention, all 
          segment sizes should be the same with the exception of the 
          last, which may be smaller.  Local and central directory 
          header records must never be split across a segment boundary. 
          When writing a header record, if the number of bytes remaining 
          within a segment is less than the size of the header record,
          end the current segment and write the header at the start
          of the next segment.  The central directory may span segment
          boundaries, but no single record in the central directory
          should be split across segments.

          Spanned/Split archives created using PKZIP for Windows
          (V2.50 or greater), PKZIP Command Line (V2.50 or greater),
          or PKZIP Explorer will include a special spanning 
          signature as the first 4 bytes of the first segment of
          the archive.  This signature (0x08074b50) will be 
          followed immediately by the local header signature for
          the first file in the archive.  

          A special spanning marker may also appear in spanned/split 
          archives if the spanning or splitting process starts but 
          only requires one segment.  In this case the 0x08074b50 
          signature will be replaced with the temporary spanning 
          marker signature of 0x30304b50.  Split archives can
          only be uncompressed by other versions of PKZIP that
          know how to create a split archive.

          The signature value 0x08074b50 is also used by some
          ZIP implementations as a marker for the Data Descriptor 
          record.  Conflict in this alternate assignment can be
          avoided by ensuring the position of the signature
          within the ZIP file to determine the use for which it
          is intended.  

  L.  General notes:

      1)  All fields unless otherwise noted are unsigned and stored
          in Intel low-byte:high-byte, low-word:high-word order.

      2)  String fields are not null terminated, since the
          length is given explicitly.

      3)  The entries in the central directory may not necessarily
          be in the same order that files appear in the .ZIP file.

      4)  If one of the fields in the end of central directory
          record is too small to hold required data, the field
          should be set to -1 (0xFFFF or 0xFFFFFFFF) and the
          ZIP64 format record should be created.

      5)  The end of central directory record and the
          Zip64 end of central directory locator record must
          reside on the same disk when splitting or spanning
          an archive.

VI. UnShrinking - Method 1
--------------------------

Shrinking is a Dynamic Ziv-Lempel-Welch compression algorithm
with partial clearing.  The initial code size is 9 bits, and
the maximum code size is 13 bits.  Shrinking differs from
conventional Dynamic Ziv-Lempel-Welch implementations in several
respects:

1)  The code size is controlled by the compressor, and is not
    automatically increased when codes larger than the current
    code size are created (but not necessarily used).  When
    the decompressor encounters the code sequence 256
    (decimal) followed by 1, it should increase the code size
    read from the input stream to the next bit size.  No
    blocking of the codes is performed, so the next code at
    the increased size should be read from the input stream
    immediately after where the previous code at the smaller
    bit size was read.  Again, the decompressor should not
    increase the code size used until the sequence 256,1 is
    encountered.

2)  When the table becomes full, total clearing is not
    performed.  Rather, when the compressor emits the code
    sequence 256,2 (decimal), the decompressor should clear
    all leaf nodes from the Ziv-Lempel tree, and continue to
    use the current code size.  The nodes that are cleared
    from the Ziv-Lempel tree are then re-