diff --git a/docs/aes_coding_tips.txt b/docs/aes_coding_tips.txt
deleted file mode 100644
index 052864a..0000000
--- a/docs/aes_coding_tips.txt
+++ /dev/null
@@ -1,253 +0,0 @@
-AES Coding Tips for Developers
-
-NOTE: WinZip^(R) users do not need to read or understand the information
-contained on this page. It is intended for developers of Zip file utilities.
-
-This document contains information that may be helpful to developers and other
-interested parties who wish to support the AE-1 and AE-2 AES encryption formats
-in their own Zip file utilities. WinZip Computing makes no warranties regarding
-the information provided in this document. In particular, WinZip Computing does
-not represent or warrant that the information provided here is free from errors
-or is suitable for any particular use, or that the file formats described here
-will be supported in future versions of WinZip. You should test and validate
-all code and techniques in accordance with good programming practice.
-
-This information supplements the basic encryption specification document found
-here.
-
-This document assumes that you are using Dr. Brian Gladman's AES encryption
-package. Dr. Gladman has generously made public a sample application that
-demonstrates the use of his encryption/decryption and other routines, and the
-code samples shown below are derived from this sample application. Dr.
-Gladman's AES library and the sample application are available from the AES
-project page on Dr. Gladman's web site.
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Generating a salt value
-
-Please read the discussion of salt values in the encryption specification.
-
-Dr. Gladman has provided a pseudo-random number generator in the files PRNG.C
-and PRNG.H. You may find this suitable for generating salt values. These files
-are included in the sample package available through the AES project page on
-Dr. Gladman's web site.
-
-Here are guidelines for using Dr. Gladman's generator. Note that the generator
-is used rather like an I/O stream: it is opened (initialized), used, and
-finally closed. To obtain the best results, it is recommended that you
-initialize the generator when your application starts and close it when your
-application closes. (If you are coding in C++, you may wish to wrap these
-actions in a C++ class that initializes the generator on construction and
-closes it on destruction.)
-
- 1. You will need to provide an entropy function in your code for
-    initialization of the generator. The entropy function need not be
-    particularly sophisticated for this use. Here is one possibility for such a
-    function, based primarily upon the Windows performance counter:
-
-    int entropy_fun(
-     unsigned char buf[],
-     unsigned int len)
-        {
-        unsigned __int64 pentium_tsc[1];
-        unsigned int     i;
-        static unsigned int num = 0;
-        // this sample code returns the following sequence of entropy information
-        // - the current 8-byte Windows performance counter value
-        // - an 8-byte representation of the current date/time
-        // - an 8-byte value built from the current process ID and thread ID
-        // - all subsequent calls return the then-current 8-byte performance
-        //      counter value
-        switch (num)
-            {
-        case 1:
-            ++num;
-            // use a value that is unlikely to repeat across system reboots
-            GetSystemTimeAsFileTime((FILETIME *)pentium_tsc);
-            break;
-        case 2:
-            ++num;
-            {
-            // use a value that distinguishes between different instances of this
-            // code that might be running on different processors at the same time
-            unsigned __int32 processtest = GetCurrentProcessId();
-            unsigned __int32 threadtest = GetCurrentThreadId();
-            pentium_tsc[0] = processtest;
-            pentium_tsc[0] = (pentium_tsc[0] << 32) + threadtest;
-            }
-            break;
-        case 0:
-            ++num;
-            // fall through to default case
-        default:
-            // use a rapidly-changing value
-            //  Note: check QueryPerformanceFrequency() first to
-            //  ensure that QueryPerformanceCounter() will work.
-            QueryPerformanceCounter((LARGE_INTEGER *)pentium_tsc);
-            break;
-            }
-        for(i = 0; i < 8 && i < len; ++i)
-            buf[i] = ((unsigned char*)pentium_tsc)[i];
-        return i;
-        }
-
-    Note: the required prototype for the entropy function is defined in PRNG.H.
-
- 2. Initialize the generator by calling prng_init(), providing the addresses of
-    your entropy function and of an instance of a prng_ctx structure (defined
-    in PRNG.H). The prng_ctx variable maintains a context for the generator and
-    is used as a parameter for the other generator functions. Therefore, the
-    variable's state must be maintained until the generator is closed.
-
-    prng_ctx ctx;
-    prng_init(entropy_fun, &ctx);
-
-    You only need to do this once per application session (as long as you keep
-    the "stream" open).
-
- 3. To obtain a sequence of random bytes of arbitrary size, use prng_rand().
-    This code obtains 16 random bytes, suitable for use as a salt value for
-    256-bit AES encryption:
-
-    unsigned char buffer[16];
-    prng_rand(buffer, sizeof(buffer), &ctx);
-
-    Note that the ctx parameter is the same prng_ctx variable that was used in
-    the initialization call.
-
- 4. When you are done with the generator (this would normally be when your
-    application closes), close it by calling prng_end:
-
-    prng_end(&ctx);
-
-    Again, the ctx parameter is the same prng_ctx variable that was used in the
-    initialization call.
-
-Encryption and decryption
-
-The actual encryption and decryption of data are handled quite similarly, and
-again are rather stream-like: a stream is "opened", data is passed to it for
-encryption or decryption, and then it is closed. The password verifier is
-returned when the stream is opened, and the authentication code is returned
-when the stream is closed.
-
-Here is the basic technique:
-
- 1. Initialize the "stream" for encryption or decryption and obtain the
-    password verification value.
-
-    There is no difference in the initialization, regardless of whether you are
-    encrypting or decrypting:
-
-    fcrypt_ctx zctx;     // the encryption context
-    int rc = fcrypt_init(
-      KeySize,       // extra data value indicating key size
-      pszPassword,     // the password
-      strlen(pszPassword), // number of bytes in password
-      achSALT,       // the salt
-      achPswdVerifier,   // on return contains password verifier
-      &zctx);       // encryption context
-
-    The return value is 0 if the initialization was successful; non-zero values
-    indicate errors. Note that passwords are null-terminated ANSI strings;
-    embedded nulls must not be used. (To avoid incompatibilities between the
-    various character sets in use, especially in different versions of Windows,
-    users should be encouraged to use passwords containing only the "standard"
-    characters in the range 32-127.)
-
-    The function returns the password verification value in achPswdVerifier,
-    which must be a 2-byte buffer. If you are encrypting, store this value in
-    the Zip file as indicated by the encryption specification. If you are
-    decrypting, compare this returned value to the value stored in the Zip
-    file. If they are different, then either the password provided by your user
-    was incorrect or the encrypted file has been altered in some way since it
-    was encrypted. (Note that if they match, there is still a 1 in 65,536
-    chance that an incorrect password was provided.)
-
-    The initialized encryption context (zctx) is used as a parameter to the
-    encryption/decryption functions. Therefore, its state must be maintained
-    until the "stream" is closed.
-
- 2. Encrypt or decrypt the data.
-
-    To encrypt:
-
-    fcrypt_encrypt(
-      pchData, // pointer to the data to encrypt
-      cb,   // how many bytes to encrypt
-      &zctx); // encryption context
-
-    To decrypt:
-
-    fcrypt_decrypt(
-      pchData, // pointer to the data to decrypt
-      cb,   // how many bytes to decrypt
-      &zctx); // decryption context
-
-    You may need to call the encrypt or decrypt function multiple times,
-    passing in successive chunks of data in the buffer. For AE-1 and AE-2
-    compatibility, the buffer size must be a multiple of 16 bytes except for
-    the last buffer, which may be smaller. For efficiency, a larger buffer size
-    such as 32,768 would generally be used.
-
-    Note: to encrypt zero-length files, simply skip this step. You will still
-    obtain and use the password verifier (step 1) and authentication code (step
-    3).
-
- 3. Close the "stream" and obtain the authentication code.
-
-    When encryption/decryption is complete, close the "stream" as follows:
-
-    int rc = fcrypt_end(
-      achMAC, // on return contains the authentication code
-      &zctx); // encryption context
-
-    The return value is the size of the authentication code, which will always
-    be 10 for AE-1 and AE-2. The authentication code itself is returned in your
-    buffer at achMAC, which is an array of char, sized to hold at least 10
-    characters. If you are encrypting, store this value in the Zip file as
-    indicated by the encryption specification; if you are decrypting, compare
-    this value to the value stored in the Zip file. If the values are
-    different, either the password is incorrect or the encrypted data has been
-    altered subsequent to storage.
-
-    Note that decryption can fail even if the encrypted data is unaltered and
-    the password verifier was correct in step 1. The password verifier is
-    useful as a quick way to detect most incorrect passwords, but it is not
-    perfect and on rare occasions (1 out of 65,536) it will fail to detect an
-    incorrect password. It is therefore important for you to check the
-    authentication code on completion even though the password verifier was
-    correct.
-
-Notes
-
-  • Dr. Gladman's AES code depends on the byte order (little-endian or
-    big-endian) used by the computing platform the code will run on. This is
-    determined by a C preprocessor constant called PLATFORM_BYTE_ORDER, which
-    is defined in the file AESOPT.H. You should be sure that
-    PLATFORM_BYTE_ORDER gets the proper value for your platform; if it does
-    not, you will need to define it yourself to the correct value. When using
-    the Microsoft compiler on Intel platforms it does get the proper value,
-    which on these platforms is AES_LITTLE_ENDIAN. We have, however, had a
-    report that it does not default properly when Borland C++ Builder is used,
-    and that manual assignment is necessary. For additional information on this
-    topic, refer to the comments within AESOPT.H.
-
-Change history
-
-Changes made in document version 1.04, July, 2008:
-
- A. Sample Entropy Function
-
-    The sample entropy function was changed to include information near the
-    very beginning of the entropy stream that's unique to the day and to the
-    process and thread.
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Document version: 1.04
-Last modified: July 21, 2008
-
-Copyright(C) 2003-2016 WinZip International LLC.
-All Rights Reserved
diff --git a/docs/aes_info.txt b/docs/aes_info.txt
deleted file mode 100644
index c7995d5..0000000
--- a/docs/aes_info.txt
+++ /dev/null
@@ -1,607 +0,0 @@
-AES Encryption Information:
-Encryption Specification AE-1 and AE-2
-
-Document version: 1.04
-Last modified: January 30, 2009
-
-NOTE: WinZip^(R) users do not need to read or understand the information
-contained on this page. It is intended for developers of Zip file utilities.
-
-Changes since the original version of this document are summarized in the
-Change History section below.
-
-This document describes the file format that WinZip uses to create
-AES-encrypted Zip files. The AE-1 encryption specification was introduced in
-WinZip 9.0 Beta 1, released in May 2003. The AE-2 encryption specification, a
-minor variant of the original AE-1 specification differing only in how the CRC
-is handled, was introduced in WinZip 9.0 Beta 3, released in January, 2004.
-Note that as of WinZip 11, WinZip itself encrypts most files using the AE-1
-format and encrypts others using the AE-2 format.
-
-From time to time we may update the information provided here, for example to
-document any changes to the file formats, or to add additional notes or
-implementation tips. If you would like to receive e-mail announcements of any
-substantive changes we make to this document, you can sign up below for our
-Developer Information mailing list.
-
-Without compromising the basic Zip file format, WinZip Computing has extended
-the format specification to support AES encryption, and this document fully
-describes the format extension. Additionally, we are providing information
-about a no-cost third-party source for the actual AES encryption code--the same
-code that is used by WinZip. We believe that use of the free encryption code
-and of this specification will make it easy for all developers to add
-compatible advanced encryption to their Zip file utilities.
-
-This document is not a tutorial on encryption or Zip file structure. While we
-have attempted to provide the necessary details of the current WinZip AES
-encryption format, developers and other interested third parties will need to
-have or obtain an understanding of basic encryption concepts, Zip file format,
-etc.
-
-Developers should also review AES Coding Tips page.
-
-WinZip Computing makes no warranties regarding the information provided in this
-document. In particular, WinZip Computing does not represent or warrant that
-the information provided here is free from errors or is suitable for any
-particular use, or that the file formats described here will be supported in
-future versions of WinZip. You should test and validate all code and techniques
-in accordance with good programming practice.
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Contents
-
- I. Encryption services
-II. Zip file format
-     A. Base format reference
-     B. Compression method and encryption flag
-     C. CRC value
-     D. AES extra data field
-III. Encrypted file storage format
-     A. File format
-     B. Salt value
-     C. Password verification value
-     D. Encrypted file data
-     E. Authentication code
-IV. Changes in WinZip 11
- V. Notes
-     A. Non-files and zero-length files
-     B. "Mixed" Zip files
-     C. Key generation
-VI. FAQs
-VII. Change history
-VIII. Mailing list signup
-
-
-I. Encryption services
-
-To perform AES encryption and decryption, WinZip uses AES functions written by
-Dr. Brian Gladman. The source code for these functions is available in C/C++
-and Pentium family assembler for anyone to use under an open source BSD or GPL
-license from the AES project page on Dr. Gladman's web site. The AES Coding
-Tips page also has some information on the use of these functions. WinZip
-Computing thanks Dr. Gladman for making his AES functions available to anyone
-under liberal license terms.
-
-Dr. Gladman's encryption functions are portable to a number of operating
-systems and can be static linked into your applications, so there are no
-operating system version or library dependencies. In particular, the functions
-do not require Microsoft's Cryptography API.
-
-General information on the AES standard and the encryption algorithm (also
-known as Rijndael) is readily available on the Internet. A good place to start
-is http://www.nist.gov/public_affairs/releases/g00-176.htm.
-
-II. Zip file format
-
- A. Base format reference
-
-    AES-encrypted files are stored within the guidelines of the standard Zip
-    file format using only a new "extra data" field, a new compression method
-    code, and a value in the CRC field dependant on the encryption version,
-    AE-1 or AE-2. The basic Zip file format is otherwise unchanged.
-
-    WinZip sets the version needed to extract and version made by fields in the
-    local and central headers to the same values it would use if the file were
-    not encrypted.
-
-    The basic Zip file format specification used by WinZip is available via FTP
-    from the Info-ZIP group at ftp://ftp.info-zip.org/pub/infozip/doc/
-    appnote-iz-latest.zip.
-
- B. Compression method and encryption flag
-
-    As for any encrypted file, bit 0 of the "general purpose bit flags" field
-    must be set to 1 in each AES-encrypted file's local header and central
-    directory entry.
-
-    Additionally, the presence of an AES-encrypted file in a Zip file is
-    indicated by a new compression method code (decimal 99) in the file's local
-    header and central directory entry, used along with the AES extra data
-    field described below. There is no change in either the version made by or
-    version needed to extract codes.
-
-    The code for the actual compression method is stored in the AES extra data
-    field (see below).
-
- C. CRC value
-
-    For files encrypted using the AE-2 method, the standard Zip CRC value is
-    not used, and a 0 must be stored in this field. Corruption of encrypted
-    data within a Zip file is instead detected via the authentication code
-    field.
-
-    Files encrypted using the AE-1 method do include the standard Zip CRC
-    value. This, along with the fact that the vendor version stored in the AES
-    extra data field is 0x0001 for AE-1 and 0x0002 for AE-2, is the only
-    difference between the AE-1 and AE-2 formats.
-
-    NOTE: Zip utilities that support the AE-2 format are required to be able to
-    read files that were created in the AE-1 format, and during decryption/
-    extraction of files in AE-1 format should verify that the file's CRC
-    matches the value stored in the CRC field.
-
- D. AES extra data field
-     1. A file encrypted with AES encryption will have a special "extra data"
-        field associated with it. This extra data field is stored in both the
-        local header and central directory entry for the file.
-
-        Note: see the Zip file format document referenced above for general
-        information on the format and use of extra data fields.
-
-     2. The extra data header ID for AES encryption is 0x9901. The fields are
-        all stored in Intel low-byte/high-byte order. The extra data field
-        currently has a length of 11: seven data bytes plus two bytes for the
-        header ID and two bytes for the data size. Therefore, the extra data
-        overhead for each file in the archive is 22 bytes (11 bytes in the
-        central header plus 11 bytes in the local header).
-     3. The format of the data in the AES extra data field is as follows. See
-        the notes below for additional information.
-
-        Offset Size(bytes) Content
-
-        0      2           Extra field header ID (0x9901)
-
-        2      2           Data size (currently 7, but subject
-                           to possible increase in the future)
-
-        4      2           Integer version number specific to
-                           the zip vendor
-
-        6      2           2-character vendor ID
-
-        8      1           Integer mode value indicating AES
-                           encryption strength
-
-        9      2           The actual compression method used to
-                           compress the file
-
-     4. Notes
-          ☆ Data size: this value is currently 7, but because it is possible
-            that this specification will be modified in the future to store
-            additional data in this extra field, vendors should not assume that
-            it will always remain 7.
-          ☆ Vendor ID: the vendor ID field should always be set to the two
-            ASCII characters "AE".
-          ☆ Vendor version: the vendor version for AE-1 is 0x0001. The vendor
-            version for AE-2 is 0x0002.
-
-            Zip utilities that support AE-2 must also be able to process files
-            that are encrypted in AE-1 format. The handling of the CRC value is
-            the only difference between the AE-1 and AE-2 formats.
-
-          ☆ Encryption strength: the mode values (encryption strength) for AE-1
-            and AE-2 are:
-
-            Value Strength
-
-            0x01  128-bit encryption key
-
-            0x02  192-bit encryption key
-
-            0x03  256-bit encryption key
-
-            The encryption specification supports only 128-, 192-, and 256-bit
-            encryption keys. No other key lengths are permitted.
-
-            (Note: the current version of WinZip does not support encrypting
-            files using 192-bit keys. This specification, however, does provide
-            for the use of 192-bit keys, and WinZip is able to decrypt such
-            files.)
-
-          ☆ Compression method: the compression method is the one that would
-            otherwise have been stored in the local and central headers for the
-            file. For example, if the file is imploded, this field will contain
-            the compression code 6. This is needed because a compression method
-            of 99 is used to indicate the presence of an AES-encrypted file
-            (see above).
-
-III. Encrypted file storage format
-
- A. File format
-
-    Additional overhead data required for decryption is stored with the
-    encrypted file itself (i.e., not in the headers). The actual format of the
-    stored file is as follows; additional information about these fields is
-    below. All fields are byte-aligned.
-
-    Size     Content
-    (bytes)
-
-    Variable Salt value
-
-    2        Password verification value
-
-    Variable Encrypted file data
-
-    10       Authentication code
-
-    Note that the value in the "compressed size" fields of the local file
-    header and the central directory entry is the total size of all the items
-    listed above. In other words, it is the total size of the salt value,
-    password verification value, encrypted data, and authentication code.
-
- B. Salt value
-
-    The "salt" or "salt value" is a random or pseudo-random sequence of bytes
-    that is combined with the encryption password to create encryption and
-    authentication keys. The salt is generated by the encrypting application
-    and is stored unencrypted with the file data. The addition of salt values
-    to passwords provides a number of security benefits and makes dictionary
-    attacks based on precomputed keys much more difficult.
-
-    Good cryptographic practice requires that a different salt value be used
-    for each of multiple files encrypted with the same password. If two files
-    are encrypted with the same password and salt, they can leak information
-    about each other. For example, it is possible to determine whether two
-    files encrypted with the same password and salt are identical, and an
-    attacker who somehow already knows the contents of one of two files
-    encrypted with the same password and salt can determine some or all of the
-    contents of the other file. Therefore, you should make every effort to use
-    a unique salt value for each file.
-
-    The size of the salt value depends on the length of the encryption key, as
-    follows:
-
-    Key size Salt size
-
-    128 bits 8 bytes
-
-    192 bits 12 bytes
-
-    256 bits 16 bytes
-
- C. Password verification value
-
-    This two-byte value is produced as part of the process that derives the
-    encryption and decryption keys from the password. When encrypting, a
-    verification value is derived from the encryption password and stored with
-    the encrypted file. Before decrypting, a verification value can be derived
-    from the decryption password and compared to the value stored with the
-    file, serving as a quick check that will detect most, but not all,
-    incorrect passwords. There is a 1 in 65,536 chance that an incorrect
-    password will yield a matching verification value; therefore, a matching
-    verification value cannot be absolutely relied on to indicate a correct
-    password.
-
-    Information on how to obtain the password verification value from Dr.
-    Gladman's encryption library can be found on the coding tips page.
-
-    This value is stored unencrypted.
-
- D. Encrypted file data
-
-    Encryption is applied only to the content of files. It is performed after
-    compression, and not to any other associated data. The file data is
-    encrypted byte-for-byte using the AES encryption algorithm operating in
-    "CTR" mode, which means that the lengths of the compressed data and the
-    compressed, encrypted data are the same.
-
-    It is important for implementors to note that, although the data is
-    encrypted byte-for-byte, it is presented to the encryption and decryption
-    functions in blocks. The block size used for encryption and decryption must
-    be the same. To be compatible with the encryption specification, this block
-    size must be 16 bytes (although the last block may be smaller).
-
- E. Authentication code
-
-    Authentication provides a high quality check that the contents of an
-    encrypted file have not been inadvertently changed or deliberately tampered
-    with since they were first encrypted. In effect, this is a super-CRC check
-    on the data in the file after compression and encryption. (Additionally,
-    authentication is essential when using CTR mode encryption because this
-    mode is vulnerable to several trivial attacks in its absence.)
-
-    The authentication code is derived from the output of the encryption
-    process. Dr. Gladman's AES code provides this service, and information
-    about how to obtain it is in the coding tips.
-
-    The authentication code is stored unencrypted. It is byte-aligned and
-    immediately follows the last byte of encrypted data.
-
-    For more discussion about authentication, see the authentication code FAQ
-    below.
-
-IV. Changes in WinZip 11
-
-Beginning with WinZip 11, WinZip makes a change in its use of the AE-1 and AE-2
-file formats. The file formats themselves have not changed, and AES-encrypted
-files created by WinZip 11 are completely compatible with version 1.02 the
-WinZip AES encryption specification, which was published in January 2004.
-
-WinZip 9.0 and WinZip 10.0 stored all AES-encrypted files using the AE-2 file
-format, which does not store the encrypted file's CRC. WinZip 11 instead uses
-the AE-1 file format, which does store the CRC, for most files. This provides
-an extra integrity check against the possibility of hardware or software errors
-that occur during the actual process of file compression/encryption or
-decryption/decompression. For more information on this point, see the
-discussion of the CRC below.
-
-Because for some very small files the CRC can be used to determine the exact
-contents of a file, regardless of the encryption method used, WinZip 11
-continues to use the AE-2 file format, with no CRC stored, for files with an
-uncompressed size of less than 20 bytes. WinZip 11 also uses the AE-2 file
-format for files compressed in BZIP2 format, because the BZIP2 format contains
-its own integrity checks equivalent to those provided by the Zip format's CRC.
-
-Other vendors who support WinZip's AES encryption specification may want to
-consider making a similar change to their own implementations of the
-specification, to get the benefit of the extra integrity check that it
-provides.
-
-Note that the January 2004 version of the WinZip AE-2 specification, version
-1.0.2, already required that all utilities that implemented the AE-2 format
-also be able to process files in AE-1 format, and should check on decryption/
-extraction of those files that the CRC was correct.
-
-V. Notes
-
- A. Non-files and zero-length files
-
-    To reduce Zip file size, it is recommended that non-file entries such as
-    folder/directory entries not be encrypted. This, however, is only a
-    recommendation; it is permissible to encrypt or not encrypt these entries,
-    as you prefer.
-
-    On the other hand, it is recommended that you do encrypt zero-length files.
-    The presence of both encrypted and unencrypted files in a Zip file may
-    trigger user warnings in some Zip file utilities, so the user experience
-    may be improved if all files (including zero-length files) are encrypted.
-
-    If zero-length files are encrypted, the encrypted data portion of the file
-    storage (see above) will be empty, but the remainder of the encryption
-    overhead data must be present, both in the file storage area and in the
-    local and central headers.
-
- B. "Mixed" Zip files
-
-    There is no requirement that all files in a Zip file be encrypted or that
-    all files that are encrypted use the same encryption method or the same
-    password.
-
-    A Zip file can contain any combination of unencrypted files and files
-    encrypted with any of the four currently defined encryption methods (Zip
-    2.0, AES-128, AES-192, AES-256). Encrypted files may use the same password
-    or different passwords.
-
- C. Key Generation
-
-    Key derivation, as used by AE-1 and AE-2 and as implemented in Dr.
-    Gladman's library, is done according to the PBKDF2 algorithm, which is
-    described in the RFC2898 guidelines. An iteration count of 1000 is used. An
-    appropriate number of bits from the resulting hash value are used to
-    compose three output values: an encryption key, an authentication key, and
-    a password verification value. The first n bits become the encryption key,
-    the next m bits become the authentication key, and the last 16 bits (two
-    bytes) become the password verification value.
-
-    As part of the process outlined in RFC 2898 a pseudo-random function must
-    be called; AE-2 uses the HMAC-SHA1 function, since it is a well-respected
-    algorithm that has been in wide use for this purpose for several years.
-
-    Note that, when used in connection with 192- or 256-bit AES encryption, the
-    fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the
-    password that you specify, the search space for the encryption key is
-    unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be
-    guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the
-    RFC2898 specification.
-
-VI. FAQs
-
-  • Why is the compression method field used to indicate AES encryption?
-
-    As opposed to using new version made by and version needed to extract
-    values to signal AES encryption for a file, the new compression method is
-    more likely to be handled gracefully by older versions of existing Zip file
-    utilities. Zip file utilities typically do not attempt to extract files
-    compressed with unknown methods, presumably notifying the user with an
-    appropriate message.
-
-  • How can I guarantee that the salt value is unique?
-
-    In principle, the value of the salt should be different whenever the same
-    password is used more than once, for the reasons described above, but this
-    is difficult to guarantee.
-
-    In practice, the number of bytes in the salt (as specified by AE-1 and
-    AE-2) is such that using a pseudo-random value will ensure that the
-    probability of duplicated salt values is very low and can be safely
-    ignored.
-
-    There is one exception to this: With the 8-byte salt values used with
-    WinZip's 128-bit encryption it is likely that, if approximately 4 billion
-    files are encrypted with the same password, two of the files will have the
-    same salt, so it is advisable to stay well below this limit. Because of
-    this, when using the same password to encrypt very large numbers of files
-    in WinZip's AES encryption format (that is, files totalling in the
-    millions, for example 2000 Zip files, each containing 1000 encrypted
-    files), we recommend the use of 192-bit or 256-bit AES keys, with their 12-
-    and 16-byte salt values, rather than 128-bit AES keys, with their 8-byte
-    salt values.
-
-    Although salt values do not need to be truly random, it is important that
-    they be generated in a way that the probability of duplicated salt values
-    is not significantly higher than that which would be expected if truly
-    random values were being used.
-
-    One technique for generating salt values is presented in the coding tips
-    page.
-
-  • Why is there an authentication code?
-
-    The purpose of the authentication code is to insure that, once a file's
-    data has been compressed and encrypted, any accidental corruption of the
-    encrypted data, and any deliberate attempts to modify the encrypted data by
-    an attacker who does not know the password, can be detected.
-
-    The current consensus in the cryptographic community is that associating a
-    message authentication code (or MAC) with encrypted data has strong
-    security value because it makes a number of attacks more difficult to
-    engineer. For AES CTR mode encryption in particular, a MAC is especially
-    important because a number of trivial attacks are possible in its absence.
-    The MAC used with WinZip's AES encryption is based on HMAC-SHA1-80, a
-    mature and widely respected authentication algorithm.
-
-    The MAC is calculated after the file data has been compressed and
-    encrypted. This order of calculation is referred to as Encrypt-then-MAC,
-    and is preferred by many cryptographers to the alternative order of
-    MAC-then-Encrypt because Encrypt-then-MAC is immune to some known attacks
-    on MAC-then-Encrypt.
-
-  • What is the role of the CRC in WinZip 11?
-
-    Within the Zip format, the primary use of the CRC value is to detect
-    accidental corruption of data that has been stored in the Zip file. With
-    files encrypted according to the Zip 2.0 encryption specification, it also
-    functions to some extent as a method of detecting deliberate attempts to
-    modify the encrypted data, but not one that can be considered
-    cryptographically strong. The CRC is not needed for these purposes with the
-    WinZip AES encryption specification, where the HMAC-SHA1-based
-    authentication code instead serves these roles.
-
-    The CRC has a drawback in that for very small files, such as files with
-    four or fewer bytes, the CRC can be used, independent of the encryption
-    algorithm, to determine the unencrypted contents of the file. And, in
-    general, it is preferable to store as little information as possible about
-    the encrypted file in the unencrypted Zip headers.
-
-    The CRC does serve one purpose that the authentication code does not. The
-    CRC is computed based on the original uncompressed, unencrypted contents of
-    the file, and it is checked after the file has been decrypted and
-    decompressed. In contrast, the authentication code used with WinZip AES
-    encryption is computed after compression/encryption and it is checked
-    before decryption/decompression. In the very rare event of a hardware or
-    software error that corrupts data during compression and encryption, or
-    during decryption and decompression, the CRC will catch the error, but the
-    authentication code will not.
-
-    WinZip 9.0 and WinZip 10.0 used AE-2 for all files that they created, and
-    did not store the CRC. As of WinZip 11, WinZip instead uses AE-1 for most
-    files, storing the CRC as an additional integrity check against hardware or
-    software errors occurring during the actual compression/encryption or
-    decryption/decompression processes. WinZip 11 will continue to use AE-2,
-    with no CRC, for very small files of less than 20 bytes. It will also use
-    AE-2 for files compressed in BZIP2 format, because this format has internal
-    integrity checks equivalent to a CRC check built in.
-
-    Note that the AES-encrypted files created by WinZip 11 are fully compatible
-    with January 2004's version 1.0.2 of the WinZip AES encryption
-    specification, in which both the AE-1 and AE-2 variants of the file format
-    were already defined.
-
-VII. Change history
-
-Changes made in document version 1.04, January, 2009: Minor clarification
-regarding the algorithm used to generate the authentication code.
-
-Changes made in document version 1.03, November, 2006: Minor editorial and
-clarifying changes have been made throughout the document. The following
-substantive technical changes have been made:
-
- A. WinZip 11 Usage of AE-1 and AE-2
-
-    WinZip's AES encryption specification defines two formats, known as AE-1
-    and AE-2, which differ in whether the CRC of the encrypted file is stored
-    in the Zip headers. While the file formats themselves remain unchanged,
-    WinZip's usage of them is changing. Beginning with WinZip 11, WinZip uses
-    the AE-1 format, which includes the CRC of the encrypted file, for many
-    encrypted files, in order to provide an additional integrity check against
-    hardware or software errors occurring during the compression/encryption or
-    decryption/decompression processes. Note that AES-encrypted files created
-    by WinZip 11 are completely compatible with the previous version of the
-    WinZip encryption specification, January 2004's version 1.0.2.
-
- B. The discussion of salt values mentions a limitation that applies to the
-    uniqueness of salt values when very large numbers of files are encrypted
-    with 128-bit encryption.
- C. Older versions of this specification suggested that other vendors might
-    want to use their own vendor IDs to create their own unique encryption
-    formats. We no longer suggest that vendor-specific alternative encryption
-    methods be created in this way.
-
-Changes made in document version 1.02, January, 2004: The introductory text at
-the start of the document has been rewritten, and minor editorial and
-clarifying changes have been made throughout the document. Two substantive
-technical changes have been made:
-
- A. AE-2 Specification
-
-    Standard Zip files store the CRC of each file's unencrypted data. This
-    value is used to help detect damage or other alterations to Zip files.
-    However, storing the CRC value has a drawback in that, for a very small
-    file, such as a file of four or fewer bytes, the CRC value can be used,
-    independent of the encryption algorithm, to help determine the unencrypted
-    contents of the file.
-
-    Because of this, files encrypted with the new AE-2 method store a 0 in the
-    CRC field of the Zip header, and use the authentication code instead of the
-    CRC value to verify that encrypted data within the Zip file has not been
-    corrupted.
-
-    The only differences between the AE-1 and AE-2 methods are the storage in
-    AE-2 of 0 instead of the CRC in the Zip file header,and the use in the AES
-    extra data field of 0x0002 for AE-2 instead of 0x0001 for AE-1 as the
-    vendor version.
-
-    Zip utilities that support the AE-2 format are required to be able to read
-    files that were created in the AE-1 format, and during decryption/
-    extraction of files in AE-1 format should verify that the file's CRC
-    matches the value stored in the CRC field.
-
- B. Key Generation and HMAC-SHA1
-
-    The description of the key generation mechanism has been updated to point
-    out a limitation arising from its use of HMAC-SHA1 as the pseudo-random
-    function: When used in connection with 192- or 256-bit AES encryption, the
-    fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the
-    password that you specify, the search space for the encryption key is
-    unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be
-    guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the
-    RFC2898 specification.
-
-VII. Developer Information Mailing List Signup
-
-We plan to use this mailing list to notify subscribers of any substantive
-changes made to the Developer Information pages on the WinZip web site.
-
-
-
-   If you enter your e-mail address above, you will receive a message
-   asking you to confirm your wish to be added to the mailing list. If you
-   don't reply to the confirmation message, you will not be added to the
-   list.
-
-   By subscribing to this complimentary mailing list service, you
-   acknowledge and agree that WinZip Computing makes no representations
-   regarding the completeness or accuracy of the information provided
-   through the service, and that this service may be discontinued, in whole
-   or in part, with respect to any or all subscribers at any time.
-   * E-mail Address:
-     [                    ]   [Submit to Support] [Clear Form]
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Document version: 1.04
-Last modified: January 30, 2009
-
-Copyright(C) 2003-2015 WinZip International LLC.
-All Rights Reserved
diff --git a/docs/appnote.iz b/docs/appnote.iz
deleted file mode 100644
index eed5663..0000000
--- a/docs/appnote.iz
+++ /dev/null
@@ -1,3686 +0,0 @@
-[Info-ZIP note, 20040528:  this file is based on PKWARE's appnote.txt of
- 15 February 1996, taking into account PKWARE's revised appnote.txt
- version 6.2.0 of 26 April 2004.  It has been unofficially corrected
- and extended by Info-ZIP without explicit permission by PKWARE.
- Although Info-ZIP believes the information to be accurate and complete,
- it is provided under a disclaimer similar to the PKWARE disclaimer below,
- differing only in the substitution of "Info-ZIP" for "PKWARE".  In other
- words, use this information at your own risk, but we think it's correct.
-
- Specification info from PKWARE that was obviously wrong has been corrected
- silently (e.g. missing structure fields, wrong numbers).
- As of PKZIPW 2.50, two new incompatibilities have been introduced by PKWARE;
- they are noted below.  Note that the "NTFS tag" conflict is currently not
- real; PKZIPW 2.50 actually tags NTFS files as having come from a FAT
- file system, too.]
-
-File:    APPNOTE.TXT - .ZIP File Format Specification
-Version: 6.2.0 - NOTIFICATION OF CHANGE
-Revised: 04/26/2004 [2004-05-28 Info-ZIP]
-Copyright (c) 1989 - 2004 PKWARE Inc., All Rights Reserved.
-
-I. Purpose
-----------
-
-This specification is intended to define a cross-platform,
-interoperable file format.  Since its first publication
-in 1989, PKWARE has remained committed to ensuring the
-interoperability of the .ZIP file format through this
-specification.  We trust that all .ZIP compatible vendors
-and application developers that have adopted this format
-will share and support this commitment.
-
-
-II. Disclaimer
---------------
-
-Although PKWARE will attempt to supply current and accurate
-information relating to its file formats, algorithms, and the
-subject programs, the possibility of error or omission can not
-be eliminated. PKWARE therefore expressly disclaims any warranty
-that the information contained in the associated materials relating
-to the subject programs and/or the format of the files created or
-accessed by the subject programs and/or the algorithms used by
-the subject programs, or any other matter, is current, correct or
-accurate as delivered.  Any risk of damage due to any possible
-inaccurate information is assumed by the user of the information.
-Furthermore, the information relating to the subject programs
-and/or the file formats created or accessed by the subject
-programs and/or the algorithms used by the subject programs is
-subject to change without notice.
-
-If the version of this file is marked as a NOTIFICATION OF CHANGE,
-the content defines an Early Feature Specification (EFS) change
-to the .ZIP file format that may be subject to modification prior
-to publication of the Final Feature Specification (FFS).  This
-document may also contain information on Planned Feature
-Specifications (PFS) defining recognized future extensions.
-
-
-III. Change Log
----------------
-
-Version       Change Description                      Date
--------       ------------------                     ----------
-5.2           -Single Password Symmetric Encryption  06/02/2003
-               storage
-
-6.1.0         -Smart Card compatibility              01/20/2004
-              -Documentation on certificate storage
-
-6.2.0         -Introduction of Central Directory     04/26/2004
-               Encryption for encrypting metadata
-              -Added OS/X to Version Made By values
-
-
-IV. General Format of a .ZIP file
----------------------------------
-
-  Files stored in arbitrary order.  Large .ZIP files can span multiple
-  diskette media or be split into user-defined segment sizes.  [The
-  minimum user-defined segment size for a split .ZIP file is 64K.
-  (removed by PKWare 2003-06-01)]
-
-  Overall .ZIP file format:
-
-    [local file header 1]
-    [file data 1]
-    [data descriptor 1]
-    .
-    .
-    .
-    [local file header n]
-    [file data n]
-    [data descriptor n]
-    [archive decryption header] (EFS)
-    [archive extra data record] (EFS)
-    [central directory]
-    [zip64 end of central directory record]
-    [zip64 end of central directory locator]
-    [end of central directory record]
-
-
-  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:
-
-      [Info-ZIP discrepancy:
-       The Info-ZIP zip program starts the data descriptor with a 4-byte
-       PK-style signature.  Despite the specification, none of the PKWARE
-       programs supports the data descriptor.  PKZIP 4.0 -fix function
-       (and PKZIPFIX 2.04) ignores the data descriptor info even when bit 3
-       of the general purpose bit flag is set.
-        data descriptor signature       4 bytes  (0x08074b50)
-      ]
-        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 format
-      archives, the compressed and uncompressed sizes are 8 bytes each.
-
-
-  D.  Archive decryption header:  (EFS)
-
-      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: (EFS)
-
-        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 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(tm) 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.
-
-
-  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)
-
-          [PKWARE describes "OS made by" now (since 1998) as follows:
-          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.]
-          The upper byte indicates the host system (OS) for the
-          file.  Software can use this information to determine
-          the line record format for text files etc.  The current
-          mappings are:
-
-          0 - FAT file system (DOS, OS/2, NT)      + PKWARE 2.50+ VFAT, NTFS
-          1 - Amiga
-          2 - OpenVMS
-          3 - Unix
-          4 - VM/CMS
-          5 - Atari ST
-          6 - HPFS file system (OS/2, NT 3.x)
-          7 - Macintosh
-          8 - Z-System
-          9 - CP/M
-          ---------------------------------------------------------------------
-               PKWARE assignment             | Info-ZIP assignment
-          -----------------------------------|---------------------------------
-          10 - Windows NTFS                  | TOPS-20
-               (since PKZIPW 2.50, but       | (assigned Oct-1992,
-                not used by any PKWARE prog) |  no longer used)
-          11 - MVS                           | NTFS file system (WinNT)
-                                             | (actively used by Info-ZIP's
-                                             |  Zip for NT since Sep-1993)
-          12 - VSE                           | SMS/QDOS
-          ---------------------------------------------------------------------
-          13 - Acorn RISC OS
-          14 - VFAT file system (Win95, NT)     [Info-ZIP reservation, unused]
-          15 - MVS [PKWARE describes this assignment as "alternate MVS"]
-          16 - BeOS (BeBox or PowerMac)
-          17 - Tandem
-          18 - OS/400 (IBM)                  | THEOS
-          19 - OS/X (Darwin)
-          20 thru 29 - unused
-          30 - AtheOS/Syllable
-          31 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
-
-
-          * Early 7.x (pre-7.2) versions of PKZIP incorrectly set the
-          version needed to extract for BZIP2 compression to be 50
-          when it should have been 46.
-
-          ** Refer to the section on Strong Encryption Specification
-          for additional information regarding RC2 corrections.
-
-          *** Certificate encryption using non-OAEP key wrapping is the
-          intended mode of operation for all versions beginning with 6.1.
-          Support for OAEP key wrapping should only be used for
-          backward compatibility when sending ZIP files to be opened by
-          versions of PKZIP older than 6.1 (5.0 or 6.0).
-
-          When using ZIP64 extensions, the corresponding value in the
-          Zip64 end of central directory record should also be set.
-          This field currently supports only the value 45 to indicate
-          ZIP64 extensions are present.
-
-      general purpose bit flag: (2 bytes)
-
-          Bit 0: If set, indicates that the file is encrypted.
-
-          (For Method 6 - Imploding)
-          Bit 1: If the compression method used was type 6,
-                 Imploding, then this bit, if set, indicates
-                 an 8K sliding dictionary was used.  If clear,
-                 then a 4K sliding dictionary was used.
-          Bit 2: If the compression method used was type 6,
-                 Imploding, then this bit, if set, indicates
-                 3 Shannon-Fano trees were used to encode the
-                 sliding dictionary output.  If clear, then 2
-                 Shannon-Fano trees were used.
-
-          (For Methods 8 and 9 - Deflating)
-          Bit 2  Bit 1
-            0      0    Normal (-en) compression option was used.
-            0      1    Maximum (-exx/-ex) compression option was used.
-            1      0    Fast (-ef) compression option was used.
-            1      1    Super Fast (-es) compression option was used.
-
-          Note:  Bits 1 and 2 are undefined if the compression
-                 method is any other.
-
-          Bit 3: If this bit is set, the fields crc-32, compressed
-                 size and uncompressed size are set to zero in the
-                 local header.  The correct values are put in the
-                 data descriptor immediately following the compressed
-                 data.  (Note: PKZIP version 2.04g for DOS only
-                 recognizes this bit for method 8 compression, newer
-                 versions of PKZIP recognize this bit for any
-                 compression method.)
-                [Info-ZIP note: This bit was introduced by PKZIP 2.04 for
-                 DOS. In general, this feature can only be reliably used
-                 together with compression methods that allow intrinsic
-                 detection of the "end-of-compressed-data" condition. From
-                 the set of compression methods described in this Zip archive
-                 specification, only "deflate" and "bzip2" fulfill this
-                 requirement.
-                 Especially, the method STORED does not work!
-                 The Info-ZIP tools recognize this bit regardless of the
-                 compression method; but, they rely on correctly set
-                 "compressed size" information in the central directory entry.]
-
-          Bit 4: Reserved for use with method 8, for enhanced
-                 deflating.
-
-          Bit 5: If this bit is set, this indicates that the file is
-                 compressed patched data.  (Note: Requires PKZIP
-                 version 2.70 or greater)
-
-          Bit 6: Strong encryption.  If this bit is set, you should
-                 set the version needed to extract value to at least
-                 50 and you must also set bit 0.  If AES encryption
-                 is used, the version needed to extract value must
-                 be at least 51.
-
-          Bit 7: Currently unused.
-
-          Bit 8: Currently unused.
-
-          Bit 9: Currently unused.
-
-          Bit 10: Currently unused.
-
-          Bit 11: Currently unused.
-
-          Bit 12: Reserved by PKWARE for enhanced compression.
-
-          Bit 13: Used when encrypting the Central Directory to indicate
-                  selected data values in the Local Header are masked to
-                  hide their actual values.  See the section describing
-                  the Strong Encryption Specification for details.
-
-          Bit 14: Reserved by PKWARE.
-
-          Bit 15: Reserved by PKWARE.
-
-      compression method: (2 bytes)
-
-          (see accompanying documentation for algorithm
-          descriptions)
-
-          0 - The file is stored (no compression)
-          1 - The file is Shrunk
-          2 - The file is Reduced with compression factor 1
-          3 - The file is Reduced with compression factor 2
-          4 - The file is Reduced with compression factor 3
-          5 - The file is Reduced with compression factor 4
-          6 - The file is Imploded
-          7 - Reserved for Tokenizing compression algorithm
-          8 - The file is Deflated
-          9 - Enhanced Deflating using Deflate64(tm)
-         10 - PKWARE Data Compression Library Imploding
-         11 - Reserved by PKWARE
-         12 - File is compressed using BZIP2 algorithm
-
-      date and time fields: (2 bytes each)
-
-          The date and time are encoded in standard MS-DOS format.
-          If input came from standard input, the date and time are
-          those at which compression was started for this data.
-          If encrypting the central directory and general purpose bit
-          flag 13 is set indicating masking, the value stored in the
-          Local Header will be zero.
-
-      CRC-32: (4 bytes)
-
-          The CRC-32 algorithm was generously contributed by
-          David Schwaderer and can be found in his excellent
-          book "C Programmers Guide to NetBIOS" published by
-          Howard W. Sams & Co. Inc.  The 'magic number' for
-          the CRC is 0xdebb20e3.  The proper CRC pre and post
-          conditioning is used, meaning that the CRC register
-          is pre-conditioned with all ones (a starting value
-          of 0xffffffff) and the value is post-conditioned by
-          taking the one's complement of the CRC residual.
-          If bit 3 of the general purpose flag is set, this
-          field is set to zero in the local header and the correct
-          value is put in the data descriptor and in the central
-          directory.  If encrypting the central directory and general
-          purpose bit flag 13 is set indicating masking, the value
-          stored in the Local Header will be zero.
-
-      compressed size: (4 bytes)
-      uncompressed size: (4 bytes)
-
-          The size of the file compressed and uncompressed,
-          respectively.  If bit 3 of the general purpose bit flag
-          is set, these fields are set to zero in the local header
-          and the correct values are put in the data descriptor and
-          in the 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 extended information
-          extra field.  If encrypting the central directory and general
-          purpose bit flag 13 is set indicating masking, the value stored
-          for the uncompressed size in the Local Header will be zero.
-
-      file name length: (2 bytes)
-      extra field length: (2 bytes)
-      file comment length: (2 bytes)
-
-          The length of the file name, extra field, and comment
-          fields respectively.  The combined length of any
-          directory record and these three fields should not
-          generally exceed 65,535 bytes.  If input came from standard
-          input, the file name length is set to zero.
-
-         [Info-ZIP note:
-          This feature is not yet supported by any PKWARE version of ZIP
-          (at least not in PKZIP for DOS and PKZIP for Windows/WinNT).
-          The Info-ZIP programs handle standard input differently:
-          If input came from standard input, the filename is set to "-"
-          (length one).]
-
-
-      disk number start: (2 bytes)
-
-          The number of the disk on which this file begins.  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
-          extended information extra field.
-
-      internal file attributes: (2 bytes)
-
-          Bits 1 and 2 are reserved for use by PKWARE.
-
-          The lowest bit of this field indicates, if set, that
-          the file is apparently an ASCII or text file.  If not
-          set, that the file apparently contains binary data.
-          The remaining bits are unused in version 1.0.
-
-          The 0x0002 bit of this field indicates, if set, that a
-          4 byte variable record length control field precedes each
-          logical record indicating the length of the record. This
-          flag is independent of text control characters, and if used
-          in conjunction with text data, includes any control
-          characters in the total length of the record. This value is
-          provided for mainframe data transfer support.
-
-      external file attributes: (4 bytes)
-
-          The mapping of the external attributes is
-          host-system dependent (see 'version made by').  For
-          MS-DOS, the low order byte is the MS-DOS directory
-          attribute byte.  If input came from standard input, this
-          field is set to zero.
-
-      relative offset of local header: (4 bytes)
-
-          This is the offset from the start of the first disk on
-          which this file appears, to where the local header should
-          be found.  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 extended information extra field.
-
-      file name: (Variable)
-
-          The name of the file, with optional relative path.
-          The path stored should not contain a drive or
-          device letter, or a leading slash.  All slashes
-          should be forward slashes '/' as opposed to
-          backwards slashes '\' for compatibility with Amiga
-          and Unix file systems etc.  If input came from standard
-          input, there is no file name field.  If encrypting
-          the central directory and general purpose bit flag 13 is set
-          indicating masking, the file name stored in the Local Header
-          will not be the actual file name.  A masking value consisting
-          of a unique hexadecimal value will be stored.  This value will
-          be sequentially incremented for each file in the archive.  See
-          the section on the Strong Encryption Specification for details
-          on retrieving the encrypted file name.
-         [Info-ZIP discrepancy:
-          If input came from standard input, the file name is set
-          to "-" (without the quotes).
-          As far as we know, the PKWARE specification for "input from
-          stdin" is not supported by PKZIP/PKUNZIP for DOS, OS/2, Windows
-          Windows NT.]
-
-      extra field: (Variable)
-
-          This is for expansion.  If additional information
-          needs to be stored for special needs or for specific
-          platforms, it should be stored here.  Earlier versions
-          of the software can then safely skip this file, and
-          find the next file or header.  This field will be 0
-          length in version 1.0.
-
-          In order to allow different programs and different types
-          of information to be stored in the 'extra' field in .ZIP
-          files, the following structure should be used for all
-          programs storing data in this field:
-
-          header1+data1 + header2+data2 . . .
-
-          Each header should consist of:
-
-            Header ID - 2 bytes
-            Data Size - 2 bytes
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          The Header ID field indicates the type of data that is in
-          the following data block.
-
-          Header ID's of 0 thru 31 are reserved for use by PKWARE.
-          The remaining ID's can be used by third party vendors for
-          proprietary usage.
-
-          The current Header ID mappings defined by PKWARE are:
-
-          0x0001        ZIP64 extended information extra field
-          0x0007        AV Info
-          0x0008        Reserved for future Unicode file name data (PFS)
-          0x0009        OS/2 extended attributes      (also Info-ZIP)
-          0x000a        NTFS (Win9x/WinNT FileTimes)
-          0x000c        OpenVMS                       (also Info-ZIP)
-          0x000d        Unix
-          0x000e        Reserved for file stream and fork descriptors
-          0x000f        Patch Descriptor
-          0x0014        PKCS#7 Store for X.509 Certificates
-          0x0015        X.509 Certificate ID and Signature for
-                        individual file
-          0x0016        X.509 Certificate ID for Central Directory
-          0x0017        Strong Encryption Header
-          0x0018        Record Management Controls
-          0x0019        PKCS#7 Encryption Recipient Certificate List
-          0x0065        IBM S/390 (Z390), AS/400 (I400) attributes
-                        - uncompressed
-          0x0066        Reserved for IBM S/390 (Z390), AS/400 (I400)
-                        attributes - compressed
-
-          The Header ID mappings defined by Info-ZIP and third parties are:
-
-          0x07c8        Info-ZIP Macintosh (old, J. Lee)
-          0x2605        ZipIt Macintosh (first version)
-          0x2705        ZipIt Macintosh v 1.3.5 and newer (w/o full filename)
-          0x2805        ZipIt Macintosh 1.3.5+
-          0x334d        Info-ZIP Macintosh (new, D. Haase's 'Mac3' field)
-          0x4154        Tandem NSK
-          0x4341        Acorn/SparkFS (David Pilling)
-          0x4453        Windows NT security descriptor (binary ACL)
-          0x4704        VM/CMS
-          0x470f        MVS
-          0x4854        Theos, old inofficial port
-          0x4b46        FWKCS MD5 (see below)
-          0x4c41        OS/2 access control list (text ACL)
-          0x4d49        Info-ZIP OpenVMS (obsolete)
-          0x4d63        Macintosh SmartZIP, by Macro Bambini
-          0x4f4c        Xceed original location extra field
-          0x5356        AOS/VS (binary ACL)
-          0x5455        extended timestamp
-          0x554e        Xceed unicode extra field
-          0x5855        Info-ZIP Unix (original; also OS/2, NT, etc.)
-          0x6542        BeOS (BeBox, PowerMac, etc.)
-          0x6854        Theos
-          0x7441        AtheOS (AtheOS/Syllable attributes)
-          0x756e        ASi Unix
-          0x7855        Info-ZIP Unix (new)
-          0xfb4a        SMS/QDOS
-
-          Detailed descriptions of Extra Fields defined by third
-          party mappings will be documented as information on
-          these data structures is made available to PKWARE.
-          PKWARE does not guarantee the accuracy of any published
-          third party data.
-
-          The Data Size field indicates the size of the following
-          data block. Programs can use this value to skip to the
-          next header block, passing over any data blocks that are
-          not of interest.
-
-          Note: As stated above, the size of the entire .ZIP file
-                header, including the file name, comment, and extra
-                field should not exceed 64K in size.
-
-          In case two different programs should appropriate the same
-          Header ID value, it is strongly recommended that each
-          program place a unique signature of at least two bytes in
-          size (and preferably 4 bytes or bigger) at the start of
-          each data area.  Every program should verify that its
-          unique signature is present, in addition to the Header ID
-          value being correct, before assuming that it is a block of
-          known type.
-
-          In the following descriptions, note that "Short" means two bytes,
-          "Long" means four bytes, and "Long-Long" means eight bytes,
-          regardless of their native sizes.  Unless specifically noted, all
-          integer fields should be interpreted as unsigned (non-negative)
-          numbers.
-
-
-         -ZIP64 Extended Information Extra Field (0x0001):
-          ===============================================
-
-          The following is the layout of the ZIP64 extended
-          information "extra" block. If one of the size or
-          offset fields in the Local or Central directory
-          record is too small to hold the required data,
-          a ZIP64 extended information record is created.
-          The order of the fields in the ZIP64 extended
-          information record is fixed, but the fields will
-          only appear if the corresponding Local or Central
-          directory record field is set to 0xFFFF or 0xFFFFFFFF.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value      Size       Description
-          -----      ----       -----------
-  (ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
-          Size       2 bytes    Size of this "extra" block
-          Original
-          Size       8 bytes    Original uncompressed file size
-          Compressed
-          Size       8 bytes    Size of compressed data
-          Relative Header
-          Offset     8 bytes    Offset of local header record
-          Disk Start
-          Number     4 bytes    Number of the disk on which
-                                this file starts
-
-          This entry in the Local header must include BOTH original
-          and compressed file sizes.
-
-
-         -OS/2 Extended Attributes Extra Field (0x0009):
-          =============================================
-
-          The following is the layout of the OS/2 extended attributes "extra"
-          block.  (Last Revision 19960922)
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (OS/2)  0x0009        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed EA data size
-          CType         Short       compression type
-          EACRC         Long        CRC value for uncompressed EA data
-          (var.)        variable    compressed EA data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (OS/2)  0x0009        Short       tag for this extra block type
-          TSize         Short       total data size for this block (4)
-          BSize         Long        size of uncompressed local EA data
-
-          The value of CType is interpreted according to the "compression
-          method" section above; i.e., 0 for stored, 8 for deflated, etc.
-
-          The OS/2 extended attribute structure (FEA2LIST) is
-          compressed and then stored in its entirety within this
-          structure.  There will only ever be one "block" of data in
-          the variable-length field.
-
-
-         -OS/2 Access Control List Extra Field:
-          ====================================
-
-          The following is the layout of the OS/2 ACL extra block.
-          (Last Revision 19960922)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (ACL)   0x4c41        Short       tag for this extra block type ("AL")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed ACL data size
-          CType         Short       compression type
-          EACRC         Long        CRC value for uncompressed ACL data
-          (var.)        variable    compressed ACL data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (ACL)   0x4c41        Short       tag for this extra block type ("AL")
-          TSize         Short       total data size for this block (4)
-          BSize         Long        size of uncompressed local ACL data
-
-          The value of CType is interpreted according to the "compression
-          method" section above; i.e., 0 for stored, 8 for deflated, etc.
-
-          The uncompressed ACL data consist of a text header of the form
-          "ACL1:%hX,%hd\n", where the first field is the OS/2 ACCINFO acc_attr
-          member and the second is acc_count, followed by acc_count strings
-          of the form "%s,%hx\n", where the first field is acl_ugname (user
-          group name) and the second acl_access.  This block type will be
-          extended for other operating systems as needed.
-
-
-         -Windows NT Security Descriptor Extra Field (0x4453):
-          ===================================================
-
-          The following is the layout of the NT Security Descriptor (another
-          type of ACL) extra block.  (Last Revision 19960922)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (SD)    0x4453        Short       tag for this extra block type ("SD")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed SD data size
-          Version       Byte        version of uncompressed SD data format
-          CType         Short       compression type
-          EACRC         Long        CRC value for uncompressed SD data
-          (var.)        variable    compressed SD data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (SD)    0x4453        Short       tag for this extra block type ("SD")
-          TSize         Short       total data size for this block (4)
-          BSize         Long        size of uncompressed local SD data
-
-          The value of CType is interpreted according to the "compression
-          method" section above; i.e., 0 for stored, 8 for deflated, etc.
-          Version specifies how the compressed data are to be interpreted
-          and allows for future expansion of this extra field type.  Currently
-          only version 0 is defined.
-
-          For version 0, the compressed data are to be interpreted as a single
-          valid Windows NT SECURITY_DESCRIPTOR data structure, in self-relative
-          format.
-
-
-         -PKWARE Win95/WinNT Extra Field (0x000a):
-          =======================================
-
-          The following description covers PKWARE's "NTFS" attributes
-          "extra" block, introduced with the release of PKZIP 2.50 for
-          Windows. (Last Revision 20001118)
-
-          (Note: At this time the Mtime, Atime and Ctime values may
-          be used on any WIN32 system.)
-         [Info-ZIP note: In the current implementations, this field has
-          a fixed total data size of 32 bytes and is only stored as local
-          extra field.]
-
-          Value         Size        Description
-          -----         ----        -----------
-  (NTFS)  0x000a        Short       Tag for this "extra" block type
-          TSize         Short       Total Data Size for this block
-          Reserved      Long        for future use
-          Tag1          Short       NTFS attribute tag value #1
-          Size1         Short       Size of attribute #1, in bytes
-          (var.)        SubSize1    Attribute #1 data
-          .
-          .
-          .
-          TagN          Short       NTFS attribute tag value #N
-          SizeN         Short       Size of attribute #N, in bytes
-          (var.)        SubSizeN    Attribute #N data
-
-          For NTFS, values for Tag1 through TagN are as follows:
-          (currently only one set of attributes is defined for NTFS)
-
-          Tag        Size       Description
-          -----      ----       -----------
-          0x0001     2 bytes    Tag for attribute #1
-          Size1      2 bytes    Size of attribute #1, in bytes (24)
-          Mtime      8 bytes    64-bit NTFS file last modification time
-          Atime      8 bytes    64-bit NTFS file last access time
-          Ctime      8 bytes    64-bit NTFS file creation time
-
-          The total length for this block is 28 bytes, resulting in a
-          fixed size value of 32 for the TSize field of the NTFS block.
-
-          The NTFS filetimes are 64-bit unsigned integers, stored in Intel
-          (least significant byte first) byte order. They determine the
-          number of 1.0E-07 seconds (1/10th microseconds!) past WinNT "epoch",
-          which is "01-Jan-1601 00:00:00 UTC".
-
-
-         -PKWARE OpenVMS Extra Field (0x000c):
-          ===================================
-
-          The following is the layout of PKWARE's OpenVMS attributes
-          "extra" block.  (Last Revision 12/17/91)
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (VMS)   0x000c        Short       Tag for this "extra" block type
-          TSize         Short       Total Data Size for this block
-          CRC           Long        32-bit CRC for remainder of the block
-          Tag1          Short       OpenVMS attribute tag value #1
-          Size1         Short       Size of attribute #1, in bytes
-          (var.)        Size1       Attribute #1 data
-          .
-          .
-          .
-          TagN          Short       OpenVMS attribute tage value #N
-          SizeN         Short       Size of attribute #N, in bytes
-          (var.)        SizeN       Attribute #N data
-
-          Rules:
-
-          1. There will be one or more of attributes present, which
-             will each be preceded by the above TagX & SizeX values.
-             These values are identical to the ATR$C_XXXX and
-             ATR$S_XXXX constants which are defined in ATR.H under
-             OpenVMS C.  Neither of these values will ever be zero.
-
-          2. No word alignment or padding is performed.
-
-          3. A well-behaved PKZIP/OpenVMS program should never produce
-             more than one sub-block with the same TagX value.  Also,
-             there will never be more than one "extra" block of type
-             0x000c in a particular directory record.
-
-
-         -Info-ZIP VMS Extra Field:
-          ========================
-
-          The following is the layout of Info-ZIP's VMS attributes extra
-          block for VAX or Alpha AXP.  The local-header and central-header
-          versions are identical.  (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (VMS2)  0x4d49        Short       tag for this extra block type ("JM")
-          TSize         Short       total data size for this block
-          ID            Long        block ID
-          Flags         Short       info bytes
-          BSize         Short       uncompressed block size
-          Reserved      Long        (reserved)
-          (var.)        variable    compressed VMS file-attributes block
-
-          The block ID is one of the following unterminated strings:
-
-                "VFAB"          struct FAB
-                "VALL"          struct XABALL
-                "VFHC"          struct XABFHC
-                "VDAT"          struct XABDAT
-                "VRDT"          struct XABRDT
-                "VPRO"          struct XABPRO
-                "VKEY"          struct XABKEY
-                "VMSV"          version (e.g., "V6.1"; truncated at hyphen)
-                "VNAM"          reserved
-
-          The lower three bits of Flags indicate the compression method.  The
-          currently defined methods are:
-
-                0       stored (not compressed)
-                1       simple "RLE"
-                2       deflated
-
-          The "RLE" method simply replaces zero-valued bytes with zero-valued
-          bits and non-zero-valued bytes with a "1" bit followed by the byte
-          value.
-
-          The variable-length compressed data contains only the data corre-
-          sponding to the indicated structure or string.  Typically multiple
-          VMS2 extra fields are present (each with a unique block type).
-
-
-         -Info-ZIP Macintosh Extra Field:
-          ==============================
-
-          The following is the layout of the (old) Info-ZIP resource-fork extra
-          block for Macintosh.  The local-header and central-header versions
-          are identical.  (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac)   0x07c8        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          "JLEE"        beLong      extra-field signature
-          FInfo         16 bytes    Macintosh FInfo structure
-          CrDat         beLong      HParamBlockRec fileParam.ioFlCrDat
-          MdDat         beLong      HParamBlockRec fileParam.ioFlMdDat
-          Flags         beLong      info bits
-          DirID         beLong      HParamBlockRec fileParam.ioDirID
-          VolName       28 bytes    volume name (optional)
-
-          All fields but the first two are in native Macintosh format
-          (big-endian Motorola order, not little-endian Intel).  The least
-          significant bit of Flags is 1 if the file is a data fork, 0 other-
-          wise.  In addition, if this extra field is present, the filename
-          has an extra 'd' or 'r' appended to indicate data fork or resource
-          fork.  The 28-byte VolName field may be omitted.
-
-
-         -ZipIt Macintosh Extra Field (long):
-          ==================================
-
-          The following is the layout of the ZipIt extra block for Macintosh.
-          The local-header and central-header versions are identical.
-          (Last Revision 19970130)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac2)  0x2605        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          "ZPIT"        beLong      extra-field signature
-          FnLen         Byte        length of FileName
-          FileName      variable    full Macintosh filename
-          FileType      Byte[4]     four-byte Mac file type string
-          Creator       Byte[4]     four-byte Mac creator string
-
-
-         -ZipIt Macintosh Extra Field (short, for files):
-          ==============================================
-
-          The following is the layout of a shortened variant of the
-          ZipIt extra block for Macintosh (without "full name" entry).
-          This variant is used by ZipIt 1.3.5 and newer for entries of
-          files (not directories) that do not have a MacBinary encoded
-          file.  The local-header and central-header versions are identical.
-          (Last Revision 20030602)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac2b) 0x2705        Short       tag for this extra block type
-          TSize         Short       total data size for this block (min. 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):
-          ====================================================
-
-          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;
-
-
-         -Info-ZIP Macintosh Extra Field (new):
-          ====================================
-
-          The following is the layout of the (new) Info-ZIP extra
-          block for Macintosh, designed by Dirk Haase.
-          All values are in little-endian.
-          (Last Revision 19981005)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac3)  0x334d        Short       tag for this extra block type ("M3")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed finder attribute data size
-          Flags         Short       info bits
-          fdType        Byte[4]     Type of the File (4-byte string)
-          fdCreator     Byte[4]     Creator of the File (4-byte string)
-          (CType)       Short       compression type
-          (CRC)         Long        CRC value for uncompressed MacOS data
-          Attribs       variable    finder attribute data (see below)
-
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac3)  0x334d        Short       tag for this extra block type ("M3")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed finder attribute data size
-          Flags         Short       info bits
-          fdType        Byte[4]     Type of the File (4-byte string)
-          fdCreator     Byte[4]     Creator of the File (4-byte string)
-
-          The third bit of Flags in both headers indicates whether
-          the LOCAL extra field is uncompressed (and therefore whether CType
-          and CRC are omitted):
-
-          Bits of the Flags:
-              bit 0           if set, file is a data fork; otherwise unset
-              bit 1           if set, filename will be not changed
-              bit 2           if set, Attribs is uncompressed (no CType, CRC)
-              bit 3           if set, date and times are in 64 bit
-                              if zero date and times are in 32 bit.
-              bit 4           if set, timezone offsets fields for the native
-                              Mac times are omitted (UTC support deactivated)
-              bits 5-15       reserved;
-
-
-          Attributes:
-
-          Attribs is a Mac-specific block of data in little-endian format with
-          the following structure (if compressed, uncompress it first):
-
-          Value         Size        Description
-          -----         ----        -----------
-          fdFlags       Short       Finder Flags
-          fdLocation.v  Short       Finder Icon Location
-          fdLocation.h  Short       Finder Icon Location
-          fdFldr        Short       Folder containing file
-
-          FXInfo        16 bytes    Macintosh FXInfo structure
-            FXInfo-Structure:
-                fdIconID        Short
-                fdUnused[3]     Short       unused but reserved 6 bytes
-                fdScript        Byte        Script flag and number
-                fdXFlags        Byte        More flag bits
-                fdComment       Short       Comment ID
-                fdPutAway       Long        Home Dir ID
-
-          FVersNum      Byte        file version number
-                                    may be not used by MacOS
-          ACUser        Byte        directory access rights
-
-          FlCrDat       ULong       date and time of creation
-          FlMdDat       ULong       date and time of last modification
-          FlBkDat       ULong       date and time of last backup
-            These time numbers are original Mac FileTime values (local time!).
-            Currently, date-time width is 32-bit, but future version may
-            support be 64-bit times (see flags)
-
-          CrGMTOffs     Long(signed!)   difference "local Creat. time - UTC"
-          MdGMTOffs     Long(signed!)   difference "local Modif. time - UTC"
-          BkGMTOffs     Long(signed!)   difference "local Backup time - UTC"
-            These "local time - UTC" differences (stored in seconds) may be
-            used to support timestamp adjustment after inter-timezone transfer.
-            These fields are optional; bit 4 of the flags word controls their
-            presence.
-
-          Charset       Short       TextEncodingBase (Charset)
-                                    valid for the following two fields
-
-          FullPath      variable    Path of the current file.
-                                    Zero terminated string (C-String)
-                                    Currently coded in the native Charset.
-
-          Comment       variable    Finder Comment of the current file.
-                                    Zero terminated string (C-String)
-                                    Currently coded in the native Charset.
-
-
-         -SmartZIP Macintosh Extra Field:
-          ====================================
-
-          The following is the layout of the SmartZIP extra
-          block for Macintosh, designed by Marco Bambini.
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-          0x4d63        Short       tag for this extra block type ("cM")
-          TSize         Short       total data size for this block (64)
-          "dZip"        beLong      extra-field signature
-          fdType        Byte[4]     Type of the File (4-byte string)
-          fdCreator     Byte[4]     Creator of the File (4-byte string)
-          fdFlags       beShort     Finder Flags
-          fdLocation.v  beShort     Finder Icon Location
-          fdLocation.h  beShort     Finder Icon Location
-          fdFldr        beShort     Folder containing file
-          CrDat         beLong      HParamBlockRec fileParam.ioFlCrDat
-          MdDat         beLong      HParamBlockRec fileParam.ioFlMdDat
-          frScroll.v    Byte        vertical pos. of folder's scroll bar
-          fdScript      Byte        Script flag and number
-          frScroll.h    Byte        horizontal pos. of folder's scroll bar
-          fdXFlags      Byte        More flag bits
-          FileName      Byte[32]    full Macintosh filename (pascal string)
-
-          All fields but the first two are in native Macintosh format
-          (big-endian Motorola order, not little-endian Intel).
-          The extra field size is fixed to 64 bytes.
-          The local-header and central-header versions are identical.
-
-
-         -Acorn SparkFS Extra Field:
-          =========================
-
-          The following is the layout of David Pilling's SparkFS extra block
-          for Acorn RISC OS.  The local-header and central-header versions are
-          identical.  (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Acorn) 0x4341        Short       tag for this extra block type ("AC")
-          TSize         Short       total data size for this block (20)
-          "ARC0"        Long        extra-field signature
-          LoadAddr      Long        load address or file type
-          ExecAddr      Long        exec address
-          Attr          Long        file permissions
-          Zero          Long        reserved; always zero
-
-          The following bits of Attr are associated with the given file
-          permissions:
-
-                bit 0           user-writable ('W')
-                bit 1           user-readable ('R')
-                bit 2           reserved
-                bit 3           locked ('L')
-                bit 4           publicly writable ('w')
-                bit 5           publicly readable ('r')
-                bit 6           reserved
-                bit 7           reserved
-
-
-         -VM/CMS Extra Field:
-          ==================
-
-          The following is the layout of the file-attributes extra block for
-          VM/CMS.  The local-header and central-header versions are
-          identical.  (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
- (VM/CMS) 0x4704        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          flData        variable    file attributes data
-
-          flData is an uncompressed fldata_t struct.
-
-
-         -MVS Extra Field:
-          ===============
-
-          The following is the layout of the file-attributes extra block for
-          MVS.  The local-header and central-header versions are identical.
-          (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (MVS)   0x470f        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          flData        variable    file attributes data
-
-          flData is an uncompressed fldata_t struct.
-
-
-         -PKWARE Unix Extra Field (0x000d):
-          ================================
-
-          The following is the layout of PKWARE's Unix "extra" block.
-          It was introduced with the release of PKZIP for Unix 2.50.
-          Note: all fields are stored in Intel low-byte/high-byte order.
-          (Last Revision 19980901)
-
-          This field has a minimum data size of 12 bytes and is only stored
-          as local extra field.
-
-          Value         Size        Description
-          -----         ----        -----------
- (Unix0)  0x000d        Short       Tag for this "extra" block type
-          TSize         Short       Total Data Size for this block
-          AcTime        Long        time of last access (UTC/GMT)
-          ModTime       Long        time of last modification (UTC/GMT)
-          UID           Short       Unix user ID
-          GID           Short       Unix group ID
-          (var)         variable    Variable length data field
-
-          The variable length data field will contain file type
-          specific data.  Currently the only values allowed are
-          the original "linked to" file names for hard or symbolic
-          links, and the major and minor device node numbers for
-          character and block device nodes.  Since device nodes
-          cannot be either symbolic or hard links, only one set of
-          variable length data is stored.  Link files will have the
-          name of the original file stored.  This name is NOT NULL
-          terminated.  Its size can be determined by checking TSize -
-          12.  Device entries will have eight bytes stored as two 4
-          byte entries (in little-endian format).  The first entry
-          will be the major device number, and the second the minor
-          device number.
-
-         [Info-ZIP note: The fixed part of this field has the same layout as
-          Info-ZIP's abandoned "Unix1 timestamps & owner ID info" extra field;
-          only the two tag bytes are different.]
-
-
-         -PATCH Descriptor Extra Field (0x000f):
-          =====================================
-
-          The following is the layout of the Patch Descriptor "extra"
-          block.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Patch) 0x000f        Short       Tag for this "extra" block type
-          TSize         Short       Size of the total "extra" block
-          Version       Short       Version of the descriptor
-          Flags         Long        Actions and reactions (see below)
-          OldSize       Long        Size of the file about to be patched
-          OldCRC        Long        32-bit CRC of the file about to be patched
-          NewSize       Long        Size of the resulting file
-          NewCRC        Long        32-bit CRC of the resulting file
-
-
-          Actions and reactions
-
-          Bits          Description
-          ----          ----------------
-          0             Use for auto detection
-          1             Treat as a self-patch
-          2-3           RESERVED
-          4-5           Action (see below)
-          6-7           RESERVED
-          8-9           Reaction (see below) to absent file
-          10-11         Reaction (see below) to newer file
-          12-13         Reaction (see below) to unknown file
-          14-15         RESERVED
-          16-31         RESERVED
-
-          Actions
-
-          Action       Value
-          ------       -----
-          none         0
-          add          1
-          delete       2
-          patch        3
-
-          Reactions
-
-          Reaction     Value
-          --------     -----
-          ask          0
-          skip         1
-          ignore       2
-          fail         3
-
-          Patch support is provided by PKPatchMaker(tm) technology and is
-          covered under U.S. Patents and Patents Pending.
-
-
-         -PKCS#7 Store for X.509 Certificates (0x0014):
-          ============================================
-
-          This field contains information about each of the certificates
-          files may be signed with.  When the Central Directory Encryption
-          feature is enabled for a ZIP file, this record will appear in
-          the Archive Extra Data Record, otherwise it will appear in the
-          first central directory record and will be ignored in any
-          other record.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value     Size     Description
-          -----     ----     -----------
-  (Store) 0x0014    2 bytes  Tag for this "extra" block type
-          TSize     2 bytes  Size of the store data
-          SData     TSize    Data about the store
-
-          SData
-          Value     Size        Description
-          -----     ----        -----------
-          Version   2 bytes     Version number, 0x0001 for now
-          StoreD    (variable)  Actual store data
-
-          The StoreD member is suitable for passing as the pbData
-          member of a CRYPT_DATA_BLOB to the CertOpenStore() function
-          in Microsoft's CryptoAPI.  The SSize member above will be
-          cbData + 6, where cbData is the cbData member of the same
-          CRYPT_DATA_BLOB.  The encoding type to pass to
-          CertOpenStore() should be
-          PKCS_7_ANS_ENCODING | X509_ASN_ENCODING.
-
-
-         -X.509 Certificate ID and Signature for individual file (0x0015):
-          ===============================================================
-
-          This field contains the information about which certificate in
-          the PKCS#7 store was used to sign a particular file.  It also
-          contains the signature data.  This field can appear multiple
-          times, but can only appear once per certificate.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (CID)   0x0015        2 bytes     Tag for this "extra" block type
-          CSize         2 bytes     Size of Method
-          Method        (variable)
-
-          Method
-          Value         Size        Description
-          -----         ----        -----------
-          Version       2 bytes     Version number, for now 0x0001
-          AlgID         2 bytes     Algorithm ID used for signing
-          IDSize        2 bytes     Size of Certificate ID data
-          CertID        (variable)  Certificate ID data
-          SigSize       2 bytes     Size of Signature data
-          Sig           (variable)  Signature data
-
-          CertID
-          Value         Size        Description
-          -----         ----        -----------
-          Size1         4 bytes     Size of CertID, should be (IDSize - 4)
-          Size1         4 bytes     A bug in version one causes this value
-                                    to appear twice.
-          IssSize       4 bytes     Issuer data size
-          Issuer        (variable)  Issuer data
-          SerSize       4 bytes     Serial Number size
-          Serial        (variable)  Serial Number data
-
-          The Issuer and IssSize members are suitable for creating a
-          CRYPT_DATA_BLOB to be the Issuer member of a CERT_INFO
-          struct. The Serial and SerSize members would be the
-          SerialNumber member of the same CERT_INFO struct.  This
-          struct would be used to find the certificate in the store
-          the file was signed with.  Those structures are from the MS
-          CryptoAPI.
-
-          Sig and SigSize are the actual signature data and size
-          generated by signing the file with the MS CryptoAPI using a
-          hash created with the given AlgID.
-
-
-         -X.509 Certificate ID and Signature for central directory (0x0016):
-          =================================================================
-
-          This field contains the information about which certificate in
-          the PKCS#7 store was used to sign the central directory structure.
-          When the Central Directory Encryption feature is enabled for a
-          ZIP file, this record will appear in the Archive Extra Data Record,
-          otherwise it will appear in the first central directory record,
-          along with the store.  The data structure is the
-          same as the CID, except that SigSize will be 0, and there
-          will be no Sig member.
-
-          This field is also kept after the last central directory
-          record, as the signature data (ID 0x05054b50, it looks like
-          a central directory record of a different type).  This
-          second copy of the data is the Signature Data member of the
-          record, and will have a SigSize that is non-zero, and will
-          have Sig data.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value     Size     Description
-          -----     ----     -----------
-  (CDID)  0x0016    2 bytes  Tag for this "extra" block type
-          TSize     2 bytes  Size of data that follows
-          TData     TSize    Data
-
-
-         -Strong Encryption Header (0x0017) (EFS):
-          ===============================
-
-          Value     Size     Description
-          -----     ----     -----------
-          0x0017    2 bytes  Tag for this "extra" block type
-          TSize     2 bytes  Size of data that follows
-          Format    2 bytes  Format definition for this record
-          AlgID     2 bytes  Encryption algorithm identifier
-          Bitlen    2 bytes  Bit length of encryption key
-          Flags     2 bytes  Processing flags
-          CertData  TSize-8  Certificate decryption extra field data
-                             (refer to the explanation for CertData
-                              in the section describing the
-                              Certificate Processing Method under
-                              the Strong Encryption Specification)
-
-
-         -Record Management Controls (0x0018):
-          ===================================
-
-          Value     Size     Description
-          -----     ----     -----------
-(Rec-CTL) 0x0018    2 bytes  Tag for this "extra" block type
-          CSize     2 bytes  Size of total extra block data
-          Tag1      2 bytes  Record control attribute 1
-          Size1     2 bytes  Size of attribute 1, in bytes
-          Data1     Size1    Attribute 1 data
-            .
-            .
-            .
-          TagN      2 bytes  Record control attribute N
-          SizeN     2 bytes  Size of attribute N, in bytes
-          DataN     SizeN    Attribute N data
-
-
-         -PKCS#7 Encryption Recipient Certificate List (0x0019): (EFS)
-          =====================================================
-
-          This field contains the information about each of the certificates
-          that files may be encrypted with. This field should only appear
-          in the archive extra data record. This field is not required and
-          serves only to aide archive modifications by preserving public
-          encryption data. Individual security requirements may dictate
-          that this data be omitted to deter information exposure.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value     Size     Description
-          -----     ----     -----------
- (CStore) 0x0019    2 bytes  Tag for this "extra" block type
-          TSize     2 bytes  Size of the store data
-          TData     TSize    Data about the store
-
-          TData:
-
-          Value     Size     Description
-          -----     ----     -----------
-          Version   2 bytes  Format version number - must 0x0001 at this time
-          CStore    (var)    PKCS#7 data blob
-
-
-         -MVS Extra Field (PKWARE, 0x0065):
-          ================================
-
-          The following is the layout of the MVS "extra" block.
-          Note: Some fields are stored in Big Endian format.
-          All text is in EBCDIC format unless otherwise specified.
-
-          Value       Size          Description
-          -----       ----          -----------
-  (MVS)   0x0065      2 bytes       Tag for this "extra" block type
-          TSize       2 bytes       Size for the following data block
-          ID          4 bytes       EBCDIC "Z390" 0xE9F3F9F0 or
-                                    "T4MV" for TargetFour
-          (var)       TSize-4       Attribute data
-
-
-         -OS/400 Extra Field (0x0065):
-          ===========================
-
-          The following is the layout of the OS/400 "extra" block.
-          Note: Some fields are stored in Big Endian format.
-          All text is in EBCDIC format unless otherwise specified.
-
-          Value       Size          Description
-          -----       ----          -----------
-  (OS400) 0x0065      2 bytes       Tag for this "extra" block type
-          TSize       2 bytes       Size for the following data block
-          ID          4 bytes       EBCDIC "I400" 0xC9F4F0F0 or
-                                    "T4MV" for TargetFour
-          (var)       TSize-4       Attribute data
-
-
-         -Extended Timestamp Extra Field:
-          ==============================
-
-          The following is the layout of the extended-timestamp extra block.
-          (Last Revision 19970118)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (time)  0x5455        Short       tag for this extra block type ("UT")
-          TSize         Short       total data size for this block
-          Flags         Byte        info bits
-          (ModTime)     Long        time of last modification (UTC/GMT)
-          (AcTime)      Long        time of last access (UTC/GMT)
-          (CrTime)      Long        time of original creation (UTC/GMT)
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (time)  0x5455        Short       tag for this extra block type ("UT")
-          TSize         Short       total data size for this block
-          Flags         Byte        info bits (refers to local header!)
-          (ModTime)     Long        time of last modification (UTC/GMT)
-
-          The central-header extra field contains the modification time only,
-          or no timestamp at all.  TSize is used to flag its presence or
-          absence.  But note:
-
-              If "Flags" indicates that Modtime is present in the local header
-              field, it MUST be present in the central header field, too!
-              This correspondence is required because the modification time
-              value may be used to support trans-timezone freshening and
-              updating operations with zip archives.
-
-          The time values are in standard Unix signed-long format, indicating
-          the number of seconds since 1 January 1970 00:00:00.  The times
-          are relative to Coordinated Universal Time (UTC), also sometimes
-          referred to as Greenwich Mean Time (GMT).  To convert to local time,
-          the software must know the local timezone offset from UTC/GMT.
-
-          The lower three bits of Flags in both headers indicate which time-
-          stamps are present in the LOCAL extra field:
-
-                bit 0           if set, modification time is present
-                bit 1           if set, access time is present
-                bit 2           if set, creation time is present
-                bits 3-7        reserved for additional timestamps; not set
-
-          Those times that are present will appear in the order indicated, but
-          any combination of times may be omitted.  (Creation time may be
-          present without access time, for example.)  TSize should equal
-          (1 + 4*(number of set bits in Flags)), as the block is currently
-          defined.  Other timestamps may be added in the future.
-
-
-         -Info-ZIP Unix Extra Field (type 1):
-          ==================================
-
-          The following is the layout of the old Info-ZIP extra block for
-          Unix.  It has been replaced by the extended-timestamp extra block
-          (0x5455) and the Unix type 2 extra block (0x7855).
-          (Last Revision 19970118)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix1) 0x5855        Short       tag for this extra block type ("UX")
-          TSize         Short       total data size for this block
-          AcTime        Long        time of last access (UTC/GMT)
-          ModTime       Long        time of last modification (UTC/GMT)
-          UID           Short       Unix user ID (optional)
-          GID           Short       Unix group ID (optional)
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix1) 0x5855        Short       tag for this extra block type ("UX")
-          TSize         Short       total data size for this block
-          AcTime        Long        time of last access (GMT/UTC)
-          ModTime       Long        time of last modification (GMT/UTC)
-
-          The file access and modification times are in standard Unix signed-
-          long format, indicating the number of seconds since 1 January 1970
-          00:00:00.  The times are relative to Coordinated Universal Time
-          (UTC), also sometimes referred to as Greenwich Mean Time (GMT).  To
-          convert to local time, the software must know the local timezone
-          offset from UTC/GMT.  The modification time may be used by non-Unix
-          systems to support inter-timezone freshening and updating of zip
-          archives.
-
-          The local-header extra block may optionally contain UID and GID
-          info for the file.  The local-header TSize value is the only
-          indication of this.  Note that Unix UIDs and GIDs are usually
-          specific to a particular machine, and they generally require root
-          access to restore.
-
-          This extra field type is obsolete, but it has been in use since
-          mid-1994.  Therefore future archiving software should continue to
-          support it.  Some guidelines:
-
-              An archive member should either contain the old "Unix1"
-              extra field block or the new extra field types "time" and/or
-              "Unix2".
-
-              If both the old "Unix1" block type and one or both of the new
-              block types "time" and "Unix2" are found, the "Unix1" block
-              should be considered invalid and ignored.
-
-              Unarchiving software should recognize both old and new extra
-              field block types, but the info from new types overrides the
-              old "Unix1" field.
-
-              Archiving software should recognize "Unix1" extra fields for
-              timestamp comparison but never create it for updated, freshened
-              or new archive members.  When copying existing members to a new
-              archive, any "Unix1" extra field blocks should be converted to
-              the new "time" and/or "Unix2" types.
-
-
-         -Info-ZIP Unix Extra Field (type 2):
-          ==================================
-
-          The following is the layout of the new Info-ZIP extra block for
-          Unix.  (Last Revision 19960922)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix2) 0x7855        Short       tag for this extra block type ("Ux")
-          TSize         Short       total data size for this block (4)
-          UID           Short       Unix user ID
-          GID           Short       Unix group ID
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix2) 0x7855        Short       tag for this extra block type ("Ux")
-          TSize         Short       total data size for this block (0)
-
-          The data size of the central-header version is zero; it is used
-          solely as a flag that UID/GID info is present in the local-header
-          extra field.  If additional fields are ever added to the local
-          version, the central version may be extended to indicate this.
-
-          Note that Unix UIDs and GIDs are usually specific to a particular
-          machine, and they generally require root access to restore.
-
-
-         -ASi Unix Extra Field:
-          ====================
-
-          The following is the layout of the ASi extra block for Unix.  The
-          local-header and central-header versions are identical.
-          (Last Revision 19960916)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix3) 0x756e        Short       tag for this extra block type ("nu")
-          TSize         Short       total data size for this block
-          CRC           Long        CRC-32 of the remaining data
-          Mode          Short       file permissions
-          SizDev        Long        symlink'd size OR major/minor dev num
-          UID           Short       user ID
-          GID           Short       group ID
-          (var.)        variable    symbolic link filename
-
-          Mode is the standard Unix st_mode field from struct stat, containing
-          user/group/other permissions, setuid/setgid and symlink info, etc.
-
-          If Mode indicates that this file is a symbolic link, SizDev is the
-          size of the file to which the link points.  Otherwise, if the file
-          is a device, SizDev contains the standard Unix st_rdev field from
-          struct stat (includes the major and minor numbers of the device).
-          SizDev is undefined in other cases.
-
-          If Mode indicates that the file is a symbolic link, the final field
-          will be the name of the file to which the link points.  The file-
-          name length can be inferred from TSize.
-
-          [Note that TSize may incorrectly refer to the data size not counting
-           the CRC; i.e., it may be four bytes too small.]
-
-
-         -BeOS Extra Field:
-          ================
-
-          The following is the layout of the file-attributes extra block for
-          BeOS.  (Last Revision 19970531)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (BeOS)  0x6542        Short       tag for this extra block type ("Be")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed file attribute data size
-          Flags         Byte        info bits
-          (CType)       Short       compression type
-          (CRC)         Long        CRC value for uncompressed file attribs
-          Attribs       variable    file attribute data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (BeOS)  0x6542        Short       tag for this extra block type ("Be")
-          TSize         Short       total data size for this block (5)
-          BSize         Long        size of uncompr. local EF block data
-          Flags         Byte        info bits
-
-          The least significant bit of Flags in both headers indicates whether
-          the LOCAL extra field is uncompressed (and therefore whether CType
-          and CRC are omitted):
-
-                bit 0           if set, Attribs is uncompressed (no CType, CRC)
-                bits 1-7        reserved; if set, assume error or unknown data
-
-          Currently the only supported compression types are deflated (type 8)
-          and stored (type 0); the latter is not used by Info-ZIP's Zip but is
-          supported by UnZip.
-
-          Attribs is a BeOS-specific block of data in big-endian format with
-          the following structure (if compressed, uncompress it first):
-
-              Value     Size        Description
-              -----     ----        -----------
-              Name      variable    attribute name (null-terminated string)
-              Type      Long        attribute type (32-bit unsigned integer)
-              Size      Long Long   data size for this sub-block (64 bits)
-              Data      variable    attribute data
-
-          The attribute structure is repeated for every attribute.  The Data
-          field may contain anything--text, flags, bitmaps, etc.
-
-
-         -AtheOS Extra Field:
-          ==================
-
-          The following is the layout of the file-attributes extra block for
-          AtheOS.  This field is a very close spin-off from the BeOS e.f.
-          The only differences are:
-           - a new extra field signature
-           - numeric field in the attributes data are stored in little-endian
-             format ("i386" was initial hardware for AtheOS)
-          (Last Revision 20040908)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
- (AtheOS) 0x7441        Short       tag for this extra block type ("At")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed file attribute data size
-          Flags         Byte        info bits
-          (CType)       Short       compression type
-          (CRC)         Long        CRC value for uncompressed file attribs
-          Attribs       variable    file attribute data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
- (AtheOS) 0x7441        Short       tag for this extra block type ("At")
-          TSize         Short       total data size for this block (5)
-          BSize         Long        size of uncompr. local EF block data
-          Flags         Byte        info bits
-
-          The least significant bit of Flags in both headers indicates whether
-          the LOCAL extra field is uncompressed (and therefore whether CType
-          and CRC are omitted):
-
-                bit 0           if set, Attribs is uncompressed (no CType, CRC)
-                bits 1-7        reserved; if set, assume error or unknown data
-
-          Currently the only supported compression types are deflated (type 8)
-          and stored (type 0); the latter is not used by Info-ZIP's Zip but is
-          supported by UnZip.
-
-          Attribs is a AtheOS-specific block of data in little-endian format
-          with the following structure (if compressed, uncompress it first):
-
-              Value     Size        Description
-              -----     ----        -----------
-              Name      variable    attribute name (null-terminated string)
-              Type      Long        attribute type (32-bit unsigned integer)
-              Size      Long Long   data size for this sub-block (64 bits)
-              Data      variable    attribute data
-
-          The attribute structure is repeated for every attribute.  The Data
-          field may contain anything--text, flags, bitmaps, etc.
-
-
-         -SMS/QDOS Extra Field:
-          ====================
-
-          The following is the layout of the file-attributes extra block for
-          SMS/QDOS.  The local-header and central-header versions are identical.
-          (Last Revision 19960929)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (QDOS)  0xfb4a        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          LongID        Long        extra-field signature
-          (ExtraID)     Long        additional signature/flag bytes
-          QDirect       64 bytes    qdirect structure
-
-          LongID may be "QZHD" or "QDOS".  In the latter case, ExtraID will
-          be present.  Its first three bytes are "02\0"; the last byte is
-          currently undefined.
-
-          QDirect contains the file's uncompressed directory info (qdirect
-          struct).  Its elements are in native (big-endian) format:
-
-          d_length      beLong          file length
-          d_access      byte            file access type
-          d_type        byte            file type
-          d_datalen     beLong          data length
-          d_reserved    beLong          unused
-          d_szname      beShort         size of filename
-          d_name        36 bytes        filename
-          d_update      beLong          time of last update
-          d_refdate     beLong          file version number
-          d_backup      beLong          time of last backup (archive date)
-
-
-         -AOS/VS Extra Field:
-          ==================
-
-          The following is the layout of the extra block for Data General
-          AOS/VS.  The local-header and central-header versions are identical.
-          (Last Revision 19961125)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (AOSVS) 0x5356        Short       tag for this extra block type ("VS")
-          TSize         Short       total data size for this block
-          "FCI\0"       Long        extra-field signature
-          Version       Byte        version of AOS/VS extra block (10 = 1.0)
-          Fstat         variable    fstat packet
-          AclBuf        variable    raw ACL data ($MXACL bytes)
-
-          Fstat contains the file's uncompressed fstat packet, which is one of
-          the following:
-
-                normal fstat packet             (P_FSTAT struct)
-                DIR/CPD fstat packet            (P_FSTAT_DIR struct)
-                unit (device) fstat packet      (P_FSTAT_UNIT struct)
-                IPC file fstat packet           (P_FSTAT_IPC struct)
-
-          AclBuf contains the raw ACL data; its length is $MXACL.
-
-
-         -Tandem NSK Extra Field:
-          ======================
-
-          The following is the layout of the file-attributes extra block for
-          Tandem NSK.  The local-header and central-header versions are
-          identical.  (Last Revision 19981221)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (TA)    0x4154        Short       tag for this extra block type ("TA")
-          TSize         Short       total data size for this block (20)
-          NSKattrs      20 Bytes    NSK attributes
-
-
-         -THEOS Extra Field:
-          =================
-
-          The following is the layout of the file-attributes extra block for
-          Theos.  The local-header and central-header versions are identical.
-          (Last Revision 19990206)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Theos) 0x6854        Short       'Th' signature
-          size          Short       size of extra block
-          flags         Byte        reserved for future use
-          filesize      Long        file size
-          fileorg       Byte        type of file (see below)
-          keylen        Short       key length for indexed and keyed files,
-                                    data segment size for 16 bits programs
-          reclen        Short       record length for indexed,keyed and direct,
-                                    text segment size for 16 bits programs
-          filegrow      Byte        growing factor for indexed,keyed and direct
-          protect       Byte        protections (see below)
-          reserved      Short       reserved for future use
-
-            File types
-            ==========
-
-            0x80  library (keyed access list of files)
-            0x40  directory
-            0x10  stream file
-            0x08  direct file
-            0x04  keyed file
-            0x02  indexed file
-            0x0e  reserved
-            0x01  16 bits real mode program (obsolete)
-            0x21  16 bits protected mode program
-            0x41  32 bits protected mode program
-
-            Protection codes
-            ================
-
-            User protection
-            ---------------
-            0x01  non readable
-            0x02  non writable
-            0x04  non executable
-            0x08  non erasable
-
-            Other protection
-            ----------------
-            0x10  non readable
-            0x20  non writable
-            0x40  non executable Theos before 4.0
-            0x40  modified Theos 4.x
-            0x80  not hidden
-
-
-         -THEOS old inofficial Extra Field:
-          ================================
-
-          The following is the layout of an inoffical former version of a
-          Theos file-attributes extra blocks.  This layout was never published
-          and is no longer created. However, UnZip can optionally support it
-          when compiling with the option flag OLD_THEOS_EXTRA defined.
-          Both the local-header and central-header versions are identical.
-          (Last Revision 19990206)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (THS0)  0x4854        Short       'TH' signature
-          size          Short       size of extra block
-          flags         Short       reserved for future use
-          filesize      Long        file size
-          reclen        Short       record length for indexed,keyed and direct,
-                                    text segment size for 16 bits programs
-          keylen        Short       key length for indexed and keyed files,
-                                    data segment size for 16 bits programs
-          filegrow      Byte        growing factor for indexed,keyed and direct
-          reserved      3 Bytes     reserved for future use
-
-
-         -FWKCS MD5 Extra Field (0x4b46):
-          ==============================
-
-          The FWKCS Contents_Signature System, used in automatically
-          identifying files independent of filename, optionally adds
-          and uses an extra field to support the rapid creation of
-          an enhanced contents_signature.
-          There is no local-header version; the following applies
-          only to the central header.  (Last Revision 19961207)
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (MD5)   0x4b46        Short       tag for this extra block type ("FK")
-          TSize         Short       total data size for this block (19)
-          "MD5"         3 bytes     extra-field signature
-          MD5hash       16 bytes    128-bit MD5 hash of uncompressed data
-                                    (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."
-
-
-      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.  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)  Local headers should not span disk boundaries.  Also, even
-          though the central directory can span disk boundaries, no
-          single record in the central directory should be split
-          across disks.
-
-      4)  The entries in the central directory may not necessarily
-          be in the same order that files appear in the .ZIP file.
-
-      5)  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.  Spanned/split archives
-          created with this special signature are compatible with
-          all versions of PKZIP from PKWARE.  Split archives can
-          only be uncompressed by other versions of PKZIP that
-          know how to create a split archive.
-
-      6)  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.
-
-      7)  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.
-
-V. 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-used, with the lowest
-    code value re-used first, and the highest code value
-    re-used last.  The compressor can emit the sequence 256,2
-    at any time.
-
-
-VI. Expanding - Methods 2-5
----------------------------
-
-The Reducing algorithm is actually a combination of two
-distinct algorithms.  The first algorithm compresses repeated
-byte sequences, and the second algorithm takes the compressed
-stream from the first algorithm and applies a probabilistic
-compression method.
-
-The probabilistic compression stores an array of 'follower
-sets' S(j), for j=0 to 255, corresponding to each possible
-ASCII character.  Each set contains between 0 and 32
-characters, to be denoted as S(j)[0],...,S(j)[m], where m<32.
-The sets are stored at the beginning of the data area for a
-Reduced file, in reverse order, with S(255) first, and S(0)
-last.
-
-The sets are encoded as { N(j), S(j)[0],...,S(j)[N(j)-1] },
-where N(j) is the size of set S(j).  N(j) can be 0, in which
-case the follower set for S(j) is empty.  Each N(j) value is
-encoded in 6 bits, followed by N(j) eight bit character values
-corresponding to S(j)[0] to S(j)[N(j)-1] respectively.  If
-N(j) is 0, then no values for S(j) are stored, and the value
-for N(j-1) immediately follows.
-
-Immediately after the follower sets, is the compressed data
-stream.  The compressed data stream can be interpreted for the
-probabilistic decompression as follows:
-
-
-let Last-Character <- 0.
-loop until done
-    if the follower set S(Last-Character) is empty then
-        read 8 bits from the input stream, and copy this
-        value to the output stream.
-    otherwise if the follower set S(Last-Character) is non-empty then
-        read 1 bit from the input stream.
-        if this bit is not zero then
-            read 8 bits from the input stream, and copy this
-            value to the output stream.
-        otherwise if this bit is zero then
-            read B(N(Last-Character)) bits from the input
-            stream, and assign this value to I.
-            Copy the value of S(Last-Character)[I] to the
-            output stream.
-
-    assign the last value placed on the output stream to
-    Last-Character.
-end loop
-
-
-B(N(j)) is defined as the minimal number of bits required to
-encode the value N(j)-1.
-
-
-The decompressed stream from above can then be expanded to
-re-create the original file as follows:
-
-
-let State <- 0.
-
-loop until done
-    read 8 bits from the input stream into C.
-    case State of
-        0:  if C is not equal to DLE (144 decimal) then
-                copy C to the output stream.
-            otherwise if C is equal to DLE then
-                let State <- 1.
-
-        1:  if C is non-zero then
-                let V <- C.
-                let Len <- L(V)
-                let State <- F(Len).
-            otherwise if C is zero then
-                copy the value 144 (decimal) to the output stream.
-                let State <- 0
-
-        2:  let Len <- Len + C
-            let State <- 3.
-
-        3:  move backwards D(V,C) bytes in the output stream
-            (if this position is before the start of the output
-            stream, then assume that all the data before the
-            start of the output stream is filled with zeros).
-            copy Len+3 bytes from this position to the output stream.
-            let State <- 0.
-    end case
-end loop
-
-
-The functions F,L, and D are dependent on the 'compression
-factor', 1 through 4, and are defined as follows:
-
-For compression factor 1:
-    L(X) equals the lower 7 bits of X.
-    F(X) equals 2 if X equals 127 otherwise F(X) equals 3.
-    D(X,Y) equals the (upper 1 bit of X) * 256 + Y + 1.
-For compression factor 2:
-    L(X) equals the lower 6 bits of X.
-    F(X) equals 2 if X equals 63 otherwise F(X) equals 3.
-    D(X,Y) equals the (upper 2 bits of X) * 256 + Y + 1.
-For compression factor 3:
-    L(X) equals the lower 5 bits of X.
-    F(X) equals 2 if X equals 31 otherwise F(X) equals 3.
-    D(X,Y) equals the (upper 3 bits of X) * 256 + Y + 1.
-For compression factor 4:
-    L(X) equals the lower 4 bits of X.
-    F(X) equals 2 if X equals 15 otherwise F(X) equals 3.
-    D(X,Y) equals the (upper 4 bits of X) * 256 + Y + 1.
-
-
-VII. Imploding - Method 6
--------------------------
-
-The Imploding algorithm is actually a combination of two distinct
-algorithms.  The first algorithm compresses repeated byte
-sequences using a sliding dictionary.  The second algorithm is
-used to compress the encoding of the sliding dictionary output,
-using multiple Shannon-Fano trees.
-
-The Imploding algorithm can use a 4K or 8K sliding dictionary
-size. The dictionary size used can be determined by bit 1 in the
-general purpose flag word; a 0 bit indicates a 4K dictionary
-while a 1 bit indicates an 8K dictionary.
-
-The Shannon-Fano trees are stored at the start of the compressed
-file. The number of trees stored is defined by bit 2 in the
-general purpose flag word; a 0 bit indicates two trees stored, a
-1 bit indicates three trees are stored.  If 3 trees are stored,
-the first Shannon-Fano tree represents the encoding of the
-Literal characters, the second tree represents the encoding of
-the Length information, the third represents the encoding of the
-Distance information.  When 2 Shannon-Fano trees are stored, the
-Length tree is stored first, followed by the Distance tree.
-
-The Literal Shannon-Fano tree, if present is used to represent
-the entire ASCII character set, and contains 256 values.  This
-tree is used to compress any data not compressed by the sliding
-dictionary algorithm.  When this tree is present, the Minimum
-Match Length for the sliding dictionary is 3.  If this tree is
-not present, the Minimum Match Length is 2.
-
-The Length Shannon-Fano tree is used to compress the Length part
-of the (length,distance) pairs from the sliding dictionary
-output.  The Length tree contains 64 values, ranging from the
-Minimum Match Length, to 63 plus the Minimum Match Length.
-
-The Distance Shannon-Fano tree is used to compress the Distance
-part of the (length,distance) pairs from the sliding dictionary
-output. The Distance tree contains 64 values, ranging from 0 to
-63, representing the upper 6 bits of the distance value.  The
-distance values themselves will be between 0 and the sliding
-dictionary size, either 4K or 8K.
-
-The Shannon-Fano trees themselves are stored in a compressed
-format. The first byte of the tree data represents the number of
-bytes of data representing the (compressed) Shannon-Fano tree
-minus 1.  The remaining bytes represent the Shannon-Fano tree
-data encoded as:
-
-    High 4 bits: Number of values at this bit length + 1. (1 - 16)
-    Low  4 bits: Bit Length needed to represent value + 1. (1 - 16)
-
-The Shannon-Fano codes can be constructed from the bit lengths
-using the following algorithm:
-
-1)  Sort the Bit Lengths in ascending order, while retaining the
-    order of the original lengths stored in the file.
-
-2)  Generate the Shannon-Fano trees:
-
-    Code <- 0
-    CodeIncrement <- 0
-    LastBitLength <- 0
-    i <- number of Shannon-Fano codes - 1   (either 255 or 63)
-
-    loop while i >= 0
-        Code = Code + CodeIncrement
-        if BitLength(i) <> LastBitLength then
-            LastBitLength=BitLength(i)
-            CodeIncrement = 1 shifted left (16 - LastBitLength)
-        ShannonCode(i) = Code
-        i <- i - 1
-    end loop
-
-
-3)  Reverse the order of all the bits in the above ShannonCode()
-    vector, so that the most significant bit becomes the least
-    significant bit.  For example, the value 0x1234 (hex) would
-    become 0x2C48 (hex).
-
-4)  Restore the order of Shannon-Fano codes as originally stored
-    within the file.
-
-Example:
-
-    This example will show the encoding of a Shannon-Fano tree
-    of size 8.  Notice that the actual Shannon-Fano trees used
-    for Imploding are either 64 or 256 entries in size.
-
-Example:   0x02, 0x42, 0x01, 0x13
-
-    The first byte indicates 3 values in this table.  Decoding the
-    bytes:
-            0x42 = 5 codes of 3 bits long
-            0x01 = 1 code  of 2 bits long
-            0x13 = 2 codes of 4 bits long
-
-    This would generate the original bit length array of:
-    (3, 3, 3, 3, 3, 2, 4, 4)
-
-    There are 8 codes in this table for the values 0 thru 7.  Using
-    the algorithm to obtain the Shannon-Fano codes produces:
-
-                                  Reversed     Order     Original
-Val  Sorted   Constructed Code      Value     Restored    Length
----  ------   -----------------   --------    --------    ------
-0:     2      1100000000000000        11       101          3
-1:     3      1010000000000000       101       001          3
-2:     3      1000000000000000       001       110          3
-3:     3      0110000000000000       110       010          3
-4:     3      0100000000000000       010       100          3
-5:     3      0010000000000000       100        11          2
-6:     4      0001000000000000      1000      1000          4
-7:     4      0000000000000000      0000      0000          4
-
-
-The values in the Val, Order Restored and Original Length columns
-now represent the Shannon-Fano encoding tree that can be used for
-decoding the Shannon-Fano encoded data.  How to parse the
-variable length Shannon-Fano values from the data stream is beyond
-the scope of this document.  (See the references listed at the end of
-this document for more information.)  However, traditional decoding
-schemes used for Huffman variable length decoding, such as the
-Greenlaw algorithm, can be successfully applied.
-
-The compressed data stream begins immediately after the
-compressed Shannon-Fano data.  The compressed data stream can be
-interpreted as follows:
-
-loop until done
-    read 1 bit from input stream.
-
-    if this bit is non-zero then       (encoded data is literal data)
-        if Literal Shannon-Fano tree is present
-            read and decode character using Literal Shannon-Fano tree.
-        otherwise
-            read 8 bits from input stream.
-        copy character to the output stream.
-    otherwise              (encoded data is sliding dictionary match)
-        if 8K dictionary size
-            read 7 bits for offset Distance (lower 7 bits of offset).
-        otherwise
-            read 6 bits for offset Distance (lower 6 bits of offset).
-
-        using the Distance Shannon-Fano tree, read and decode the
-          upper 6 bits of the Distance value.
-
-        using the Length Shannon-Fano tree, read and decode
-          the Length value.
-
-        Length <- Length + Minimum Match Length
-
-        if Length = 63 + Minimum Match Length
-            read 8 bits from the input stream,
-            add this value to Length.
-
-        move backwards Distance+1 bytes in the output stream, and
-        copy Length characters from this position to the output
-        stream.  (if this position is before the start of the output
-        stream, then assume that all the data before the start of
-        the output stream is filled with zeros).
-end loop
-
-VIII. Tokenizing - Method 7
----------------------------
-
-This method is not used by PKZIP.
-
-IX. Deflating - Method 8
-------------------------
-
-The Deflate algorithm is similar to the Implode algorithm using
-a sliding dictionary of up to 32K with secondary compression
-from Huffman/Shannon-Fano codes.
-
-The compressed data is stored in blocks with a header describing
-the block and the Huffman codes used in the data block.  The header
-format is as follows:
-
-   Bit 0: Last Block bit     This bit is set to 1 if this is the last
-                             compressed block in the data.
-   Bits 1-2: Block type
-      00 (0) - Block is stored - All stored data is byte aligned.
-               Skip bits until next byte, then next word = block
-               length, followed by the ones compliment of the block
-               length word. Remaining data in block is the stored
-               data.
-
-      01 (1) - Use fixed Huffman codes for literal and distance codes.
-               Lit Code    Bits             Dist Code   Bits
-               ---------   ----             ---------   ----
-                 0 - 143    8                 0 - 31      5
-               144 - 255    9
-               256 - 279    7
-               280 - 287    8
-
-               Literal codes 286-287 and distance codes 30-31 are
-               never used but participate in the huffman construction.
-
-      10 (2) - Dynamic Huffman codes.  (See expanding Huffman codes)
-
-      11 (3) - Reserved - Flag a "Error in compressed data" if seen.
-
-Expanding Huffman Codes
------------------------
-If the data block is stored with dynamic Huffman codes, the Huffman
-codes are sent in the following compressed format:
-
-   5 Bits: # of Literal codes sent - 257 (257 - 286)
-           All other codes are never sent.
-   5 Bits: # of Dist codes - 1           (1 - 32)
-   4 Bits: # of Bit Length codes - 4     (4 - 19)
-
-The Huffman codes are sent as bit lengths and the codes are built as
-described in the implode algorithm.  The bit lengths themselves are
-compressed with Huffman codes.  There are 19 bit length codes:
-
-   0 - 15: Represent bit lengths of 0 - 15
-       16: Copy the previous bit length 3 - 6 times.
-           The next 2 bits indicate repeat length (0 = 3, ... ,3 = 6)
-              Example:  Codes 8, 16 (+2 bits 11), 16 (+2 bits 10) will
-                        expand to 12 bit lengths of 8 (1 + 6 + 5)
-       17: Repeat a bit length of 0 for 3 - 10 times. (3 bits of length)
-       18: Repeat a bit length of 0 for 11 - 138 times (7 bits of length)
-
-The lengths of the bit length codes are sent packed 3 bits per value
-(0 - 7) in the following order:
-
-   16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15
-
-The Huffman codes should be built as described in the Implode algorithm
-except codes are assigned starting at the shortest bit length, i.e. the
-shortest code should be all 0's rather than all 1's.  Also, codes with
-a bit length of zero do not participate in the tree construction.  The
-codes are then used to decode the bit lengths for the literal and
-distance tables.
-
-The bit lengths for the literal tables are sent first with the number
-of entries sent described by the 5 bits sent earlier.  There are up
-to 286 literal characters; the first 256 represent the respective 8
-bit character, code 256 represents the End-Of-Block code, the remaining
-29 codes represent copy lengths of 3 thru 258.  There are up to 30
-distance codes representing distances from 1 thru 32k as described
-below.
-
-                             Length Codes
-                             ------------
-      Extra             Extra              Extra              Extra
- Code Bits Length  Code Bits Lengths  Code Bits Lengths  Code Bits Length(s)
- ---- ---- ------  ---- ---- -------  ---- ---- -------  ---- ---- ---------
-  257   0     3     265   1   11,12    273   3   35-42    281   5  131-162
-  258   0     4     266   1   13,14    274   3   43-50    282   5  163-194
-  259   0     5     267   1   15,16    275   3   51-58    283   5  195-226
-  260   0     6     268   1   17,18    276   3   59-66    284   5  227-258
-  261   0     7     269   2   19-22    277   4   67-82    285   0    258
-  262   0     8     270   2   23-26    278   4   83-98
-  263   0     9     271   2   27-30    279   4   99-114
-  264   0    10     272   2   31-34    280   4  115-130
-
-                            Distance Codes
-                            --------------
-      Extra           Extra             Extra               Extra
- Code Bits Dist  Code Bits  Dist   Code Bits Distance  Code Bits Distance
- ---- ---- ----  ---- ---- ------  ---- ---- --------  ---- ---- --------
-   0   0    1      8   3   17-24    16    7  257-384    24   11  4097-6144
-   1   0    2      9   3   25-32    17    7  385-512    25   11  6145-8192
-   2   0    3     10   4   33-48    18    8  513-768    26   12  8193-12288
-   3   0    4     11   4   49-64    19    8  769-1024   27   12 12289-16384
-   4   1   5,6    12   5   65-96    20    9 1025-1536   28   13 16385-24576
-   5   1   7,8    13   5   97-128   21    9 1537-2048   29   13 24577-32768
-   6   2   9-12   14   6  129-192   22   10 2049-3072
-   7   2  13-16   15   6  193-256   23   10 3073-4096
-
-The compressed data stream begins immediately after the
-compressed header data.  The compressed data stream can be
-interpreted as follows:
-
-do
-   read header from input stream.
-
-   if stored block
-      skip bits until byte aligned
-      read count and 1's compliment of count
-      copy count bytes data block
-   otherwise
-      loop until end of block code sent
-         decode literal character from input stream
-         if literal < 256
-            copy character to the output stream
-         otherwise
-            if literal = end of block
-               break from loop
-            otherwise
-               decode distance from input stream
-
-               move backwards distance bytes in the output stream, and
-               copy length characters from this position to the output
-               stream.
-      end loop
-while not last block
-
-if data descriptor exists
-   skip bits until byte aligned
-   check data descriptor signature
-   read crc and sizes
-endif
-
-X. Enhanced Deflating - Method 9
---------------------------------
-
-The Enhanced Deflating algorithm is similar to Deflate but
-uses a sliding dictionary of up to 64K. Deflate64(tm) is supported
-by the Deflate extractor.
-
-[This description is inofficial.  It has been deduced by Info-ZIP from
-close inspection of PKZIP 4.x Deflate64(tm) compressed output.]
-
-The Deflate64 algorithm is almost identical to the normal Deflate algorithm.
-Differences are:
-
-- The sliding window size is 64k.
-
-- The previously unused distance codes 30 and 31 are now used to describe
-  match distances from 32k-48k and 48k-64k.
-         Extra
-    Code Bits Distance
-    ---- ---- -----------
-     ..   ..      ...
-     29   13  24577-32768
-     30   14  32769-49152
-     31   14  49153-65536
-
-- The semantics of the "maximum match length" code #258 has been changed to
-  allow the specification of arbitrary large match lengths (up to 64k).
-         Extra
-    Code Bits Lengths
-    ---- ---- ------
-     ...  ..    ...
-     284   5  227-258
-     285  16  3-65538
-
-Whereas the first two modifications fit into the framework of Deflate,
-this last change breaks compatibility with Deflate method 8. Thus, a
-Deflate64 decompressor cannot decode normal deflated data.
-
-XI. BZIP2 - Method 12
----------------------
-
-BZIP2 is an open-source data compression algorithm developed by
-Julian Seward.  Information and source code for this algorithm
-can be found on the internet.
-
-
-XII. Traditional PKWARE Encryption
-----------------------------------
-
-The following information discusses the decryption steps
-required to support traditional PKWARE encryption.  This
-form of encryption is considered weak by today's standards
-and its use is recommended only for situations with
-low security needs or for compatibility with older .ZIP
-applications.
-
-XIII. Decryption
-----------------
-
-The encryption used in PKZIP was generously supplied by Roger
-Schlafly.  PKWARE is grateful to Mr. Schlafly for his expert
-help and advice in the field of data encryption.
-
-PKZIP encrypts the compressed data stream.  Encrypted files must
-be decrypted before they can be extracted.
-
-Each encrypted file has an extra 12 bytes stored at the start of
-the data area defining the encryption header for that file.  The
-encryption header is originally set to random values, and then
-itself encrypted, using three, 32-bit keys.  The key values are
-initialized using the supplied encryption password.  After each byte
-is encrypted, the keys are then updated using pseudo-random number
-generation techniques in combination with the same CRC-32 algorithm
-used in PKZIP and described elsewhere in this document.
-
-The following is the basic steps required to decrypt a file:
-
-1) Initialize the three 32-bit keys with the password.
-2) Read and decrypt the 12-byte encryption header, further
-   initializing the encryption keys.
-3) Read and decrypt the compressed data stream using the
-   encryption keys.
-
-
-Step 1 - Initializing the encryption keys
------------------------------------------
-
-Key(0) <- 305419896
-Key(1) <- 591751049
-Key(2) <- 878082192
-
-loop for i <- 0 to length(password)-1
-    update_keys(password(i))
-end loop
-
-
-Where update_keys() is defined as:
-
-
-update_keys(char):
-  Key(0) <- crc32(key(0),char)
-  Key(1) <- Key(1) + (Key(0) & 000000ffH)
-  Key(1) <- Key(1) * 134775813 + 1
-  Key(2) <- crc32(key(2),key(1) >> 24)
-end update_keys
-
-
-Where crc32(old_crc,char) is a routine that given a CRC value and a
-character, returns an updated CRC value after applying the CRC-32
-algorithm described elsewhere in this document.
-
-
-Step 2 - Decrypting the encryption header
------------------------------------------
-
-The purpose of this step is to further initialize the encryption
-keys, based on random data, to render a plaintext attack on the
-data ineffective.
-
-
-Read the 12-byte encryption header into Buffer, in locations
-Buffer(0) thru Buffer(11).
-
-loop for i <- 0 to 11
-    C <- buffer(i) ^ decrypt_byte()
-    update_keys(C)
-    buffer(i) <- C
-end loop
-
-
-Where decrypt_byte() is defined as:
-
-
-unsigned char decrypt_byte()
-    local unsigned short temp
-    temp <- Key(2) | 2
-    decrypt_byte <- (temp * (temp ^ 1)) >> 8
-end decrypt_byte
-
-
-After the header is decrypted,  the last 1 or 2 bytes in Buffer
-should be the high-order word/byte of the CRC for the file being
-decrypted, stored in Intel low-byte/high-byte order, or the high-order
-byte of the file time if bit 3 of the general purpose bit flag is set.
-Versions of PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is
-used on versions after 2.0.  This can be used to test if the password
-supplied is correct or not.
-
-
-Step 3 - Decrypting the compressed data stream
-----------------------------------------------
-
-The compressed data stream can be decrypted as follows:
-
-
-loop until done
-    read a character into C
-    Temp <- C ^ decrypt_byte()
-    update_keys(temp)
-    output Temp
-end loop
-
-
-XIV. Strong Encryption Specification (EFS)
-------------------------------------------
-
-Version 5.x of this specification introduced support for strong
-encryption algorithms.  These algorithms can be used with either
-a password or an X.509v3 digital certificate to encrypt each file.
-This format specification supports either password or certificate
-based encryption to meet the security needs of today, to enable
-interoperability between users within both PKI and non-PKI
-environments, and to ensure interoperability between different
-computing platforms that are running a ZIP program.
-
-Password based encryption is the most common form of encryption
-people are familiar with.  However, inherent weaknesses with
-passwords (e.g. susceptibility to dictionary/brute force attack)
-as well as password management and support issues make certificate
-based encryption a more secure and scalable option.  Industry
-efforts and support are defining and moving towards more advanced
-security solutions built around X.509v3 digital certificates and
-Public Key Infrastructures(PKI) because of the greater scalability,
-administrative options, and more robust security over traditional
-password-based encryption.
-
-Most standard encryption algorithms are supported with this
-specification. Reference implementations for many of these
-algorithms are available from either commercial or open source
-distributors.  Readily available cryptographic toolkits make
-implementation of the encryption features straight-forward.
-This document is not intended to provide a treatise on data
-encryption principles or theory.  Its purpose is to document the
-data structures required for implementing interoperable data
-encryption within the .ZIP format.  It is strongly recommended that
-you have a good understanding of data encryption before reading
-further.
-
-The algorithms introduced in Version 5.0 of this specification
-include:
-
-    RC2 40 bit, 64 bit, and 128 bit
-    RC4 40 bit, 64 bit, and 128 bit
-    DES
-    3DES 112 bit and 168 bit
-
-Version 5.1 adds support for the following:
-
-    AES 128 bit, 192 bit, and 256 bit
-
-Version 6.1 introduces encryption data changes to support
-interoperability with SmartCard and USB Token certificate storage
-methods which do not support the OAEP strengthening standard.
-
-Version 6.2 introduces support for encrypting metadata by compressing
-and encrypting the central directory data structure to reduce information
-leakage.   Information leakage can occur in legacy ZIP applications
-through exposure of information about a file even though that file is
-stored encrypted.  The information exposed consists of file
-characteristics stored within the records and fields defined by this
-specification.  This includes data such as a files name, its original
-size, timestamp and CRC32 value.
-
-Central Directory Encryption provides greater protection against
-information leakage by encrypting the Central Directory structure and
-by masking key values that are replicated in the unencrypted Local
-Header.   ZIP compatible programs that cannot interpret an encrypted
-Central Directory structure cannot rely on the data in the corresponding
-Local Header for decompression information.
-
-Extra Field records that may contain information about a file that should
-not be exposed should not be stored in the Local Header and should only
-be written to the Central Directory where they can be encrypted.  This
-design currently does not support streaming.  Information in the End of
-Central Directory record, the ZIP64 End of Central Directory Locator,
-and the ZIP64 End of Central Directory record are not encrypted.  Access
-to view data on files within a ZIP file with an encrypted Central Directory
-requires the appropriate password or private key for decryption prior to
-viewing any files, or any information about the files, in the archive.
-
-Older ZIP compatible programs not familiar with the Central Directory
-Encryption feature will no longer be able to recognize the Central
-Directory and may assume the ZIP file is corrupt.  Programs that
-attempt streaming access using Local Headers will see invalid
-information for each file.  Central Directory Encryption need not be
-used for every ZIP file.  Its use is recommended for greater security.
-ZIP files not using Central Directory Encryption should operate as
-in the past.
-
-The details of the strong encryption specification for certificates
-remain under development as design and testing issues are worked out
-for the range of algorithms, encryption methods, certificate processing
-and cross-platform support necessary to meet the advanced security needs
-of .ZIP file users today and in the future.
-
-This feature specification is intended to support basic encryption needs
-of today, such as password support.  However this specification is also
-designed to lay the foundation for future advanced security needs.
-
-Encryption provides data confidentiality and privacy.  It is
-recommended that you combine X.509 digital signing with encryption
-to add authentication and non-repudiation.
-
-
-Single Password Symmetric Encryption Method:
--------------------------------------------
-
-The Single Password Symmetric Encryption Method using strong
-encryption algorithms operates similarly to the traditional
-PKWARE encryption defined in this format.  Additional data
-structures are added to support the processing needs of the
-strong algorithms.
-
-The Strong Encryption data structures are:
-
-1. General Purpose Bits - Bits 0 and 6 of the General Purpose bit
-flag in both local and central header records.  Both bits set
-indicates strong encryption.  Bit 13, when set indicates the Central
-Directory is encrypted and that selected fields in the Local Header
-are masked to hide their actual value.
-
-
-2. Extra Field 0x0017 in central header only.
-
-     Fields to consider in this record are:
-
-     Format - the data format identifier for this record.  The only
-     value allowed at this time is the integer value 2.
-
-     AlgId - integer identifier of the encryption algorithm from the
-     following range
-
-         0x6601 - DES
-         0x6602 - RC2 (version needed to extract < 5.2)
-         0x6603 - 3DES 168
-         0x6609 - 3DES 112
-         0x660E - AES 128
-         0x660F - AES 192
-         0x6610 - AES 256
-         0x6702 - RC2 (version needed to extract >= 5.2)
-         0x6801 - RC4
-         0xFFFF - Unknown algorithm
-
-     Bitlen - Explicit bit length of key
-
-          40
-          56
-          64
-         112
-         128
-         168
-         192
-         256
-
-     Flags - Processing flags needed for decryption
-
-         0x0001 - Password is required to decrypt
-         0x0002 - Certificates only
-         0x0003 - Password or certificate required to decrypt
-
-         Values > 0x0003 reserved for certificate processing
-
-
-3. Decryption header record preceeding compressed file data.
-
-         -Decryption Header:
-
-          Value     Size     Description
-          -----     ----     -----------
-          IVSize    2 bytes  Size of initialization vector (IV)
-          IVData    IVSize   Initialization vector for this file
-          Size      4 bytes  Size of remaining decryption header data
-          Format    2 bytes  Format definition for this record
-          AlgID     2 bytes  Encryption algorithm identifier
-          Bitlen    2 bytes  Bit length of encryption key
-          Flags     2 bytes  Processing flags
-          ErdSize   2 bytes  Size of Encrypted Random Data
-          ErdData   ErdSize  Encrypted Random Data
-          Reserved1 4 bytes  Reserved certificate processing data
-          Reserved2 (var)    Reserved for certificate processing data
-          VSize     2 bytes  Size of password validation data
-          VData     VSize-4  Password validation data
-          VCRC32    4 bytes  Standard ZIP CRC32 of password validation data
-
-     IVData - The size of the IV should match the algorithm block size.
-              The IVData can be completely random data.  If the size of
-              the randomly generated data does not match the block size
-              it should be complemented with zero's or truncated as
-              necessary.  If IVSize is 0, then IV = CRC32 + Uncompressed
-              File Size (as a 64 bit little-endian, unsigned integer value).
-
-     Format - the data format identifier for this record.  The only
-     value allowed at this time is the integer value 3.
-
-     AlgId - integer identifier of the encryption algorithm from the
-     following range
-
-         0x6601 - DES
-         0x6602 - RC2 (version needed to extract < 5.2)
-         0x6603 - 3DES 168
-         0x6609 - 3DES 112
-         0x660E - AES 128
-         0x660F - AES 192
-         0x6610 - AES 256
-         0x6702 - RC2 (version needed to extract >= 5.2)
-         0x6801 - RC4
-         0xFFFF - Unknown algorithm
-
-     Bitlen - Explicit bit length of key
-
-          40
-          56
-          64
-         112
-         128
-         168
-         192
-         256
-
-     Flags - Processing flags needed for decryption
-
-         0x0001 - Password is required to decrypt
-         0x0002 - Certificates only
-         0x0003 - Password or certificate required to decrypt
-
-         Values > 0x0003 reserved for certificate processing
-
-     ErdData - Encrypted random data is used to generate a file
-               session key for encrypting each file.  SHA1 is
-               used to calculate hash data used to derive keys.
-               File session keys are derived from a master session
-               key generated from the user-supplied password.
-               If the Flags field in the decryption header contains
-               the value 0x4000, then the ErdData field must be
-               decrypted using 3DES.
-
-     Reserved1 - Reserved for certificate processing, if value is
-               zero, then Reserved2 data is absent.  See the explanation
-               under the Certificate Processing Method for details on
-               this data structure.
-
-     Reserved2 - If present, the size of the Reserved2 data structure
-               is located by skipping the first 4 bytes of this field
-               and using the next 2 bytes as the remaining size.  See
-               the explanation under the Certificate Processing Method
-               for details on this data structure.
-
-     VSize - This size value will always include the 4 bytes of the
-             VCRC32 data and will be greater than 4 bytes.
-
-     VData - Random data for password validation.  This data is VSize
-             in length and VSize must be a multiple of the encryption
-             block size.  VCRC32 is a checksum value of VData.
-             VData and VCRC32 are stored encrypted and start the
-             stream of encrypted data for a file.
-
-4. Single Password Central Directory Encryption
-
-Central Directory Encryption is achieved within the .ZIP format by
-encrypting the Central Directory structure.  This encapsulates the metadata
-most often used for processing .ZIP files.  Additional metadata is stored for
-redundancy in the Local Header for each file.  The process of concealing
-metadata by encrypting the Central Directory does not protect the data within
-the Local Header.  To avoid information leakage from the exposed metadata
-in the Local Header, the fields containing information about a file are masked.
-
-Local Header:
-
-Masking replaces the true content of the fields for a file in the Local
-Header with false information.  When masked, the Local Header is not
-suitable for streaming access and the options for data recovery of damaged
-archives is reduced.  Extra Data fields that may contain confidential
-data should not be stored within the Local Header.  The value set into
-the Version needed to extract field should be the correct value needed to
-extract the file without regard to Central Directory Encryption. The fields
-within the Local Header targeted for masking when the Central Directory is
-encrypted are:
-
-        Field Name                     Mask Value
-        ------------------             ---------------------------
-        compression method              0
-        last mod file time              0
-        last mod file date              0
-        crc-32                          0
-        compressed size                 0
-        uncompressed size               0
-        file name (variable size)       Base 16 value from the
-                                        range 1 - FFFFFFFFFFFFFFFF
-                                        represented as a string whose
-                                        size will be set into the
-                                        file name length field
-
-The Base 16 value assigned as a masked file name is simply a sequentially
-incremented value for each file starting with 1 for the first file.
-Modifications to a ZIP file may cause different values to be stored for
-each file.  For compatibility, the file name field in the Local Header
-should never be left blank.  As of Version 6.2 of this specification,
-the Compression Method and Compressed Size fields are not yet masked.
-
-Encrypting the Central Directory:
-
-Encryption of the Central Directory does not include encryption of the
-Central Directory Signature data, the ZIP64 End of Central Directory
-record, the ZIP64 End of Central Directory Locator, or the End
-of Central Directory record.  The ZIP file comment data is never
-encrypted.
-
-Before encrypting the Central Directory, it may optionally be compressed.
-Compression is not required, but for storage efficiency it is assumed
-this structure will be compressed before encrypting.  Similarly, this
-specification supports compressing the Central Directory without
-requiring that it also be encrypted.  Early implementations of this
-feature will assume the encryption method applied to files matches the
-encryption applied to the Central Directory.
-
-Encryption of the Central Directory is done in a manner similar to
-that of file encryption.  The encrypted data is preceded by a
-decryption header.  The decryption header is known as the Archive
-Decryption Header.  The fields of this record are identical to
-the decryption header preceding each encrypted file.  The location
-of the Archive Decryption Header is determined by the value in the
-Start of the Central Directory field in the ZIP64 End of Central
-Directory record.  When the Central Directory is encrypted, the
-ZIP64 End of Central Directory record will always be present.
-
-The layout of the ZIP64 End of Central Directory record for all
-versions starting with 6.2 of this specification will follow the
-Version 2 format.  The Version 2 format is as follows:
-
-The first 48 bytes will remain identical to that of Version 1.
-The record signature for both Version 1 and Version 2 will be
-0x06064b50.  Immediately following the 48th byte, which identifies
-the end of the field known as the Offset of Start of Central
-Directory With Respect to the Starting Disk Number will begin the
-new fields defining Version 2 of this record.
-
-New fields for Version 2:
-
-Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value                 Size       Description
-          -----                 ----       -----------
-          Compression Method    2 bytes    Method used to compress the
-                                           Central Directory
-          Compressed Size       8 bytes    Size of the compressed data
-          Original   Size       8 bytes    Original uncompressed size
-          AlgId                 2 bytes    Encryption algorithm ID
-          BitLen                2 bytes    Encryption key length
-          Flags                 2 bytes    Encryption flags
-          HashID                2 bytes    Hash algorithm identifier
-          Hash Length           2 bytes    Length of hash data
-          Hash Data             (variable) Hash data
-
-The Compression Method accepts the same range of values as the
-corresponding field in the Central Header.
-
-The Compressed Size and Original Size values will not include the
-data of the Central Directory Signature which is compressed or
-encrypted.
-
-The AlgId, BitLen, and Flags fields accept the same range of values
-the corresponding fields within the 0x0017 record.
-
-Hash ID identifies the algorithm used to hash the Central Directory
-data.  This data does not have to be hashed, in which case the
-values for both the HashID and Hash Length will be 0.  Possible
-values for HashID are:
-
-      Value         Algorithm
-     ------         ---------
-     0x0000          none
-     0x0001          CRC32
-     0x8003          MD5
-     0x8004          SHA1
-
-When the Central Directory data is signed, the same hash algorithm
-used to hash the Central Directory for signing should be used.
-This is recommended for processing efficiency, however, it is
-permissible for any of the above algorithms to be used independent
-of the signing process.
-
-The Hash Data will contain the hash data for the Central Directory.
-The length of this data will vary depending on the algorithm used.
-
-The Version Needed to Extract should be set to 62.
-
-The value for the Total Number of Entries on the Current Disk will
-be 0.  These records will no longer support random access when
-encrypting the Central Directory.
-
-When the Central Directory is compressed and/or encrypted, the
-End of Central Directory record will store the value 0xFFFFFFFF
-as the value for the Total Number of Entries in the Central
-Directory.  The value stored in the Total Number of Entries in
-the Central Directory on this Disk field will be 0.  The actual
-values will be stored in the equivalent fields of the ZIP64
-End of Central Directory record.
-
-Decrypting and decompressing the Central Directory is accomplished
-in the same manner as decrypting and decompressing a file.
-
-
-5. Useful Tips
-
-Strong Encryption is always applied to a file after compression. The
-block oriented algorithms all operate in Cypher Block Chaining (CBC)
-mode.  The block size used for AES encryption is 16.  All other block
-algorithms use a block size of 8.  Two ID's are defined for RC2 to
-account for a discrepancy found in the implementation of the RC2
-algorithm in the cryptographic library on Windows XP SP1 and all
-earlier versions of Windows.
-
-A pseudo-code representation of the encryption process is as follows:
-
-Password = GetUserPassword()
-RD  = Random()
-ERD = Encrypt(RD,DeriveKey(SHA1(Password)))
-For Each File
-    IV = Random()
-    VData = Random()
-    FileSessionKey = DeriveKey(SHA1(IV + RD))
-    Encrypt(VData + VCRC32 + FileData,FileSessionKey)
-Done
-
-The function names and parameter requirements will depend on
-the choice of the cryptographic toolkit selected.  Almost any
-toolkit supporting the reference implementations for each
-algorithm can be used.  The RSA BSAFE(r), OpenSSL, and Microsoft
-CryptoAPI libraries are all known to work well.
-
-
-Certificate Processing Method:
------------------------------
-
-The Certificate Processing Method for ZIP file encryption remains
-under development.  The information provided here serves as a guide
-to those interested in certificate-based data decryption.  This
-information may be subject to change in future versions of this
-specification and is subject to change without notice.
-
-OAEP Processing with Certificate-based Encryption:
-
-Versions of PKZIP available during this development phase of the
-certificate processing method may set a value of 61 into the
-version needed to extract field for a file.  This indicates that
-non-OAEP key wrapping is used.  This affects certificate encryption
-only, and password encryption functions should not be affected by
-this value.  This means values of 61 may be found on files encrypted
-with certificates only, or on files encrypted with both password
-encryption and certificate encryption.  Files encrypted with both
-methods can safely be decrypted using the password methods documented.
-
-OAEP stands for Optimal Asymmetric Encryption Padding.  It is a
-strengthening technique used for small encoded items such as decryption
-keys.  This is commonly applied in cryptographic key-wrapping techniques
-and is supported by PKCS #1.  Versions 5.0 and 6.0 of this specification
-were designed to support OAEP key-wrapping for certificate-based
-decryption keys for additional security.
-
-Support for private keys stored on Smart Cards or Tokens introduced
-a conflict with this OAEP logic.  Most card and token products do
-not support the additional strengthening applied to OAEP key-wrapped
-data.  In order to resolve this conflict, versions 6.1 and above of this
-specification will no longer support OAEP when encrypting using
-digital certificates.
-
-Certificate Processing Data Fields:
-
-The Certificate Processing Method of this specification defines the
-following additional data fields:
-
-
-1. Certificate Flag Values
-
-Additional processing flags that can be present in the Flags field of both
-the 0x0017 field of the central directory Extra Field and the Decryption
-header record preceding compressed file data are:
-
-         0x0007 - reserved for future use
-         0x000F - reserved for future use
-         0x0100 - Indicates non-OAEP key wrapping was used.  If this
-                  this field is set, the version needed to extract must
-                  be at least 61.  This means OAEP key wrapping is not
-                  used when generating a Master Session Key using
-                  ErdData.
-         0x4000 - ErdData must be decrypted using 3DES-168, otherwise use the
-                  same algorithm used for encrypting the file contents.
-         0x8000 - reserved for future use
-
-
-2. CertData - Extra Field 0x0017 record certificate data structure
-
-The data structure used to store certificate data within the section
-of the Extra Field defined by the CertData field of the 0x0017
-record are as shown:
-
-          Value     Size     Description
-          -----     ----     -----------
-          RCount    4 bytes  Number of recipients.
-          HashAlg   2 bytes  Hash algorithm identifier
-          HSize     2 bytes  Hash size
-          SRList    (var)    Simple list of recipients hashed public keys
-
-
-     RCount    This defines the number intended recipients whose
-               public keys were used for encryption.  This identifies
-               the number of elements in the SRList.
-
-     HashAlg   This defines the hash algorithm used to calculate
-               the public key hash of each public key used
-               for encryption. This field currently supports
-               only the following value for SHA-1
-
-               0x8004 - SHA1
-
-     HSize     This defines the size of a hashed public key.
-
-     SRList    This is a variable length list of the hashed
-               public keys for each intended recipient.  Each
-               element in this list is HSize.  The total size of
-               SRList is determined using RCount * HSize.
-
-
-3. Reserved1 - Certificate Decryption Header Reserved1 Data:
-
-          Value     Size     Description
-          -----     ----     -----------
-          RCount    4 bytes  Number of recipients.
-
-     RCount    This defines the number intended recipients whose
-               public keys were used for encryption.  This defines
-               the number of elements in the REList field defined below.
-
-
-4. Reserved2 - Certificate Decryption Header Reserved2 Data Structures:
-
-
-          Value     Size     Description
-          -----     ----     -----------
-          HashAlg   2 bytes  Hash algorithm identifier
-          HSize     2 bytes  Hash size
-          REList    (var)    List of recipient data elements
-
-
-     HashAlg   This defines the hash algorithm used to calculate
-               the public key hash of each public key used
-               for encryption. This field currently supports
-               only the following value for SHA-1
-
-               0x8004 - SHA1
-
-     HSize     This defines the size of a hashed public key
-               defined in REHData.
-
-     REList    This is a variable length of list of recipient data.
-               Each element in this list consists of a Recipient
-               Element data structure as follows:
-
-
-    Recipient Element (REList) Data Structure:
-
-          Value     Size     Description
-          -----     ----     -----------
-          RESize    2 bytes  Size of REHData + REKData
-          REHData   HSize    Hash of recipients public key
-          REKData   (var)    Simple key blob
-
-
-     RESize    This defines the size of an individual REList
-               element.  This value is the combined size of the
-               REHData field + REKData field.  REHData is defined by
-               HSize.  REKData is variable and can be calculated
-               for each REList element using RESize and HSize.
-
-     REHData   Hashed public key for this recipient.
-
-     REKData   Simple Key Blob.  The format of this data structure
-               is identical to that defined in the Microsoft
-               CryptoAPI and generated using the CryptExportKey()
-               function.  The version of the Simple Key Blob
-               supported at this time is 0x02 as defined by
-               Microsoft.
-
-5. Certificate Processing - Central Directory Encryption:
-
-Central Directory Encryption using Digital Certificates will
-operate in a manner similar to that of Single Password Central
-Directory Encryption.  This record will only be present when there
-is data to place into it.  Currently, data is placed into this
-record when digital certificates are used for either encrypting
-or signing the files within a ZIP file.  When only password
-encryption is used with no certificate encryption or digital
-signing, this record is not currently needed. When present, this
-record will appear before the start of the actual Central Directory
-data structure and will be located immediately after the Archive
-Decryption Header if the Central Directory is encrypted.
-
-The Archive Extra Data record will be used to store the following
-information.  Additional data may be added in future versions.
-
-Extra Data Fields:
-
-0x0014 - PKCS#7 Store for X.509 Certificates
-0x0016 - X.509 Certificate ID and Signature for central directory
-0x0019 - PKCS#7 Encryption Recipient Certificate List
-
-The 0x0014 and 0x0016 Extra Data records that otherwise would be
-located in the first record of the Central Directory for digital
-certificate processing. When encrypting or compressing the Central
-Directory, the 0x0014 and 0x0016 records must be located in the
-Archive Extra Data record and they should not remain in the first
-Central Directory record.  The Archive Extra Data record will also
-be used to store the 0x0019 data.
-
-When present, the size of the Archive Extra Data record will be
-included in the size of the Central Directory.  The data of the
-Archive Extra Data record will also be compressed and encrypted
-along with the Central Directory data structure.
-
-6. Certificate Processing Differences:
-
-The Certificate Processing Method of encryption differs from the
-Single Password Symmetric Encryption Method as follows.  Instead
-of using a user-defined password to generate a master session key,
-cryptographically random data is used.  The key material is then
-wrapped using standard key-wrapping techniques.  This key material
-is wrapped using the public key of each recipient that will need
-to decrypt the file using their corresponding private key.
-
-This specification currently assumes digital certificates will follow
-the X.509 V3 format for 1024 bit and higher RSA format digital
-certificates.  Implementation of this Certificate Processing Method
-requires supporting logic for key access and management.  This logic
-is outside the scope of this specification.
-
-
-License Agreement:
------------------
-
-The features set forth in this Section XIV (the "Strong Encryption
-Specification") are covered by a pending patent application. Portions of
-this Strong Encryption technology are available for use at no charge
-under the following terms and conditions.
-
-1. License Grant.
-
-   a. NOTICE TO USER. PLEASE READ THIS ENTIRE SECTION XIV OF THE
-   APPNOTE (THE "AGREEMENT") CAREFULLY. BY USING ALL OR ANY PORTION OF THE
-   LICENSED TECHNOLOGY, YOU ACCEPT ALL THE TERMS AND CONDITIONS OF THIS
-   AGREEMENT AND YOU AGREE THAT THIS AGREEMENT IS ENFORCEABLE LIKE ANY
-   WRITTEN NEGOTIATED AGREEMENT SIGNED BY YOU. IF YOU DO NOT AGREE, DO NOT
-   USE THE LICENSED TECHNOLOGY.
-
-   b. Definitions.
-
-      i. "Licensed Technology" shall mean that proprietary technology now or
-      hereafter owned or controlled by PKWare, Inc. ("PKWARE") or any
-      subsidiary or affiliate  that covers or is necessary to be used to give
-      software the ability to a) extract and decrypt data from zip files
-      encrypted using any methods of data encryption and key processing which
-      are published in this APPNOTE or any prior APPNOTE, as supplemented by
-      any Additional Compatibility Information; and b) encrypt file contents
-      as part of .ZIP file processing using only the Single Password Symmetric
-      Encryption Method as published in this APPNOTE or any prior APPNOTE, as
-      supplemented by any Additional Compatibility Information.  For purposes
-      of this AGREEMENT, "Additional Compatibility Information" means, with
-      regard to any method of data encryption and key processing published in
-      this or any prior APPNOTE, any corrections, additions, or clarifications
-      to the information in such APPNOTE that are required in order to give
-      software the ability to successfully extract and decrypt zip files (or,
-      but solely in the case of the Single Password Symmetric Encryption Method,
-      to successfully encrypt zip files) in a manner interoperable with the
-      actual implementation of such method in any PKWARE product that is
-      documented or publicly described by PKWARE as being able to create, or
-      to extract and decrypt, zip files using that method.
-
-      ii. "Licensed Products" shall mean any products you produce that
-      incorporate the Licensed Technology.
-
-   c. License to Licensed Technology.
-
-   PKWARE hereby grants to you a non-exclusive license to use the Licensed
-   Technology for the purpose of manufacturing, offering, selling and using
-   Licensed Products, which license shall extend to permit the practice of all
-   claims in any patent or patent application (collectively, "Patents") now or
-   hereafter owned or controlled by PKWARE in any jurisdiction in the world
-   that are infringed by implementation of the Licensed Technology.  You have
-   the right to sublicense rights you receive under the terms of this AGREEMENT
-   for the purpose of allowing sublicensee to manufacture, offer, sell and use
-   products that incorporate all or a portion of any of your Licensed Products,
-   but if you do, you agree to i) impose the same restrictions on any such
-   sublicensee as these terms impose on you and ii) notify the sublicensee,
-   by means chosen by you in your unfettered discretion, including a notice on
-   your web site, of the terms of this AGREEMENT and make available to each
-   sublicensee the full text of this APPNOTE.   Further, PKWARE hereby grants to
-   you a non-exclusive right to reproduce and distribute, in any form, copies of
-   this APPNOTE, without modification.  Notwithstanding anything to the contrary
-   in this AGREEMENT, you have the right to sublicense the rights, without any of
-   the restrictions described above or elsewhere in this AGREEMENT, to use, offer
-   to sell and sell Licensed Technology as incorporated in executable object code
-   or byte code forms of your Licensed Products.  Any sublicense to use the
-   Licensed Technology incorporated in a Licensed Product granted by you shall
-   survive the termination of this AGREEMENT for any reason.  PKWARE warrants that
-   this license shall continue to encumber the Licensed Technology regardless of
-   changes in ownership of the Licensed Technology.
-
-   d. Proprietary Notices.
-
-      i. With respect to any Licensed Product that is distributed by you either
-      in source code form or in the form of an object code library of externally
-      callable functions that has been designed by you for incorporation into third
-      party products, you agree to include, in the source code, or in the case of
-      an object code library, in accompanying documentation, a notice using the
-      words "patent pending" until a patent is issued to PKWARE covering any
-      portion of the Licensed Technology or PKWARE provides notice, by means
-      chosen by PKWARE in its unfettered discretion, that it no longer has any
-      patent pending covering any portion of the Licensed Technology.  With respect
-      to any Licensed Product, upon your becoming aware that at least one patent has
-      been granted covering the Licensed Technology, you agree to include in any
-      revisions made by you to the documentation (or any source code distributed
-      by you) the words "Pat. No.", or "Patent Number" and the patent number or
-      numbers of the applicable patent or patents.  PKWARE shall, from time to time,
-      inform you of the patent number or numbers of the patents covering the
-      Licensed Technology, by means chosen by PKWARE in its unfettered discretion,
-      including a notice on its web site.  It shall be a violation of the terms of
-      this AGREEMENT for you to sell Licensed Products without complying with the
-      foregoing marking provisions.
-
-      ii. You acknowledge that the terms of this AGREEMENT do not grant you any
-      license or other right to use any PKWARE trademark in connection with the sale,
-      offering for sale, distribution and delivery of the Licensed Products, or in
-      connection with the advertising, promotion and offering of the Licensed Products.
-      You acknowledge PKWARE's ownership of the PKZIP trademark and all other marks
-      owned by PKWARE.
-
-   e. Covenant of Compliance and Remedies.
-
-   To the extent that you have elected to implement portions of the Licensed
-   Technology, you agree to use reasonable diligence to comply with those portions
-   of this Section XIV, as modified or supplemented by Additional Compatibility
-   Information available to you, describing the portions of the Licensed Technology
-   that you have elected to implement.  Upon reasonable request by PKWARE, you will
-   provide written notice to PKWARE identifying which version of this APPNOTE you
-   have relied upon for your implementation of any specified Licensed Product.
-
-   If any substantial non-compliance with the terms of this AGREEMENT is determined
-   to exist, you will make such changes as necessary to bring your Licensed Products
-   into substantial compliance with the terms of this AGREEMENT.  If, within sixty
-   days of receipt of notice that a Licensed Product fails to comply with the terms
-   of this AGREEMENT, you fail to make such changes as necessary to bring your
-   Licensed Products into compliance with the terms of this AGREEMENT, PKWARE may
-   terminate your rights under this AGREEMENT.  PKWARE does not waive and expressly
-   reserves the right to pursue any and all additional remedies that are or may
-   become available to PKWARE.
-
-   f. Warranty and Indemnification Regarding Exportation.
-
-   You realize and acknowledge that, as between yourself and PKWARE, you are fully
-   responsible for compliance with the import and export laws and regulations of
-   any country in or to which you import or export any Licensed Products, and you
-   agree to hold PKWARE harmless from any claim of violation of any such import
-   or export laws.
-
-   g. Patent Infringement.
-
-   You agree that you will not bring or threaten to bring any action against PKWARE
-   for infringement of the claims of any patent owned or controlled by you solely
-   as a result of PKWARE's own implementation of the Licensed Technology.  As its
-   exclusive remedy for your breach of the foregoing agreement, PKWARE reserves
-   the right to suspend or terminate all rights granted under the terms of this
-   AGREEMENT if you bring or threaten to bring any such action against PKWARE,
-   effective immediately upon delivery of written notice of suspension or
-   termination to you.
-
-   h. Governing Law.
-
-   The license granted in this AGREEMENT shall be governed by and construed under
-   the laws of the State of Wisconsin and the United States.
-
-   i. Revisions and Notice.
-
-   The license granted in this APPNOTE is irrevocable, except as expressly set
-   forth above.  You agree and understand that any changes which PKWARE determines
-   to make to this APPNOTE shall be posted at the same location as the current
-   APPNOTE or at a location which will be identified by means chosen by PKWARE,
-   including a notice on its web site, and shall be available for adoption by you
-   immediately upon such posting, or at such other time as PKWARE shall determine.
-   Any changes to the terms of the license published in a subsequent version of
-   this AGREEMENT shall be binding upon you only with respect to your products
-   that (i) incorporate any Licensed Technology (as defined in the subsequent
-   AGREEMENT) that is not otherwise included in the definition of Licensed
-   Technology under this AGREEMENT, or (ii) that you expressly identify are to
-   be licensed under the subsequent AGREEMENT, which identification shall be by
-   written notice with reference to the APPNOTE (version and release date or other
-   unique identifier) in which the subsequent AGREEMENT is published.  PKWARE
-   agrees to identify each change to this APPNOTE by using a unique version and
-   release date identifier or other unique identifier.
-
-   j. Warranty by PKWARE
-
-   PKWare, Inc. warrants that it has the right to grant the license hereunder.
-
-XV. Change Process
-------------------
-
-In order for the .ZIP file format to remain a viable definition, this
-specification should be considered as open for periodic review and
-revision.  Although this format was originally designed with a
-certain level of extensibility, not all changes in technology
-(present or future) were or will be necessarily considered in its
-design.  If your application requires new definitions to the
-extensible sections in this format, or if you would like to
-submit new data structures, please forward your request to
-zipformat@pkware.com.  All submissions will be reviewed by the
-ZIP File Specification Committee for possible inclusion into
-future versions of this specification.  Periodic revisions
-to this specification will be published to ensure interoperability.
-We encourage comments and feedback that may help improve clarity
-or content.
-
-
-XVI. Acknowledgements
----------------------
-
-In addition to the above mentioned contributors to PKZIP and PKUNZIP,
-I would like to extend special thanks to Robert Mahoney for suggesting
-the extension .ZIP for this software.
-
-
-XVII. References
-----------------
-
-    Fiala, Edward R., and Greene, Daniel H., "Data compression with
-       finite windows",  Communications of the ACM, Volume 32, Number 4,
-       April 1989, pages 490-505.
-
-    Held, Gilbert, "Data Compression, Techniques and Applications,
-       Hardware and Software Considerations", John Wiley & Sons, 1987.
-
-    Huffman, D.A., "A method for the construction of minimum-redundancy
-       codes", Proceedings of the IRE, Volume 40, Number 9, September 1952,
-       pages 1098-1101.
-
-    Nelson, Mark, "LZW Data Compression", Dr. Dobbs Journal, Volume 14,
-       Number 10, October 1989, pages 29-37.
-
-    Nelson, Mark, "The Data Compression Book",  M&T Books, 1991.
-
-    Storer, James A., "Data Compression, Methods and Theory",
-       Computer Science Press, 1988
-
-    Welch, Terry, "A Technique for High-Performance Data Compression",
-       IEEE Computer, Volume 17, Number 6, June 1984, pages 8-19.
-
-    Ziv, J. and Lempel, A., "A universal algorithm for sequential data
-       compression", Communications of the ACM, Volume 30, Number 6,
-       June 1987, pages 520-540.
-
-    Ziv, J. and Lempel, A., "Compression of individual sequences via
-       variable-rate coding", IEEE Transactions on Information Theory,
-       Volume 24, Number 5, September 1978, pages 530-536.
diff --git a/docs/appnote.txt b/docs/appnote.txt
deleted file mode 100644
index 985f6f8..0000000
--- a/docs/appnote.txt
+++ /dev/null
@@ -1,3497 +0,0 @@
-File:    APPNOTE.TXT - .ZIP File Format Specification
-Version: 6.3.4 
-Status: Final - replaces version 6.3.3
-Revised: October 1, 2014
-Copyright (c) 1989 - 2014 PKWARE Inc., All Rights Reserved.
-
-1.0 Introduction
----------------
-
-1.1 Purpose
------------
-
-   1.1.1 This specification is intended to define a cross-platform,
-   interoperable file storage and transfer format.  Since its 
-   first publication in 1989, PKWARE, Inc. ("PKWARE") has remained 
-   committed to ensuring the interoperability of the .ZIP file 
-   format through periodic publication and maintenance of this 
-   specification.  We trust that all .ZIP compatible vendors and 
-   application developers that use and benefit from this format 
-   will share and support this commitment to interoperability.
-
-1.2 Scope
----------
-
-   1.2.1 ZIP is one of the most widely used compressed file formats. It is 
-   universally used to aggregate, compress, and encrypt files into a single
-   interoperable container. No specific use or application need is 
-   defined by this format and no specific implementation guidance is 
-   provided. This document provides details on the storage format for 
-   creating ZIP files.  Information is provided on the records and 
-   fields that describe what a ZIP file is. 
-
-1.3 Trademarks
---------------
-
-   1.3.1 PKWARE, PKZIP, SecureZIP, and PKSFX are registered trademarks of 
-   PKWARE, Inc. in the United States and elsewhere.  PKPatchMaker, 
-   Deflate64, and ZIP64 are trademarks of PKWARE, Inc.  Other marks 
-   referenced within this document appear for identification
-   purposes only and are the property of their respective owners.
-   
-
-1.4 Permitted Use
------------------ 
-
-   1.4.1 This document, "APPNOTE.TXT -  .ZIP File Format Specification" is the
-   exclusive property of PKWARE.  Use of the information contained in this 
-   document is permitted solely for the purpose of creating products, 
-   programs and processes that read and write files in the ZIP format
-   subject to the terms and conditions herein.
-
-   1.4.2 Use of the content of this document within other publications is 
-   permitted only through reference to this document.  Any reproduction
-   or distribution of this document in whole or in part without prior
-   written permission from PKWARE is strictly prohibited.
-
-   1.4.3 Certain technological components provided in this document are the 
-   patented proprietary technology of PKWARE and as such require a 
-   separate, executed license agreement from PKWARE.  Applicable 
-   components are marked with the following, or similar, statement: 
-   'Refer to the section in this document entitled  "Incorporating 
-   PKWARE Proprietary Technology into Your Product" for more information'.
-
-1.5 Contacting PKWARE
----------------------
-
-   1.5.1 If you have questions on this format, its use, or licensing, or if you 
-   wish to report defects, request changes or additions, please contact:
-
-     PKWARE, Inc.
-     201 E. Pittsburgh Avenue, Suite 400
-     Milwaukee, WI 53204
-     +1-414-289-9788
-     +1-414-289-9789 FAX
-     zipformat@pkware.com
-
-   1.5.2 Information about this format and copies of this document are publicly
-   available at:
-
-     http://www.pkware.com/appnote
-
-1.6 Disclaimer
---------------
-
-   1.6.1 Although PKWARE will attempt to supply current and accurate
-   information relating to its file formats, algorithms, and the
-   subject programs, the possibility of error or omission cannot 
-   be eliminated. PKWARE therefore expressly disclaims any warranty 
-   that the information contained in the associated materials relating 
-   to the subject programs and/or the format of the files created or
-   accessed by the subject programs and/or the algorithms used by
-   the subject programs, or any other matter, is current, correct or
-   accurate as delivered.  Any risk of damage due to any possible
-   inaccurate information is assumed by the user of the information.
-   Furthermore, the information relating to the subject programs
-   and/or the file formats created or accessed by the subject
-   programs and/or the algorithms used by the subject programs is
-   subject to change without notice.
-
-2.0 Revisions
---------------
-
-2.1 Document Status
---------------------
-
-   2.1.1 If the STATUS of this file is marked as DRAFT, the content 
-   defines proposed revisions to this specification which may consist 
-   of changes to the ZIP format itself, or that may consist of other 
-   content changes to this document.  Versions of this document and 
-   the format in DRAFT form may be subject to modification prior to 
-   publication STATUS of FINAL. DRAFT versions are published periodically 
-   to provide notification to the ZIP community of pending changes and to 
-   provide opportunity for review and comment.
-
-   2.1.2 Versions of this document having a STATUS of FINAL are 
-   considered to be in the final form for that version of the document 
-   and are not subject to further change until a new, higher version
-   numbered document is published.  Newer versions of this format 
-   specification are intended to remain interoperable with with all prior 
-   versions whenever technically possible.  
-
-2.2 Change Log
---------------
-
-   Version       Change Description                        Date
-   -------       ------------------                       ----------
-   5.2           -Single Password Symmetric Encryption    06/02/2003
-                  storage
-
-   6.1.0         -Smartcard compatibility                 01/20/2004
-                 -Documentation on certificate storage
-
-   6.2.0         -Introduction of Central Directory       04/26/2004
-                  Encryption for encrypting metadata
-                 -Added OS X to Version Made By values
-
-   6.2.1         -Added Extra Field placeholder for       04/01/2005
-                  POSZIP using ID 0x4690
-
-                 -Clarified size field on 
-                  "zip64 end of central directory record"
-
-   6.2.2         -Documented Final Feature Specification  01/06/2006
-                  for Strong Encryption
-
-                 -Clarifications and typographical 
-                  corrections
-
-   6.3.0         -Added tape positioning storage          09/29/2006
-                  parameters
-
-                 -Expanded list of supported hash algorithms
-
-                 -Expanded list of supported compression
-                  algorithms
-
-                 -Expanded list of supported encryption
-                  algorithms
-
-                 -Added option for Unicode filename 
-                  storage
-
-                 -Clarifications for consistent use
-                  of Data Descriptor records
-
-                 -Added additional "Extra Field" 
-                  definitions
-
-   6.3.1         -Corrected standard hash values for      04/11/2007
-                  SHA-256/384/512
-
-   6.3.2         -Added compression method 97             09/28/2007
-
-                 -Documented InfoZIP "Extra Field"
-                  values for UTF-8 file name and
-                  file comment storage
-
-   6.3.3         -Formatting changes to support           09/01/2012
-                  easier referencing of this APPNOTE
-                  from other documents and standards        
-
-   6.3.4         -Address change                          10/01/2014
-
-
-3.0 Notations
--------------
-
-   3.1 Use of the term MUST or SHALL indicates a required element. 
-
-   3.2 MAY NOT or SHALL NOT indicates an element is prohibited from use. 
-
-   3.3 SHOULD indicates a RECOMMENDED element.
-
-   3.4 SHOULD NOT indicates an element NOT RECOMMENDED for use.
-   
-   3.5 MAY indicates an OPTIONAL element.
-
-
-4.0 ZIP Files
--------------
-
-4.1 What is a ZIP file
-----------------------
-
-   4.1.1 ZIP files MAY be identified by the standard .ZIP file extension 
-   although use of a file extension is not required.  Use of the 
-   extension .ZIPX is also recognized and MAY be used for ZIP files.  
-   Other common file extensions using the ZIP format include .JAR, .WAR, 
-   .DOCX, .XLXS, .PPTX, .ODT, .ODS, .ODP and others. Programs reading or 
-   writing ZIP files SHOULD rely on internal record signatures described 
-   in this document to identify files in this format.
-
-   4.1.2 ZIP files SHOULD contain at least one file and MAY contain 
-   multiple files.  
-
-   4.1.3 Data compression MAY be used to reduce the size of files
-   placed into a ZIP file, but is not required.  This format supports the 
-   use of multiple data compression algorithms.  When compression is used, 
-   one of the documented compression algorithms MUST be used.  Implementors 
-   are advised to experiment with their data to determine which of the 
-   available algorithms provides the best compression for their needs.
-   Compression method 8 (Deflate) is the method used by default by most 
-   ZIP compatible application programs.  
-
-
-   4.1.4 Data encryption MAY be used to protect files within a ZIP file. 
-   Keying methods supported for encryption within this format include
-   passwords and public/private keys.  Either MAY be used individually
-   or in combination. Encryption MAY be applied to individual files.  
-   Additional security MAY be used through the encryption of ZIP file 
-   metadata stored within the Central Directory. See the section on the 
-   Strong Encryption Specification for information. Refer to the section 
-   in this document entitled "Incorporating PKWARE Proprietary Technology 
-   into Your Product" for more information.
-
-   4.1.5 Data integrity MUST be provided for each file using CRC32.  
-   
-   4.1.6 Additional data integrity MAY be included through the use of 
-   digital signatures.  Individual files MAY be signed with one or more 
-   digital signatures. The Central Directory, if signed, MUST use a 
-   single signature.  
-
-   4.1.7 Files MAY be placed within a ZIP file uncompressed or stored. 
-   The term "stored" as used in the context of this document means the file 
-   is copied into the ZIP file uncompressed.  
-
-   4.1.8 Each data file placed into a ZIP file MAY be compressed, stored, 
-   encrypted or digitally signed independent of how other data files in the 
-   same ZIP file are archived.
-
-   4.1.9 ZIP files MAY be streamed, split into segments (on fixed or on
-   removable media) or "self-extracting".  Self-extracting ZIP 
-   files MUST include extraction code for a target platform within 
-   the ZIP file.  
-
-   4.1.10 Extensibility is provided for platform or application specific
-   needs through extra data fields that MAY be defined for custom
-   purposes.  Extra data definitions MUST NOT conflict with existing
-   documented record definitions.  
-
-   4.1.11 Common uses for ZIP MAY also include the use of manifest files.  
-   Manifest files store application specific information within a file stored 
-   within the ZIP file.  This manifest file SHOULD be the first file in the 
-   ZIP file. This specification does not provide any information or guidance on 
-   the use of manifest files within ZIP files.  Refer to the application developer
-   for information on using manifest files and for any additional profile
-   information on using ZIP within an application.
-
-   4.1.12 ZIP files MAY be placed within other ZIP files.
-
-4.2 ZIP Metadata
-----------------
-
-   4.2.1 ZIP files are identified by metadata consisting of defined record types 
-   containing the storage information necessary for maintaining the files 
-   placed into a ZIP file.  Each record type MUST be identified using a header 
-   signature that identifies the record type.  Signature values begin with the 
-   two byte constant marker of 0x4b50, representing the characters "PK".
-
-
-4.3 General Format of a .ZIP file
----------------------------------
-
-   4.3.1 A ZIP file MUST contain an "end of central directory record". A ZIP 
-   file containing only an "end of central directory record" is considered an 
-   empty ZIP file.  Files may be added or replaced within a ZIP file, or deleted. 
-   A ZIP file MUST have only one "end of central directory record".  Other 
-   records defined in this specification MAY be used as needed to support 
-   storage requirements for individual ZIP files.
-
-   4.3.2 Each file placed into a ZIP file MUST be preceeded by  a "local 
-   file header" record for that file.  Each "local file header" MUST be 
-   accompanied by a corresponding "central directory header" record within 
-   the central directory section of the ZIP file.
-
-   4.3.3 Files MAY be stored in arbitrary order within a ZIP file.  A ZIP 
-   file MAY span multiple volumes or it MAY be split into user-defined 
-   segment sizes. All values MUST be stored in little-endian byte order unless 
-   otherwise specified in this document for a specific data element. 
-
-   4.3.4 Compression MUST NOT be applied to a "local file header", an "encryption
-   header", or an "end of central directory record".  Individual "central 
-   directory records" must not be compressed, but the aggregate of all central
-   directory records MAY be compressed.    
-
-   4.3.5 File data MAY be followed by a "data descriptor" for the file.  Data 
-   descriptors are used to facilitate ZIP file streaming.  
-
- 
-   4.3.6 Overall .ZIP file format:
-
-      [local file header 1]
-      [encryption header 1]
-      [file data 1]
-      [data descriptor 1]
-      . 
-      .
-      .
-      [local file header n]
-      [encryption header n]
-      [file data n]
-      [data descriptor n]
-      [archive decryption header] 
-      [archive extra data record] 
-      [central directory header 1]
-      .
-      .
-      .
-      [central directory header n]
-      [zip64 end of central directory record]
-      [zip64 end of central directory locator] 
-      [end of central directory record]
-
-
-   4.3.7  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)
-
-   4.3.8  File data
-
-      Immediately following the local header for a file
-      SHOULD be placed the compressed or stored data for the file.
-      If the file is encrypted, the encryption header for the file 
-      SHOULD be placed after the local header and before the file 
-      data. The series of [local file header][encryption header]
-      [file data][data descriptor] repeats for each file in the 
-      .ZIP archive. 
-
-      Zero-byte files, directories, and other file types that 
-      contain no content MUST not include file data.
-
-   4.3.9  Data descriptor:
-
-        crc-32                          4 bytes
-        compressed size                 4 bytes
-        uncompressed size               4 bytes
-
-      4.3.9.1 This descriptor MUST exist 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 SHOULD be 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.
-
-      4.3.9.2 When compressing files, compressed and uncompressed sizes 
-      should be stored in ZIP64 format (as 8 byte values) when a 
-      file's 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.  
-
-      4.3.9.3 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.
-
-      4.3.9.4 When writing ZIP files, implementors SHOULD 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.
-
-      4.3.9.5 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.
-
-      4.3.9.6 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 MUST be set to binary zeros.  See the section on the Strong 
-      Encryption Specification for information. Refer to the section in 
-      this document entitled "Incorporating PKWARE Proprietary Technology 
-      into Your Product" for more information.
-
-
-   4.3.10  Archive decryption header:  
-
-      4.3.10.1 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 MUST precede the encrypted data segment.  
-
-      4.3.10.2 The encrypted data segment SHALL 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.  See the 
-      section on the Strong Encryption Specification for information
-      on the fields used in the Archive Decryption Header record.
-      Refer to the section in this document entitled "Incorporating 
-      PKWARE Proprietary Technology into Your Product" for more information.
-
-
-   4.3.11  Archive extra data record: 
-
-        archive extra data signature    4 bytes  (0x08064b50)
-        extra field length              4 bytes
-        extra field data                (variable size)
-
-      4.3.11.1 The Archive Extra Data Record is introduced in version 6.2
-      of the ZIP format specification.  This record MAY be used 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 MUST immediately precede the central 
-      directory data structure.  
-
-      4.3.11.2 The size of this data record SHALL 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. Refer to the section in this document 
-      entitled "Incorporating PKWARE Proprietary Technology into Your 
-      Product" for more information.
-
-   4.3.12  Central directory structure:
-
-      [central directory header 1]
-      .
-      .
-      . 
-      [central directory 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)
-
-   4.3.13 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.
-
-   4.3.14  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)
-
-      4.3.14.1 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.
-
-      4.3.14.2 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. Refer to the section in this document entitled 
-      "Incorporating PKWARE Proprietary Technology into Your Product"
-      for more information applicable to use of Version 2 of this
-      record.
-
-      4.3.14.3 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.
-
-      4.3.14.4 Multiple special purpose data blocks MAY be present. 
-      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.
-
-   4.3.15 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
-        
-   4.3.16  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)
-                
-4.4  Explanation of fields
---------------------------
-      
-   4.4.1 General notes on fields
-
-      4.4.1.1  All fields unless otherwise noted are unsigned and stored
-      in Intel low-byte:high-byte, low-word:high-word order.
-
-      4.4.1.2  String fields are not null terminated, since the length 
-      is given explicitly.
-
-      4.4.1.3  The entries in the central directory may not necessarily
-      be in the same order that files appear in the .ZIP file.
-
-      4.4.1.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.
-
-      4.4.1.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.
-
-   4.4.2 version made by (2 bytes)
-
-        4.4.2.1 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.  
-
-        4.4.2.2 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
-
-        4.4.2.3 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.  
-
-   4.4.3 version needed to extract (2 bytes)
-
-        4.4.3.1 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 MUST 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.
-
-        4.4.3.2 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
-
-        4.4.3.3 Notes on version needed to extract 
-
-        * Early 7.x (pre-7.2) versions of PKZIP incorrectly set the
-        version needed to extract for BZIP2 compression to be 50
-        when it should have been 46.
-
-        ** Refer to the section on Strong Encryption Specification
-        for additional information regarding RC2 corrections.
-
-        *** Certificate encryption using non-OAEP key wrapping is the
-        intended mode of operation for all versions beginning with 6.1.
-        Support for OAEP key wrapping MUST only be used for
-        backward compatibility when sending ZIP files to be opened by
-        versions of PKZIP older than 6.1 (5.0 or 6.0).
-
-        + Files compressed using PPMd MUST set the version
-        needed to extract field to 6.3, however, not all ZIP 
-        programs enforce this and may be unable to decompress 
-        data files compressed using PPMd if this value is set.
-
-        When using ZIP64 extensions, the corresponding value in the
-        zip64 end of central directory record MUST also be set.  
-        This field should be set appropriately to indicate whether 
-        Version 1 or Version 2 format is in use. 
-
-
-   4.4.4 general purpose bit flag: (2 bytes)
-
-        Bit 0: If set, indicates that the file is encrypted.
-
-        (For Method 6 - Imploding)
-        Bit 1: If the compression method used was type 6,
-               Imploding, then this bit, if set, indicates
-               an 8K sliding dictionary was used.  If clear,
-               then a 4K sliding dictionary was used.
-
-        Bit 2: If the compression method used was type 6,
-               Imploding, then this bit, if set, indicates
-               3 Shannon-Fano trees were used to encode the
-               sliding dictionary output.  If clear, then 2
-               Shannon-Fano trees were used.
-
-        (For Methods 8 and 9 - Deflating)
-        Bit 2  Bit 1
-          0      0    Normal (-en) compression option was used.
-          0      1    Maximum (-exx/-ex) compression option was used.
-          1      0    Fast (-ef) compression option was used.
-          1      1    Super Fast (-es) compression option was used.
-
-        (For Method 14 - LZMA)
-        Bit 1: If the compression method used was type 14,
-               LZMA, then this bit, if set, indicates
-               an end-of-stream (EOS) marker is used to
-               mark the end of the compressed data stream.
-               If clear, then an EOS marker is not present
-               and the compressed data size must be known
-               to extract.
-
-        Note:  Bits 1 and 2 are undefined if the compression
-               method is any other.
-
-        Bit 3: If this bit is set, the fields crc-32, compressed 
-               size and uncompressed size are set to zero in the 
-               local header.  The correct values are put in the 
-               data descriptor immediately following the compressed
-               data.  (Note: PKZIP version 2.04g for DOS only 
-               recognizes this bit for method 8 compression, newer 
-               versions of PKZIP recognize this bit for any 
-               compression method.)
-
-        Bit 4: Reserved for use with method 8, for enhanced
-               deflating. 
-
-        Bit 5: If this bit is set, this indicates that the file is 
-               compressed patched data.  (Note: Requires PKZIP 
-               version 2.70 or greater)
-
-        Bit 6: Strong encryption.  If this bit is set, you MUST
-               set the version needed to extract value to at least
-               50 and you MUST also set bit 0.  If AES encryption
-               is used, the version needed to extract value MUST 
-               be at least 51. See the section describing the Strong
-               Encryption Specification for details.  Refer to the 
-               section in this document entitled "Incorporating PKWARE 
-               Proprietary Technology into Your Product" for more 
-               information.
-
-        Bit 7: Currently unused.
-
-        Bit 8: Currently unused.
-
-        Bit 9: Currently unused.
-
-        Bit 10: Currently unused.
-
-        Bit 11: Language encoding flag (EFS).  If this bit is set,
-                the filename and comment fields for this file
-                MUST be encoded using UTF-8. (see APPENDIX D)
-
-        Bit 12: Reserved by PKWARE for enhanced compression.
-
-        Bit 13: Set when encrypting the Central Directory to indicate 
-                selected data values in the Local Header are masked to
-                hide their actual values.  See the section describing 
-                the Strong Encryption Specification for details.  Refer
-                to the section in this document entitled "Incorporating 
-                PKWARE Proprietary Technology into Your Product" for 
-                more information.
-
-        Bit 14: Reserved by PKWARE.
-
-        Bit 15: Reserved by PKWARE.
-
-   4.4.5 compression method: (2 bytes)
-
-        0 - The file is stored (no compression)
-        1 - The file is Shrunk
-        2 - The file is Reduced with compression factor 1
-        3 - The file is Reduced with compression factor 2
-        4 - The file is Reduced with compression factor 3
-        5 - The file is Reduced with compression factor 4
-        6 - The file is Imploded
-        7 - Reserved for Tokenizing compression algorithm
-        8 - The file is Deflated
-        9 - Enhanced Deflating using Deflate64(tm)
-       10 - PKWARE Data Compression Library Imploding (old IBM TERSE)
-       11 - Reserved by PKWARE
-       12 - File is compressed using BZIP2 algorithm
-       13 - Reserved by PKWARE
-       14 - LZMA (EFS)
-       15 - Reserved by PKWARE
-       16 - Reserved by PKWARE
-       17 - Reserved by PKWARE
-       18 - File is compressed using IBM TERSE (new)
-       19 - IBM LZ77 z Architecture (PFS)
-       97 - WavPack compressed data
-       98 - PPMd version I, Rev 1
-
-
-   4.4.6 date and time fields: (2 bytes each)
-
-       The date and time are encoded in standard MS-DOS format.
-       If input came from standard input, the date and time are
-       those at which compression was started for this data. 
-       If encrypting the central directory and general purpose bit 
-       flag 13 is set indicating masking, the value stored in the 
-       Local Header will be zero. 
-
-   4.4.7 CRC-32: (4 bytes)
-
-       The CRC-32 algorithm was generously contributed by
-       David Schwaderer and can be found in his excellent
-       book "C Programmers Guide to NetBIOS" published by
-       Howard W. Sams & Co. Inc.  The 'magic number' for
-       the CRC is 0xdebb20e3.  The proper CRC pre and post
-       conditioning is used, meaning that the CRC register
-       is pre-conditioned with all ones (a starting value
-       of 0xffffffff) and the value is post-conditioned by
-       taking the one's complement of the CRC residual.
-       If bit 3 of the general purpose flag is set, this
-       field is set to zero in the local header and the correct
-       value is put in the data descriptor and in the central
-       directory. When encrypting the central directory, if the
-       local header is not in ZIP64 format and general purpose 
-       bit flag 13 is set indicating masking, the value stored 
-       in the Local Header will be zero. 
-
-   4.4.8 compressed size: (4 bytes)
-   4.4.9 uncompressed size: (4 bytes)
-
-       The size of the file compressed (4.4.8) and uncompressed,
-       (4.4.9) respectively.  When a decryption header is present it 
-       will be placed in front of the file data and the value of the
-       compressed file size will include the bytes of the decryption
-       header.  If bit 3 of the general purpose bit flag is set, 
-       these fields are set to zero in the local header and the 
-       correct values are put in the data descriptor and
-       in the 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 extended information 
-       extra field.  When encrypting the central directory, if the
-       local header is not in ZIP64 format and general purpose bit 
-       flag 13 is set indicating masking, the value stored for the 
-       uncompressed size in the Local Header will be zero. 
-
-   4.4.10 file name length: (2 bytes)
-   4.4.11 extra field length: (2 bytes)
-   4.4.12 file comment length: (2 bytes)
-
-       The length of the file name, extra field, and comment
-       fields respectively.  The combined length of any
-       directory record and these three fields should not
-       generally exceed 65,535 bytes.  If input came from standard
-       input, the file name length is set to zero.  
-
-
-   4.4.13 disk number start: (2 bytes)
-
-       The number of the disk on which this file begins.  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 
-       extended information extra field.
-
-   4.4.14 internal file attributes: (2 bytes)
-
-       Bits 1 and 2 are reserved for use by PKWARE.
-
-       4.4.14.1 The lowest bit of this field indicates, if set, 
-       that the file is apparently an ASCII or text file.  If not
-       set, that the file apparently contains binary data.
-       The remaining bits are unused in version 1.0.
-
-       4.4.14.2 The 0x0002 bit of this field indicates, if set, that 
-       a 4 byte variable record length control field precedes each 
-       logical record indicating the length of the record. The 
-       record length control field is stored in little-endian byte
-       order.  This flag is independent of text control characters, 
-       and if used in conjunction with text data, includes any 
-       control characters in the total length of the record. This 
-       value is provided for mainframe data transfer support.
-
-   4.4.15 external file attributes: (4 bytes)
-
-       The mapping of the external attributes is
-       host-system dependent (see 'version made by').  For
-       MS-DOS, the low order byte is the MS-DOS directory
-       attribute byte.  If input came from standard input, this
-       field is set to zero.
-
-   4.4.16 relative offset of local header: (4 bytes)
-
-       This is the offset from the start of the first disk on
-       which this file appears, to where the local header should
-       be found.  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 extended information extra field.
-
-   4.4.17 file name: (Variable)
-
-       4.4.17.1 The name of the file, with optional relative path.
-       The path stored MUST not contain a drive or
-       device letter, or a leading slash.  All slashes
-       MUST be forward slashes '/' as opposed to
-       backwards slashes '\' for compatibility with Amiga
-       and UNIX file systems etc.  If input came from standard
-       input, there is no file name field.  
-
-       4.4.17.2 If using the Central Directory Encryption Feature and 
-       general purpose bit flag 13 is set indicating masking, the file 
-       name stored in the Local Header will not be the actual file name.  
-       A masking value consisting of a unique hexadecimal value will 
-       be stored.  This value will be sequentially incremented for each 
-       file in the archive. See the section on the Strong Encryption 
-       Specification for details on retrieving the encrypted file name. 
-       Refer to the section in this document entitled "Incorporating PKWARE 
-       Proprietary Technology into Your Product" for more information.
-
-
-   4.4.18 file comment: (Variable)
-
-       The comment for this file.
-
-   4.4.19 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.
-
-
-   4.4.20 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.
-
-   4.4.21 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.
-
-   4.4.22 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.
-
-   4.4.23 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.
-
-   4.4.24 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.
-
-   4.4.25 .ZIP file comment length: (2 bytes)
-
-      The length of the comment for this .ZIP file.
-
-   4.4.26 .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.
-
-   4.4.27 zip64 extensible data sector    (variable size)
-
-      (currently reserved for use by PKWARE)
-
-
-   4.4.28 extra field: (Variable)
-
-     This SHOULD be used for storage expansion.  If additional 
-     information needs to be stored within a ZIP file for special 
-     application or platform needs, it SHOULD be stored here.  
-     Programs supporting earlier versions of this specification can 
-     then safely skip the file, and find the next file or header.  
-     This field will be 0 length in version 1.0.  
-
-     Existing extra fields are defined in the section
-     Extensible data fields that follows.
-
-4.5 Extensible data fields
---------------------------
-
-   4.5.1 In order to allow different programs and different types
-   of information to be stored in the 'extra' field in .ZIP
-   files, the following structure MUST be used for all
-   programs storing data in this field:
-
-       header1+data1 + header2+data2 . . .
-
-   Each header should consist of:
-
-       Header ID - 2 bytes
-       Data Size - 2 bytes
-
-   Note: all fields stored in Intel low-byte/high-byte order.
-
-   The Header ID field indicates the type of data that is in
-   the following data block.
-
-   Header IDs of 0 thru 31 are reserved for use by PKWARE.
-   The remaining IDs can be used by third party vendors for
-   proprietary usage.
-
-   4.5.2 The current Header ID mappings defined by PKWARE are:
-
-      0x0001        Zip64 extended information extra field
-      0x0007        AV Info
-      0x0008        Reserved for extended language encoding data (PFS)
-                    (see APPENDIX D)
-      0x0009        OS/2
-      0x000a        NTFS 
-      0x000c        OpenVMS
-      0x000d        UNIX
-      0x000e        Reserved for file stream and fork descriptors
-      0x000f        Patch Descriptor
-      0x0014        PKCS#7 Store for X.509 Certificates
-      0x0015        X.509 Certificate ID and Signature for 
-                    individual file
-      0x0016        X.509 Certificate ID for Central Directory
-      0x0017        Strong Encryption Header
-      0x0018        Record Management Controls
-      0x0019        PKCS#7 Encryption Recipient Certificate List
-      0x0065        IBM S/390 (Z390), AS/400 (I400) attributes 
-                    - uncompressed
-      0x0066        Reserved for IBM S/390 (Z390), AS/400 (I400) 
-                    attributes - compressed
-      0x4690        POSZIP 4690 (reserved) 
-
-
-   4.5.3 -Zip64 Extended Information Extra Field (0x0001):
-
-      The following is the layout of the zip64 extended 
-      information "extra" block. If one of the size or
-      offset fields in the Local or Central directory
-      record is too small to hold the required data,
-      a Zip64 extended information record is created.
-      The order of the fields in the zip64 extended 
-      information record is fixed, but the fields MUST
-      only appear if the corresponding Local or Central
-      directory record field is set to 0xFFFF or 0xFFFFFFFF.
-
-      Note: all fields stored in Intel low-byte/high-byte order.
-
-        Value      Size       Description
-        -----      ----       -----------
-(ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
-        Size       2 bytes    Size of this "extra" block
-        Original 
-        Size       8 bytes    Original uncompressed file size
-        Compressed
-        Size       8 bytes    Size of compressed data
-        Relative Header
-        Offset     8 bytes    Offset of local header record
-        Disk Start
-        Number     4 bytes    Number of the disk on which
-                              this file starts 
-
-      This entry in the Local header MUST include BOTH original
-      and compressed file size fields. If encrypting the 
-      central directory and bit 13 of the general purpose bit
-      flag is set indicating masking, the value stored in the
-      Local Header for the original file size will be zero.
-
-
-   4.5.4 -OS/2 Extra Field (0x0009):
-
-      The following is the layout of the OS/2 attributes "extra" 
-      block.  (Last Revision  09/05/95)
-
-      Note: all fields stored in Intel low-byte/high-byte order.
-
-        Value       Size          Description
-        -----       ----          -----------
-(OS/2)  0x0009      2 bytes       Tag for this "extra" block type
-        TSize       2 bytes       Size for the following data block
-        BSize       4 bytes       Uncompressed Block Size
-        CType       2 bytes       Compression type
-        EACRC       4 bytes       CRC value for uncompress block
-        (var)       variable      Compressed block
-
-      The OS/2 extended attribute structure (FEA2LIST) is 
-      compressed and then stored in its entirety within this 
-      structure.  There will only ever be one "block" of data in 
-      VarFields[].
-
-   4.5.5 -NTFS Extra Field (0x000a):
-
-      The following is the layout of the NTFS attributes 
-      "extra" block. (Note: At this time the Mtime, Atime
-      and Ctime values MAY be used on any WIN32 system.)  
-
-      Note: all fields stored in Intel low-byte/high-byte order.
-
-        Value      Size       Description
-        -----      ----       -----------
-(NTFS)  0x000a     2 bytes    Tag for this "extra" block type
-        TSize      2 bytes    Size of the total "extra" block
-        Reserved   4 bytes    Reserved for future use
-        Tag1       2 bytes    NTFS attribute tag value #1
-        Size1      2 bytes    Size of attribute #1, in bytes
-        (var)      Size1      Attribute #1 data
-         .
-         .
-         .
-         TagN       2 bytes    NTFS attribute tag value #N
-         SizeN      2 bytes    Size of attribute #N, in bytes
-         (var)      SizeN      Attribute #N data
-
-       For NTFS, values for Tag1 through TagN are as follows:
-       (currently only one set of attributes is defined for NTFS)
-
-         Tag        Size       Description
-         -----      ----       -----------
-         0x0001     2 bytes    Tag for attribute #1 
-         Size1      2 bytes    Size of attribute #1, in bytes
-         Mtime      8 bytes    File last modification time
-         Atime      8 bytes    File last access time
-         Ctime      8 bytes    File creation time
-
-   4.5.6 -OpenVMS Extra Field (0x000c):
-
-       The following is the layout of the OpenVMS attributes 
-       "extra" block.
-
-       Note: all fields stored in Intel low-byte/high-byte order.
-
-         Value      Size       Description
-         -----      ----       -----------
- (VMS)   0x000c     2 bytes    Tag for this "extra" block type
-         TSize      2 bytes    Size of the total "extra" block
-         CRC        4 bytes    32-bit CRC for remainder of the block
-         Tag1       2 bytes    OpenVMS attribute tag value #1
-         Size1      2 bytes    Size of attribute #1, in bytes
-         (var)      Size1      Attribute #1 data
-         .
-         .
-         .
-         TagN       2 bytes    OpenVMS attribute tag value #N
-         SizeN      2 bytes    Size of attribute #N, in bytes
-         (var)      SizeN      Attribute #N data
-
-       OpenVMS Extra Field Rules:
-
-          4.5.6.1. There will be one or more attributes present, which 
-          will each be preceded by the above TagX & SizeX values.  
-          These values are identical to the ATR$C_XXXX and ATR$S_XXXX 
-          constants which are defined in ATR.H under OpenVMS C.  Neither 
-          of these values will ever be zero.
-
-          4.5.6.2. No word alignment or padding is performed.
-
-          4.5.6.3. A well-behaved PKZIP/OpenVMS program should never produce
-          more than one sub-block with the same TagX value.  Also, there will 
-          never be more than one "extra" block of type 0x000c in a particular 
-          directory record.
-
-   4.5.7 -UNIX Extra Field (0x000d):
-
-        The following is the layout of the UNIX "extra" block.
-        Note: all fields are stored in Intel low-byte/high-byte 
-        order.
-
-        Value       Size          Description
-        -----       ----          -----------
-(UNIX)  0x000d      2 bytes       Tag for this "extra" block type
-        TSize       2 bytes       Size for the following data block
-        Atime       4 bytes       File last access time
-        Mtime       4 bytes       File last modification time
-        Uid         2 bytes       File user ID
-        Gid         2 bytes       File group ID
-        (var)       variable      Variable length data field
-
-        The variable length data field will contain file type 
-        specific data.  Currently the only values allowed are
-        the original "linked to" file names for hard or symbolic 
-        links, and the major and minor device node numbers for
-        character and block device nodes.  Since device nodes
-        cannot be either symbolic or hard links, only one set of
-        variable length data is stored.  Link files will have the
-        name of the original file stored.  This name is NOT NULL
-        terminated.  Its size can be determined by checking TSize -
-        12.  Device entries will have eight bytes stored as two 4
-        byte entries (in little endian format).  The first entry
-        will be the major device number, and the second the minor
-        device number.
-                          
-   4.5.8 -PATCH Descriptor Extra Field (0x000f):
-
-        4.5.8.1 The following is the layout of the Patch Descriptor 
-        "extra" block.
-
-        Note: all fields stored in Intel low-byte/high-byte order.
-
-        Value     Size     Description
-        -----     ----     -----------
-(Patch) 0x000f    2 bytes  Tag for this "extra" block type
-        TSize     2 bytes  Size of the total "extra" block
-        Version   2 bytes  Version of the descriptor
-        Flags     4 bytes  Actions and reactions (see below) 
-        OldSize   4 bytes  Size of the file about to be patched 
-        OldCRC    4 bytes  32-bit CRC of the file to be patched 
-        NewSize   4 bytes  Size of the resulting file 
-        NewCRC    4 bytes  32-bit CRC of the resulting file 
-
-        4.5.8.2 Actions and reactions
-
-        Bits          Description
-        ----          ----------------
-        0             Use for auto detection
-        1             Treat as a self-patch
-        2-3           RESERVED
-        4-5           Action (see below)
-        6-7           RESERVED
-        8-9           Reaction (see below) to absent file 
-        10-11         Reaction (see below) to newer file
-        12-13         Reaction (see below) to unknown file
-        14-15         RESERVED
-        16-31         RESERVED
-
-           4.5.8.2.1 Actions
-
-           Action       Value
-           ------       ----- 
-           none         0
-           add          1
-           delete       2
-           patch        3
-
-           4.5.8.2.2 Reactions
-        
-           Reaction     Value
-           --------     -----
-           ask          0
-           skip         1
-           ignore       2
-           fail         3
-
-        4.5.8.3 Patch support is provided by PKPatchMaker(tm) technology 
-        and is covered under U.S. Patents and Patents Pending. The use or 
-        implementation in a product of certain technological aspects set
-        forth in the current APPNOTE, including those with regard to 
-        strong encryption or patching requires a license from PKWARE.  
-        Refer to the section in this document entitled "Incorporating 
-        PKWARE Proprietary Technology into Your Product" for more 
-        information. 
-
-   4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014):
-
-        This field MUST contain information about each of the certificates 
-        files may be signed with. When the Central Directory Encryption 
-        feature is enabled for a ZIP file, this record will appear in 
-        the Archive Extra Data Record, otherwise it will appear in the 
-        first central directory record and will be ignored in any 
-        other record.  
-
-                          
-        Note: all fields stored in Intel low-byte/high-byte order.
-
-        Value     Size     Description
-        -----     ----     -----------
-(Store) 0x0014    2 bytes  Tag for this "extra" block type
-        TSize     2 bytes  Size of the store data
-        TData     TSize    Data about the store
-
-
-   4.5.10 -X.509 Certificate ID and Signature for individual file (0x0015):
-
-        This field contains the information about which certificate in 
-        the PKCS#7 store was used to sign a particular file. It also 
-        contains the signature data. This field can appear multiple 
-        times, but can only appear once per certificate.
-
-        Note: all fields stored in Intel low-byte/high-byte order.
-
-        Value     Size     Description
-        -----     ----     -----------
-(CID)   0x0015    2 bytes  Tag for this "extra" block type
-        TSize     2 bytes  Size of data that follows
-        TData     TSize    Signature Data
-
-   4.5.11 -X.509 Certificate ID and Signature for central directory (0x0016):
-
-        This field contains the information about which certificate in 
-        the PKCS#7 store was used to sign the central directory structure.
-        When the Central Directory Encryption feature is enabled for a 
-        ZIP file, this record will appear in the Archive Extra Data Record, 
-        otherwise it will appear in the first central directory record.
-
-        Note: all fields stored in Intel low-byte/high-byte order.
-
-        Value     Size     Description
-        -----     ----     -----------
-(CDID)  0x0016    2 bytes  Tag for this "extra" block type
-        TSize     2 bytes  Size of data that follows
-        TData     TSize    Data
-
-   4.5.12 -Strong Encryption Header (0x0017):
-
-        Value     Size     Description
-        -----     ----     -----------
-        0x0017    2 bytes  Tag for this "extra" block type
-        TSize     2 bytes  Size of data that follows
-        Format    2 bytes  Format definition for this record
-        AlgID     2 bytes  Encryption algorithm identifier
-        Bitlen    2 bytes  Bit length of encryption key
-        Flags     2 bytes  Processing flags
-        CertData  TSize-8  Certificate decryption extra field data
-                           (refer to the explanation for CertData
-                            in the section describing the 
-                            Certificate Processing Method under 
-                            the Strong Encryption Specification)
-
-        See the section describing the Strong Encryption Specification 
-        for details.  Refer to the section in this document entitled 
-        "Incorporating PKWARE Proprietary Technology into Your Product" 
-        for more information.
-
-   4.5.13 -Record Management Controls (0x0018):
-
-          Value     Size     Description
-          -----     ----     -----------
-(Rec-CTL) 0x0018    2 bytes  Tag for this "extra" block type
-          CSize     2 bytes  Size of total extra block data
-          Tag1      2 bytes  Record control attribute 1
-          Size1     2 bytes  Size of attribute 1, in bytes
-          Data1     Size1    Attribute 1 data
-          .
-          .
-          .
-          TagN      2 bytes  Record control attribute N
-          SizeN     2 bytes  Size of attribute N, in bytes
-          DataN     SizeN    Attribute N data
-
-
-   4.5.14 -PKCS#7 Encryption Recipient Certificate List (0x0019): 
-
-        This field MAY contain information about each of the certificates
-        used in encryption processing and it can be used to identify who is
-        allowed to decrypt encrypted files.  This field should only appear 
-        in the archive extra data record. This field is not required and 
-        serves only to aid archive modifications by preserving public 
-        encryption key data. Individual security requirements may dictate 
-        that this data be omitted to deter information exposure.
-
-        Note: all fields stored in Intel low-byte/high-byte order.
-
-         Value     Size     Description
-         -----     ----     -----------
-(CStore) 0x0019    2 bytes  Tag for this "extra" block type
-         TSize     2 bytes  Size of the store data
-         TData     TSize    Data about the store
-
-         TData:
-
-         Value     Size     Description
-         -----     ----     -----------
-         Version   2 bytes  Format version number - must 0x0001 at this time
-         CStore    (var)    PKCS#7 data blob
-
-         See the section describing the Strong Encryption Specification 
-         for details.  Refer to the section in this document entitled 
-         "Incorporating PKWARE Proprietary Technology into Your Product" 
-         for more information.
-
-   4.5.15 -MVS Extra Field (0x0065):
-
-        The following is the layout of the MVS "extra" block.
-        Note: Some fields are stored in Big Endian format.
-        All text is in EBCDIC format unless otherwise specified.
-
-        Value     Size      Description
-        -----     ----      -----------
-(MVS)   0x0065    2 bytes   Tag for this "extra" block type
-        TSize     2 bytes   Size for the following data block
-        ID        4 bytes   EBCDIC "Z390" 0xE9F3F9F0 or
-                            "T4MV" for TargetFour
-        (var)     TSize-4   Attribute data (see APPENDIX B)
-
-
-   4.5.16 -OS/400 Extra Field (0x0065):
-
-        The following is the layout of the OS/400 "extra" block.
-        Note: Some fields are stored in Big Endian format.
-        All text is in EBCDIC format unless otherwise specified.
-
-        Value     Size       Description
-        -----     ----       -----------
-(OS400) 0x0065    2 bytes    Tag for this "extra" block type
-        TSize     2 bytes    Size for the following data block
-        ID        4 bytes    EBCDIC "I400" 0xC9F4F0F0 or
-                             "T4MV" for TargetFour
-        (var)     TSize-4    Attribute data (see APPENDIX A)
-
-4.6 Third Party Mappings
-------------------------
-                 
-   4.6.1 Third party mappings commonly used are:
-
-          0x07c8        Macintosh
-          0x2605        ZipIt Macintosh
-          0x2705        ZipIt Macintosh 1.3.5+
-          0x2805        ZipIt Macintosh 1.3.5+
-          0x334d        Info-ZIP Macintosh
-          0x4341        Acorn/SparkFS 
-          0x4453        Windows NT security descriptor (binary ACL)
-          0x4704        VM/CMS
-          0x470f        MVS
-          0x4b46        FWKCS MD5 (see below)
-          0x4c41        OS/2 access control list (text ACL)
-          0x4d49        Info-ZIP OpenVMS
-          0x4f4c        Xceed original location extra field
-          0x5356        AOS/VS (ACL)
-          0x5455        extended timestamp
-          0x554e        Xceed unicode extra field
-          0x5855        Info-ZIP UNIX (original, also OS/2, NT, etc)
-          0x6375        Info-ZIP Unicode Comment Extra Field
-          0x6542        BeOS/BeBox
-          0x7075        Info-ZIP Unicode Path Extra Field
-          0x756e        ASi UNIX
-          0x7855        Info-ZIP UNIX (new)
-          0xa220        Microsoft Open Packaging Growth Hint
-          0xfd4a        SMS/QDOS
-
-   Detailed descriptions of Extra Fields defined by third 
-   party mappings will be documented as information on
-   these data structures is made available to PKWARE.  
-   PKWARE does not guarantee the accuracy of any published
-   third party data.
-
-   4.6.2 Third-party Extra Fields must include a Header ID using
-   the format defined in the section of this document 
-   titled Extensible Data Fields (section 4.5).
-
-   The Data Size field indicates the size of the following
-   data block. Programs can use this value to skip to the
-   next header block, passing over any data blocks that are
-   not of interest.
-
-   Note: As stated above, the size of the entire .ZIP file
-         header, including the file name, comment, and extra
-         field should not exceed 64K in size.
-
-   4.6.3 In case two different programs should appropriate the same
-   Header ID value, it is strongly recommended that each
-   program SHOULD place a unique signature of at least two bytes in
-   size (and preferably 4 bytes or bigger) at the start of
-   each data area.  Every program SHOULD verify that its
-   unique signature is present, in addition to the Header ID
-   value being correct, before assuming that it is a block of
-   known type.
-         
-   Third-party Mappings:
-          
-   4.6.4 -ZipIt Macintosh Extra Field (long) (0x2605):
-
-      The following is the layout of the ZipIt extra block 
-      for Macintosh. The local-header and central-header versions 
-      are identical. This block must be present if the file is 
-      stored MacBinary-encoded and it should not be used if the file 
-      is not stored MacBinary-encoded.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac2)  0x2605        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          "ZPIT"        beLong      extra-field signature
-          FnLen         Byte        length of FileName
-          FileName      variable    full Macintosh filename
-          FileType      Byte[4]     four-byte Mac file type string
-          Creator       Byte[4]     four-byte Mac creator string
-
-
-   4.6.5 -ZipIt Macintosh Extra Field (short, for files) (0x2705):
-
-      The following is the layout of a shortened variant of the
-      ZipIt extra block for Macintosh (without "full name" entry).
-      This variant is used by ZipIt 1.3.5 and newer for entries of
-      files (not directories) that do not have a MacBinary encoded
-      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
-
-
-   4.6.6 -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;
-
-
-   4.6.7 -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."
-
-
-   4.6.8 -Info-ZIP Unicode Comment Extra Field (0x6375):
-
-      Stores the UTF-8 version of the file comment as stored in the
-      central directory header. (Last Revision 20070912)
-
-         Value         Size        Description
-         -----         ----        -----------
-  (UCom) 0x6375        Short       tag for this extra block type ("uc")
-         TSize         Short       total data size for this block
-         Version       1 byte      version of this extra field, currently 1
-         ComCRC32      4 bytes     Comment Field CRC32 Checksum
-         UnicodeCom    Variable    UTF-8 version of the entry comment
-
-       Currently Version is set to the number 1.  If there is a need
-       to change this field, the version will be incremented.  Changes
-       may not be backward compatible so this extra field should not be
-       used if the version is not recognized.
-
-       The ComCRC32 is the standard zip CRC32 checksum of the File Comment
-       field in the central directory header.  This is used to verify that
-       the comment field has not changed since the Unicode Comment extra field
-       was created.  This can happen if a utility changes the File Comment 
-       field but does not update the UTF-8 Comment extra field.  If the CRC 
-       check fails, this Unicode Comment extra field should be ignored and 
-       the File Comment field in the header should be used instead.
-
-       The UnicodeCom field is the UTF-8 version of the File Comment field
-       in the header.  As UnicodeCom is defined to be UTF-8, no UTF-8 byte
-       order mark (BOM) is used.  The length of this field is determined by
-       subtracting the size of the previous fields from TSize.  If both the
-       File Name and Comment fields are UTF-8, the new General Purpose Bit
-       Flag, bit 11 (Language encoding flag (EFS)), can be used to indicate
-       both the header File Name and Comment fields are UTF-8 and, in this
-       case, the Unicode Path and Unicode Comment extra fields are not
-       needed and should not be created.  Note that, for backward
-       compatibility, bit 11 should only be used if the native character set
-       of the paths and comments being zipped up are already in UTF-8. It is
-       expected that the same file comment storage method, either general
-       purpose bit 11 or extra fields, be used in both the Local and Central
-       Directory Header for a file.
-
-
-   4.6.9 -Info-ZIP Unicode Path Extra Field (0x7075):
-
-       Stores the UTF-8 version of the file name field as stored in the
-       local header and central directory header. (Last Revision 20070912)
-
-         Value         Size        Description
-         -----         ----        -----------
- (UPath) 0x7075        Short       tag for this extra block type ("up")
-         TSize         Short       total data size for this block
-         Version       1 byte      version of this extra field, currently 1
-         NameCRC32     4 bytes     File Name Field CRC32 Checksum
-         UnicodeName   Variable    UTF-8 version of the entry File Name
-
-      Currently Version is set to the number 1.  If there is a need
-      to change this field, the version will be incremented.  Changes
-      may not be backward compatible so this extra field should not be
-      used if the version is not recognized.
-
-      The NameCRC32 is the standard zip CRC32 checksum of the File Name
-      field in the header.  This is used to verify that the header
-      File Name field has not changed since the Unicode Path extra field
-      was created.  This can happen if a utility renames the File Name but
-      does not update the UTF-8 path extra field.  If the CRC check fails,
-      this UTF-8 Path Extra Field should be ignored and the File Name field
-      in the header should be used instead.
-
-      The UnicodeName is the UTF-8 version of the contents of the File Name
-      field in the header.  As UnicodeName is defined to be UTF-8, no UTF-8
-      byte order mark (BOM) is used.  The length of this field is determined
-      by subtracting the size of the previous fields from TSize.  If both
-      the File Name and Comment fields are UTF-8, the new General Purpose
-      Bit Flag, bit 11 (Language encoding flag (EFS)), can be used to
-      indicate that both the header File Name and Comment fields are UTF-8
-      and, in this case, the Unicode Path and Unicode Comment extra fields
-      are not needed and should not be created.  Note that, for backward
-      compatibility, bit 11 should only be used if the native character set
-      of the paths and comments being zipped up are already in UTF-8. It is
-      expected that the same file name storage method, either general
-      purpose bit 11 or extra fields, be used in both the Local and Central
-      Directory Header for a file.
- 
-
-   4.6.10 -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
-
-4.7 Manifest Files
-------------------
-
-    4.7.1 Applications using ZIP files may have a need for additional 
-    information that must be included with the files placed into
-    a ZIP file. Application specific information that cannot be
-    stored using the defined ZIP storage records SHOULD be stored 
-    using the extensible Extra Field convention defined in this 
-    document.  However, some applications may use a manifest
-    file as a means for storing additional information.  One
-    example is the META-INF/MANIFEST.MF file used in ZIP formatted
-    files having the .JAR extension (JAR files).  
-
-    4.7.2 A manifest file is a file created for the application process
-    that requires this information.  A manifest file MAY be of any 
-    file type required by the defining application process.  It is 
-    placed within the same ZIP file as files to which this information 
-    applies. By convention, this file is typically the first file placed
-    into the ZIP file and it may include a defined directory path.
-
-    4.7.3 Manifest files may be compressed or encrypted as needed for
-    application processing of the files inside the ZIP files.
-
-    Manifest files are outside of the scope of this specification.
-
-
-5.0 Explanation of compression methods
---------------------------------------
-
-
-5.1 UnShrinking - Method 1
---------------------------
-
-    5.1.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:
-
-    5.1.2 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.
-
-    5.1.3 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-used, with the lowest
-    code value re-used first, and the highest code value
-    re-used last.  The compressor can emit the sequence 256,2
-    at any time.
-
-5.2 Expanding - Methods 2-5
----------------------------
-
-    5.2.1 The Reducing algorithm is actually a combination of two
-    distinct algorithms.  The first algorithm compresses repeated
-    byte sequences, and the second algorithm takes the compressed
-    stream from the first algorithm and applies a probabilistic
-    compression method.
-
-    5.2.2 The probabilistic compression stores an array of 'follower
-    sets' S(j), for j=0 to 255, corresponding to each possible
-    ASCII character.  Each set contains between 0 and 32
-    characters, to be denoted as S(j)[0],...,S(j)[m], where m<32.
-    The sets are stored at the beginning of the data area for a
-    Reduced file, in reverse order, with S(255) first, and S(0)
-    last.
-
-    5.2.3 The sets are encoded as { N(j), S(j)[0],...,S(j)[N(j)-1] },
-    where N(j) is the size of set S(j).  N(j) can be 0, in which
-    case the follower set for S(j) is empty.  Each N(j) value is
-    encoded in 6 bits, followed by N(j) eight bit character values
-    corresponding to S(j)[0] to S(j)[N(j)-1] respectively.  If
-    N(j) is 0, then no values for S(j) are stored, and the value
-    for N(j-1) immediately follows.
-
-    5.2.4 Immediately after the follower sets, is the compressed data
-    stream.  The compressed data stream can be interpreted for the
-    probabilistic decompression as follows:
-
-    let Last-Character <- 0.
-    loop until done
-        if the follower set S(Last-Character) is empty then
-            read 8 bits from the input stream, and copy this
-            value to the output stream.
-        otherwise if the follower set S(Last-Character) is non-empty then
-            read 1 bit from the input stream.
-            if this bit is not zero then
-                read 8 bits from the input stream, and copy this
-                value to the output stream.
-            otherwise if this bit is zero then
-                read B(N(Last-Character)) bits from the input
-                stream, and assign this value to I.
-                Copy the value of S(Last-Character)[I] to the
-                output stream.
-
-        assign the last value placed on the output stream to
-        Last-Character.
-    end loop
-
-    B(N(j)) is defined as the minimal number of bits required to
-    encode the value N(j)-1.
-
-    5.2.5 The decompressed stream from above can then be expanded to
-    re-create the original file as follows:
-
-    let State <- 0.
-
-    loop until done
-        read 8 bits from the input stream into C.
-        case State of
-            0:  if C is not equal to DLE (144 decimal) then
-                   copy C to the output stream.
-                 otherwise if C is equal to DLE then
-                   let State <- 1.
-
-            1:  if C is non-zero then
-                   let V <- C.
-                   let Len <- L(V)
-                   let State <- F(Len).
-                 otherwise if C is zero then
-                   copy the value 144 (decimal) to the output stream.
-                   let State <- 0
-
-            2:  let Len <- Len + C
-                    let State <- 3.
-
-            3:  move backwards D(V,C) bytes in the output stream
-                    (if this position is before the start of the output
-                    stream, then assume that all the data before the
-                    start of the output stream is filled with zeros).
-                    copy Len+3 bytes from this position to the output stream.
-                    let State <- 0.
-          end case
-    end loop
-
-    The functions F,L, and D are dependent on the 'compression
-    factor', 1 through 4, and are defined as follows:
-
-    For compression factor 1:
-        L(X) equals the lower 7 bits of X.
-        F(X) equals 2 if X equals 127 otherwise F(X) equals 3.
-        D(X,Y) equals the (upper 1 bit of X) * 256 + Y + 1.
-    For compression factor 2:
-        L(X) equals the lower 6 bits of X.
-        F(X) equals 2 if X equals 63 otherwise F(X) equals 3.
-        D(X,Y) equals the (upper 2 bits of X) * 256 + Y + 1.
-    For compression factor 3:
-        L(X) equals the lower 5 bits of X.
-        F(X) equals 2 if X equals 31 otherwise F(X) equals 3.
-        D(X,Y) equals the (upper 3 bits of X) * 256 + Y + 1.
-    For compression factor 4:
-        L(X) equals the lower 4 bits of X.
-        F(X) equals 2 if X equals 15 otherwise F(X) equals 3.
-        D(X,Y) equals the (upper 4 bits of X) * 256 + Y + 1.
-
-5.3 Imploding - Method 6
-------------------------
-
-    5.3.1 The Imploding algorithm is actually a combination of two 
-    distinct algorithms.  The first algorithm compresses repeated byte
-    sequences using a sliding dictionary.  The second algorithm is
-    used to compress the encoding of the sliding dictionary output,
-    using multiple Shannon-Fano trees.
-
-    5.3.2 The Imploding algorithm can use a 4K or 8K sliding dictionary
-    size. The dictionary size used can be determined by bit 1 in the
-    general purpose flag word; a 0 bit indicates a 4K dictionary
-    while a 1 bit indicates an 8K dictionary.
-
-    5.3.3 The Shannon-Fano trees are stored at the start of the 
-    compressed file. The number of trees stored is defined by bit 2 in 
-    the general purpose flag word; a 0 bit indicates two trees stored, 
-    a 1 bit indicates three trees are stored.  If 3 trees are stored,
-    the first Shannon-Fano tree represents the encoding of the
-    Literal characters, the second tree represents the encoding of
-    the Length information, the third represents the encoding of the
-    Distance information.  When 2 Shannon-Fano trees are stored, the
-    Length tree is stored first, followed by the Distance tree.
-
-    5.3.4 The Literal Shannon-Fano tree, if present is used to represent
-    the entire ASCII character set, and contains 256 values.  This
-    tree is used to compress any data not compressed by the sliding
-    dictionary algorithm.  When this tree is present, the Minimum
-    Match Length for the sliding dictionary is 3.  If this tree is
-    not present, the Minimum Match Length is 2.
-
-    5.3.5 The Length Shannon-Fano tree is used to compress the Length 
-    part of the (length,distance) pairs from the sliding dictionary
-    output.  The Length tree contains 64 values, ranging from the
-    Minimum Match Length, to 63 plus the Minimum Match Length.
-
-    5.3.6 The Distance Shannon-Fano tree is used to compress the Distance
-    part of the (length,distance) pairs from the sliding dictionary
-    output. The Distance tree contains 64 values, ranging from 0 to
-    63, representing the upper 6 bits of the distance value.  The
-    distance values themselves will be between 0 and the sliding
-    dictionary size, either 4K or 8K.
-
-    5.3.7 The Shannon-Fano trees themselves are stored in a compressed
-    format. The first byte of the tree data represents the number of
-    bytes of data representing the (compressed) Shannon-Fano tree
-    minus 1.  The remaining bytes represent the Shannon-Fano tree
-    data encoded as:
-
-        High 4 bits: Number of values at this bit length + 1. (1 - 16)
-        Low  4 bits: Bit Length needed to represent value + 1. (1 - 16)
-
-    5.3.8 The Shannon-Fano codes can be constructed from the bit lengths
-    using the following algorithm:
-
-    1)  Sort the Bit Lengths in ascending order, while retaining the
-        order of the original lengths stored in the file.
-
-    2)  Generate the Shannon-Fano trees:
-
-        Code <- 0
-        CodeIncrement <- 0
-        LastBitLength <- 0
-        i <- number of Shannon-Fano codes - 1   (either 255 or 63)
-
-        loop while i >= 0
-            Code = Code + CodeIncrement
-            if BitLength(i) <> LastBitLength then
-                LastBitLength=BitLength(i)
-                CodeIncrement = 1 shifted left (16 - LastBitLength)
-            ShannonCode(i) = Code
-            i <- i - 1
-        end loop
-
-    3)  Reverse the order of all the bits in the above ShannonCode()
-        vector, so that the most significant bit becomes the least
-        significant bit.  For example, the value 0x1234 (hex) would
-        become 0x2C48 (hex).
-
-    4)  Restore the order of Shannon-Fano codes as originally stored
-        within the file.
-
-    Example:
-
-        This example will show the encoding of a Shannon-Fano tree
-        of size 8.  Notice that the actual Shannon-Fano trees used
-        for Imploding are either 64 or 256 entries in size.
-
-    Example:   0x02, 0x42, 0x01, 0x13
-
-        The first byte indicates 3 values in this table.  Decoding the
-        bytes:
-                0x42 = 5 codes of 3 bits long
-                0x01 = 1 code  of 2 bits long
-                0x13 = 2 codes of 4 bits long
-
-        This would generate the original bit length array of:
-        (3, 3, 3, 3, 3, 2, 4, 4)
-
-        There are 8 codes in this table for the values 0 thru 7.  Using 
-        the algorithm to obtain the Shannon-Fano codes produces:
-
-                                      Reversed     Order     Original
-    Val  Sorted   Constructed Code      Value     Restored    Length
-    ---  ------   -----------------   --------    --------    ------
-    0:     2      1100000000000000        11       101          3
-    1:     3      1010000000000000       101       001          3
-    2:     3      1000000000000000       001       110          3
-    3:     3      0110000000000000       110       010          3
-    4:     3      0100000000000000       010       100          3
-    5:     3      0010000000000000       100        11          2
-    6:     4      0001000000000000      1000      1000          4
-    7:     4      0000000000000000      0000      0000          4
-
-    The values in the Val, Order Restored and Original Length columns
-    now represent the Shannon-Fano encoding tree that can be used for
-    decoding the Shannon-Fano encoded data.  How to parse the
-    variable length Shannon-Fano values from the data stream is beyond
-    the scope of this document.  (See the references listed at the end of
-    this document for more information.)  However, traditional decoding
-    schemes used for Huffman variable length decoding, such as the
-    Greenlaw algorithm, can be successfully applied.
-
-    5.3.9 The compressed data stream begins immediately after the
-    compressed Shannon-Fano data.  The compressed data stream can be
-    interpreted as follows:
-
-    loop until done
-        read 1 bit from input stream.
-
-        if this bit is non-zero then       (encoded data is literal data)
-            if Literal Shannon-Fano tree is present
-                read and decode character using Literal Shannon-Fano tree.
-            otherwise
-                read 8 bits from input stream.
-            copy character to the output stream.
-        otherwise              (encoded data is sliding dictionary match)
-            if 8K dictionary size
-                read 7 bits for offset Distance (lower 7 bits of offset).
-            otherwise
-                read 6 bits for offset Distance (lower 6 bits of offset).
-
-            using the Distance Shannon-Fano tree, read and decode the
-              upper 6 bits of the Distance value.
-
-            using the Length Shannon-Fano tree, read and decode
-              the Length value.
-
-            Length <- Length + Minimum Match Length
-
-            if Length = 63 + Minimum Match Length
-                read 8 bits from the input stream,
-                add this value to Length.
-
-            move backwards Distance+1 bytes in the output stream, and
-            copy Length characters from this position to the output
-            stream.  (if this position is before the start of the output
-            stream, then assume that all the data before the start of
-            the output stream is filled with zeros).
-    end loop
-
-5.4 Tokenizing - Method 7
--------------------------
-
-    5.4.1 This method is not used by PKZIP.
-
-5.5 Deflating - Method 8
-------------------------
-
-    5.5.1 The Deflate algorithm is similar to the Implode algorithm using
-    a sliding dictionary of up to 32K with secondary compression
-    from Huffman/Shannon-Fano codes.
-
-    5.5.2 The compressed data is stored in blocks with a header describing
-    the block and the Huffman codes used in the data block.  The header
-    format is as follows:
-
-       Bit 0: Last Block bit     This bit is set to 1 if this is the last
-                                 compressed block in the data.
-       Bits 1-2: Block type
-          00 (0) - Block is stored - All stored data is byte aligned.
-                   Skip bits until next byte, then next word = block 
-                   length, followed by the ones compliment of the block
-                   length word. Remaining data in block is the stored 
-                   data.
-
-          01 (1) - Use fixed Huffman codes for literal and distance codes.
-                   Lit Code    Bits             Dist Code   Bits
-                   ---------   ----             ---------   ----
-                     0 - 143    8                 0 - 31      5
-                   144 - 255    9
-                   256 - 279    7
-                   280 - 287    8
-
-                   Literal codes 286-287 and distance codes 30-31 are 
-                   never used but participate in the huffman construction.
-
-          10 (2) - Dynamic Huffman codes.  (See expanding Huffman codes)
-
-          11 (3) - Reserved - Flag a "Error in compressed data" if seen.
-
-    5.5.3 Expanding Huffman Codes
-    
-    If the data block is stored with dynamic Huffman codes, the Huffman
-    codes are sent in the following compressed format:
-
-       5 Bits: # of Literal codes sent - 256 (256 - 286)
-               All other codes are never sent.
-       5 Bits: # of Dist codes - 1           (1 - 32)
-       4 Bits: # of Bit Length codes - 3     (3 - 19)
-
-    The Huffman codes are sent as bit lengths and the codes are built as
-    described in the implode algorithm.  The bit lengths themselves are
-    compressed with Huffman codes.  There are 19 bit length codes:
-
-       0 - 15: Represent bit lengths of 0 - 15
-           16: Copy the previous bit length 3 - 6 times.
-               The next 2 bits indicate repeat length (0 = 3, ... ,3 = 6)
-                  Example:  Codes 8, 16 (+2 bits 11), 16 (+2 bits 10) will
-                            expand to 12 bit lengths of 8 (1 + 6 + 5)
-           17: Repeat a bit length of 0 for 3 - 10 times. (3 bits of length)
-           18: Repeat a bit length of 0 for 11 - 138 times (7 bits of length)
-
-    The lengths of the bit length codes are sent packed 3 bits per value
-    (0 - 7) in the following order:
-
-       16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15
-
-    The Huffman codes should be built as described in the Implode algorithm
-    except codes are assigned starting at the shortest bit length, i.e. the
-    shortest code should be all 0's rather than all 1's.  Also, codes with
-    a bit length of zero do not participate in the tree construction.  The
-    codes are then used to decode the bit lengths for the literal and 
-    distance tables.
-
-    The bit lengths for the literal tables are sent first with the number
-    of entries sent described by the 5 bits sent earlier.  There are up
-    to 286 literal characters; the first 256 represent the respective 8
-    bit character, code 256 represents the End-Of-Block code, the remaining
-    29 codes represent copy lengths of 3 thru 258.  There are up to 30
-    distance codes representing distances from 1 thru 32k as described
-    below.
-
-                                 Length Codes
-                                 ------------
-          Extra             Extra              Extra              Extra
-     Code Bits Length  Code Bits Lengths  Code Bits Lengths  Code Bits Length(s)
-     ---- ---- ------  ---- ---- -------  ---- ---- -------  ---- ---- ---------
-      257   0     3     265   1   11,12    273   3   35-42    281   5  131-162
-      258   0     4     266   1   13,14    274   3   43-50    282   5  163-194
-      259   0     5     267   1   15,16    275   3   51-58    283   5  195-226
-      260   0     6     268   1   17,18    276   3   59-66    284   5  227-257
-      261   0     7     269   2   19-22    277   4   67-82    285   0    258
-      262   0     8     270   2   23-26    278   4   83-98
-      263   0     9     271   2   27-30    279   4   99-114
-      264   0    10     272   2   31-34    280   4  115-130
-
-                                Distance Codes
-                                --------------
-          Extra           Extra             Extra               Extra
-     Code Bits Dist  Code Bits  Dist   Code Bits Distance  Code Bits Distance
-     ---- ---- ----  ---- ---- ------  ---- ---- --------  ---- ---- --------
-       0   0    1      8   3   17-24    16    7  257-384    24   11  4097-6144
-       1   0    2      9   3   25-32    17    7  385-512    25   11  6145-8192
-       2   0    3     10   4   33-48    18    8  513-768    26   12  8193-12288
-       3   0    4     11   4   49-64    19    8  769-1024   27   12 12289-16384
-       4   1   5,6    12   5   65-96    20    9 1025-1536   28   13 16385-24576
-       5   1   7,8    13   5   97-128   21    9 1537-2048   29   13 24577-32768
-       6   2   9-12   14   6  129-192   22   10 2049-3072
-       7   2  13-16   15   6  193-256   23   10 3073-4096
-
-    5.5.4 The compressed data stream begins immediately after the
-    compressed header data.  The compressed data stream can be
-    interpreted as follows:
-
-    do
-       read header from input stream.
-
-       if stored block
-          skip bits until byte aligned
-          read count and 1's compliment of count
-          copy count bytes data block
-       otherwise
-          loop until end of block code sent
-             decode literal character from input stream
-             if literal < 256
-                copy character to the output stream
-             otherwise
-                if literal = end of block
-                   break from loop
-                otherwise
-                   decode distance from input stream
-
-                   move backwards distance bytes in the output stream, and
-                   copy length characters from this position to the output
-                   stream.
-          end loop
-    while not last block
-
-    if data descriptor exists
-       skip bits until byte aligned
-       read crc and sizes
-    endif
-
-5.6 Enhanced Deflating - Method 9
----------------------------------
-
-    5.6.1 The Enhanced Deflating algorithm is similar to Deflate but uses 
-    a sliding dictionary of up to 64K. Deflate64(tm) is supported
-    by the Deflate extractor. 
-
-5.7 BZIP2 - Method 12
----------------------
-
-    5.7.1 BZIP2 is an open-source data compression algorithm developed by 
-    Julian Seward.  Information and source code for this algorithm
-    can be found on the internet.
-
-5.8 LZMA - Method 14 
----------------------
-
-    5.8.1 LZMA is a block-oriented, general purpose data compression 
-    algorithm developed and maintained by Igor Pavlov.  It is a derivative 
-    of LZ77 that utilizes Markov chains and a range coder.  Information and 
-    source code for this algorithm can be found on the internet.  Consult 
-    with the author of this algorithm for information on terms or 
-    restrictions on use.
-
-    Support for LZMA within the ZIP format is defined as follows:   
-
-    5.8.2 The Compression method field within the ZIP Local and Central 
-    Header records will be set to the value 14 to indicate data was
-    compressed using LZMA. 
-
-    5.8.3 The Version needed to extract field within the ZIP Local and 
-    Central Header records will be set to 6.3 to indicate the minimum 
-    ZIP format version supporting this feature.
-
-    5.8.4 File data compressed using the LZMA algorithm must be placed 
-    immediately following the Local Header for the file.  If a standard 
-    ZIP encryption header is required, it will follow the Local Header 
-    and will precede the LZMA compressed file data segment.  The location 
-    of LZMA compressed data segment within the ZIP format will be as shown:
-
-        [local header file 1]
-        [encryption header file 1]
-        [LZMA compressed data segment for file 1]
-        [data descriptor 1]
-        [local header file 2]
-
-    5.8.5 The encryption header and data descriptor records may
-    be conditionally present.  The LZMA Compressed Data Segment 
-    will consist of an LZMA Properties Header followed by the 
-    LZMA Compressed Data as shown:
-
-        [LZMA properties header for file 1]
-        [LZMA compressed data for file 1]
-
-    5.8.6 The LZMA Compressed Data will be stored as provided by the 
-    LZMA compression library.  Compressed size, uncompressed size and 
-    other file characteristics about the file being compressed must be 
-    stored in standard ZIP storage format.
-
-    5.8.7 The LZMA Properties Header will store specific data required 
-    to decompress the LZMA compressed Data.  This data is set by the 
-    LZMA compression engine using the function WriteCoderProperties() 
-    as documented within the LZMA SDK. 
-         
-    5.8.8 Storage fields for the property information within the LZMA 
-    Properties Header are as follows:
-
-         LZMA Version Information 2 bytes
-         LZMA Properties Size 2 bytes
-         LZMA Properties Data variable, defined by "LZMA Properties Size"
-
-       5.8.8.1 LZMA Version Information - this field identifies which version 
-       of the LZMA SDK was used to compress a file.  The first byte will 
-       store the major version number of the LZMA SDK and the second 
-       byte will store the minor number.  
-
-       5.8.8.2 LZMA Properties Size - this field defines the size of the 
-       remaining property data.  Typically this size should be determined by 
-       the version of the SDK.  This size field is included as a convenience
-       and to help avoid any ambiguity should it arise in the future due
-       to changes in this compression algorithm. 
-
-       5.8.8.3 LZMA Property Data - this variable sized field records the 
-       required values for the decompressor as defined by the LZMA SDK.  
-       The data stored in this field should be obtained using the 
-       WriteCoderProperties() in the version of the SDK defined by 
-       the "LZMA Version Information" field.  
-
-       5.8.8.4 The layout of the "LZMA Properties Data" field is a function of 
-       the LZMA compression algorithm.  It is possible that this layout may be
-       changed by the author over time.  The data layout in version 4.3 of the 
-       LZMA SDK defines a 5 byte array that uses 4 bytes to store the dictionary 
-       size in little-endian order. This is preceded by a single packed byte as 
-       the first element of the array that contains the following fields:
-
-         PosStateBits
-         LiteralPosStateBits
-         LiteralContextBits
-
-       Refer to the LZMA documentation for a more detailed explanation of 
-       these fields.  
-
-    5.8.9 Data compressed with method 14, LZMA, may include an end-of-stream
-    (EOS) marker ending the compressed data stream.  This marker is not
-    required, but its use is highly recommended to facilitate processing
-    and implementers should include the EOS marker whenever possible.
-    When the EOS marker is used, general purpose bit 1 must be set.  If
-    general purpose bit 1 is not set, the EOS marker is not present.
-
-5.9 WavPack - Method 97
------------------------
-
-    5.9.1 Information describing the use of compression method 97 is 
-    provided by WinZIP International, LLC.  This method relies on the
-    open source WavPack audio compression utility developed by David Bryant.  
-    Information on WavPack is available at www.wavpack.com.  Please consult 
-    with the author of this algorithm for information on terms and 
-    restrictions on use.
-
-    5.9.2 WavPack data for a file begins immediately after the end of the
-    local header data.  This data is the output from WavPack compression
-    routines.  Within the ZIP file, the use of WavPack compression is
-    indicated by setting the compression method field to a value of 97 
-    in both the local header and the central directory header.  The Version 
-    needed to extract and version made by fields use the same values as are 
-    used for data compressed using the Deflate algorithm.
-
-    5.9.3 An implementation note for storing digital sample data when using 
-    WavPack compression within ZIP files is that all of the bytes of
-    the sample data should be compressed.  This includes any unused
-    bits up to the byte boundary.  An example is a 2 byte sample that
-    uses only 12 bits for the sample data with 4 unused bits.  If only
-    12 bits are passed as the sample size to the WavPack routines, the 4 
-    unused bits will be set to 0 on extraction regardless of their original 
-    state.  To avoid this, the full 16 bits of the sample data size
-    should be provided. 
-
-5.10 PPMd - Method 98
----------------------
-
-    5.10.1 PPMd is a data compression algorithm developed by Dmitry Shkarin
-    which includes a carryless rangecoder developed by Dmitry Subbotin.
-    This algorithm is based on predictive phrase matching on multiple
-    order contexts.  Information and source code for this algorithm
-    can be found on the internet. Consult with the author of this
-    algorithm for information on terms or restrictions on use.
-
-    5.10.2 Support for PPMd within the ZIP format currently is provided only 
-    for version I, revision 1 of the algorithm.  Storage requirements
-    for using this algorithm are as follows:
-
-    5.10.3 Parameters needed to control the algorithm are stored in the two
-    bytes immediately preceding the compressed data.  These bytes are
-    used to store the following fields:
-
-    Model order - sets the maximum model order, default is 8, possible
-                  values are from 2 to 16 inclusive
-
-    Sub-allocator size - sets the size of sub-allocator in MB, default is 50,
-                    possible values are from 1MB to 256MB inclusive
-
-    Model restoration method - sets the method used to restart context
-                    model at memory insufficiency, values are:
-
-                    0 - restarts model from scratch - default
-                    1 - cut off model - decreases performance by as much as 2x
-                    2 - freeze context tree - not recommended
-
-    5.10.4 An example for packing these fields into the 2 byte storage field is
-    illustrated below.  These values are stored in Intel low-byte/high-byte
-    order.
-
-    wPPMd = (Model order - 1) + 
-            ((Sub-allocator size - 1) << 4) + 
-            (Model restoration method << 12)
-
-
-6.0  Traditional PKWARE Encryption
-----------------------------------
-
-    6.0.1 The following information discusses the decryption steps
-    required to support traditional PKWARE encryption.  This
-    form of encryption is considered weak by today's standards
-    and its use is recommended only for situations with
-    low security needs or for compatibility with older .ZIP 
-    applications.
-
-6.1 Traditional PKWARE Decryption
----------------------------------
-
-    6.1.1 PKWARE is grateful to Mr. Roger Schlafly for his expert 
-    contribution towards the development of PKWARE's traditional 
-    encryption.
-
-    6.1.2 PKZIP encrypts the compressed data stream.  Encrypted files 
-    must be decrypted before they can be extracted to their original
-    form.
-
-    6.1.3 Each encrypted file has an extra 12 bytes stored at the start 
-    of the data area defining the encryption header for that file.  The
-    encryption header is originally set to random values, and then
-    itself encrypted, using three, 32-bit keys.  The key values are
-    initialized using the supplied encryption password.  After each byte
-    is encrypted, the keys are then updated using pseudo-random number
-    generation techniques in combination with the same CRC-32 algorithm
-    used in PKZIP and described elsewhere in this document.
-
-    6.1.4 The following are the basic steps required to decrypt a file:
-
-    1) Initialize the three 32-bit keys with the password.
-    2) Read and decrypt the 12-byte encryption header, further
-       initializing the encryption keys.
-    3) Read and decrypt the compressed data stream using the
-       encryption keys.
-
-    6.1.5 Initializing the encryption keys
-        
-    Key(0) <- 305419896
-    Key(1) <- 591751049
-    Key(2) <- 878082192
-
-    loop for i <- 0 to length(password)-1
-        update_keys(password(i))
-    end loop
-
-    Where update_keys() is defined as:
-
-    update_keys(char):
-      Key(0) <- crc32(key(0),char)
-      Key(1) <- Key(1) + (Key(0) & 000000ffH)
-      Key(1) <- Key(1) * 134775813 + 1
-      Key(2) <- crc32(key(2),key(1) >> 24)
-    end update_keys
-
-    Where crc32(old_crc,char) is a routine that given a CRC value and a
-    character, returns an updated CRC value after applying the CRC-32
-    algorithm described elsewhere in this document.
-
-    6.1.6 Decrypting the encryption header
-        
-    The purpose of this step is to further initialize the encryption
-    keys, based on random data, to render a plaintext attack on the
-    data ineffective.
-
-    Read the 12-byte encryption header into Buffer, in locations
-    Buffer(0) thru Buffer(11).
-
-    loop for i <- 0 to 11
-        C <- buffer(i) ^ decrypt_byte()
-        update_keys(C)
-        buffer(i) <- C
-    end loop
-
-    Where decrypt_byte() is defined as:
-
-    unsigned char decrypt_byte()
-        local unsigned short temp
-        temp <- Key(2) | 2
-        decrypt_byte <- (temp * (temp ^ 1)) >> 8
-    end decrypt_byte
-
-    After the header is decrypted,  the last 1 or 2 bytes in Buffer
-    should be the high-order word/byte of the CRC for the file being
-    decrypted, stored in Intel low-byte/high-byte order.  Versions of
-    PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is
-    used on versions after 2.0.  This can be used to test if the password
-    supplied is correct or not.
-
-    6.1.7 Decrypting the compressed data stream
-    
-    The compressed data stream can be decrypted as follows:
-
-    loop until done
-        read a character into C
-        Temp <- C ^ decrypt_byte()
-        update_keys(temp)
-        output Temp
-    end loop
-
-
-7.0 Strong Encryption Specification
------------------------------------
-
-   7.0.1 Portions of the Strong Encryption technology defined in this 
-   specification are covered under patents and pending patent applications.
-   Refer to the section in this document entitled "Incorporating 
-   PKWARE Proprietary Technology into Your Product" for more information.
-
-7.1 Strong Encryption Overview
-------------------------------
-
-   7.1.1 Version 5.x of this specification introduced support for strong 
-   encryption algorithms.  These algorithms can be used with either 
-   a password or an X.509v3 digital certificate to encrypt each file. 
-   This format specification supports either password or certificate 
-   based encryption to meet the security needs of today, to enable 
-   interoperability between users within both PKI and non-PKI 
-   environments, and to ensure interoperability between different 
-   computing platforms that are running a ZIP program.  
-
-   7.1.2 Password based encryption is the most common form of encryption 
-   people are familiar with.  However, inherent weaknesses with 
-   passwords (e.g. susceptibility to dictionary/brute force attack) 
-   as well as password management and support issues make certificate 
-   based encryption a more secure and scalable option.  Industry 
-   efforts and support are defining and moving towards more advanced 
-   security solutions built around X.509v3 digital certificates and 
-   Public Key Infrastructures(PKI) because of the greater scalability, 
-   administrative options, and more robust security over traditional 
-   password based encryption. 
-
-   7.1.3 Most standard encryption algorithms are supported with this
-   specification. Reference implementations for many of these 
-   algorithms are available from either commercial or open source 
-   distributors.  Readily available cryptographic toolkits make
-   implementation of the encryption features straight-forward.  
-   This document is not intended to provide a treatise on data 
-   encryption principles or theory.  Its purpose is to document the 
-   data structures required for implementing interoperable data 
-   encryption within the .ZIP format.  It is strongly recommended that 
-   you have a good understanding of data encryption before reading 
-   further.
-
-   7.1.4 The algorithms introduced in Version 5.0 of this specification 
-   include:
-
-      RC2 40 bit, 64 bit, and 128 bit
-      RC4 40 bit, 64 bit, and 128 bit
-      DES
-      3DES 112 bit and 168 bit
-  
-   Version 5.1 adds support for the following:
-
-      AES 128 bit, 192 bit, and 256 bit
-
-
-   7.1.5 Version 6.1 introduces encryption data changes to support 
-   interoperability with Smartcard and USB Token certificate storage 
-   methods which do not support the OAEP strengthening standard.
-
-   7.1.6 Version 6.2 introduces support for encrypting metadata by compressing 
-   and encrypting the central directory data structure to reduce information 
-   leakage.   Information leakage can occur in legacy ZIP applications 
-   through exposure of information about a file even though that file is 
-   stored encrypted.  The information exposed consists of file 
-   characteristics stored within the records and fields defined by this 
-   specification.  This includes data such as a file's name, its original 
-   size, timestamp and CRC32 value. 
-
-   7.1.7 Version 6.3 introduces support for encrypting data using the Blowfish
-   and Twofish algorithms.  These are symmetric block ciphers developed 
-   by Bruce Schneier.  Blowfish supports using a variable length key from 
-   32 to 448 bits.  Block size is 64 bits.  Implementations should use 16
-   rounds and the only mode supported within ZIP files is CBC. Twofish 
-   supports key sizes 128, 192 and 256 bits.  Block size is 128 bits.  
-   Implementations should use 16 rounds and the only mode supported within
-   ZIP files is CBC.  Information and source code for both Blowfish and 
-   Twofish algorithms can be found on the internet.  Consult with the author
-   of these algorithms for information on terms or restrictions on use.
-
-   7.1.8 Central Directory Encryption provides greater protection against 
-   information leakage by encrypting the Central Directory structure and 
-   by masking key values that are replicated in the unencrypted Local 
-   Header.   ZIP compatible programs that cannot interpret an encrypted 
-   Central Directory structure cannot rely on the data in the corresponding 
-   Local Header for decompression information.  
-
-   7.1.9 Extra Field records that may contain information about a file that should 
-   not be exposed should not be stored in the Local Header and should only 
-   be written to the Central Directory where they can be encrypted.  This 
-   design currently does not support streaming.  Information in the End of 
-   Central Directory record, the Zip64 End of Central Directory Locator, 
-   and the Zip64 End of Central Directory records are not encrypted.  Access 
-   to view data on files within a ZIP file with an encrypted Central Directory
-   requires the appropriate password or private key for decryption prior to 
-   viewing any files, or any information about the files, in the archive.  
-
-   7.1.10 Older ZIP compatible programs not familiar with the Central Directory 
-   Encryption feature will no longer be able to recognize the Central 
-   Directory and may assume the ZIP file is corrupt.  Programs that 
-   attempt streaming access using Local Headers will see invalid 
-   information for each file.  Central Directory Encryption need not be 
-   used for every ZIP file.  Its use is recommended for greater security.  
-   ZIP files not using Central Directory Encryption should operate as 
-   in the past. 
-
-   7.1.11 This strong encryption feature specification is intended to provide for 
-   scalable, cross-platform encryption needs ranging from simple password
-   encryption to authenticated public/private key encryption.  
-
-   7.1.12 Encryption provides data confidentiality and privacy.  It is 
-   recommended that you combine X.509 digital signing with encryption 
-   to add authentication and non-repudiation.
-
-
-7.2 Single Password Symmetric Encryption Method
------------------------------------------------
-
-   7.2.1 The Single Password Symmetric Encryption Method using strong    
-   encryption algorithms operates similarly to the traditional 
-   PKWARE encryption defined in this format.  Additional data 
-   structures are added to support the processing needs of the 
-   strong algorithms.
-
-   The Strong Encryption data structures are:
-
-   7.2.2 General Purpose Bits - Bits 0 and 6 of the General Purpose bit 
-   flag in both local and central header records.  Both bits set 
-   indicates strong encryption.  Bit 13, when set indicates the Central
-   Directory is encrypted and that selected fields in the Local Header
-   are masked to hide their actual value.
-
-
-    7.2.3 Extra Field 0x0017 in central header only.
-
-    Fields to consider in this record are:
-
-       7.2.3.1 Format - the data format identifier for this record.  The only
-       value allowed at this time is the integer value 2.
-
-       7.2.3.2 AlgId - integer identifier of the encryption algorithm from the
-       following range
-
-                 0x6601 - DES
-                 0x6602 - RC2 (version needed to extract < 5.2)
-                 0x6603 - 3DES 168
-                 0x6609 - 3DES 112
-                 0x660E - AES 128 
-                 0x660F - AES 192 
-                 0x6610 - AES 256 
-                 0x6702 - RC2 (version needed to extract >= 5.2)
-                 0x6720 - Blowfish
-                 0x6721 - Twofish
-                 0x6801 - RC4
-                 0xFFFF - Unknown algorithm
-
-       7.2.3.3 Bitlen - Explicit bit length of key
-
-                 32 - 448 bits
-           
-       7.2.3.4 Flags - Processing flags needed for decryption
-
-                 0x0001 - Password is required to decrypt
-                 0x0002 - Certificates only
-                 0x0003 - Password or certificate required to decrypt
-
-                 Values > 0x0003 reserved for certificate processing
-
-
-   7.2.4 Decryption header record preceding compressed file data.
-
-                 -Decryption Header:
-
-                  Value     Size     Description
-                  -----     ----     -----------
-                  IVSize    2 bytes  Size of initialization vector (IV)
-                  IVData    IVSize   Initialization vector for this file
-                  Size      4 bytes  Size of remaining decryption header data
-                  Format    2 bytes  Format definition for this record
-                  AlgID     2 bytes  Encryption algorithm identifier
-                  Bitlen    2 bytes  Bit length of encryption key
-                  Flags     2 bytes  Processing flags
-                  ErdSize   2 bytes  Size of Encrypted Random Data
-                  ErdData   ErdSize  Encrypted Random Data
-                  Reserved1 4 bytes  Reserved certificate processing data
-                  Reserved2 (var)    Reserved for certificate processing data
-                  VSize     2 bytes  Size of password validation data
-                  VData     VSize-4  Password validation data
-                  VCRC32    4 bytes  Standard ZIP CRC32 of password validation data
-
-       7.2.4.1 IVData - The size of the IV should match the algorithm block size.
-       The IVData can be completely random data.  If the size of
-       the randomly generated data does not match the block size
-       it should be complemented with zero's or truncated as
-       necessary.  If IVSize is 0,then IV = CRC32 + Uncompressed
-       File Size (as a 64 bit little-endian, unsigned integer value).
-
-       7.2.4.2 Format - the data format identifier for this record.  The only
-       value allowed at this time is the integer value 3.
-
-       7.2.4.3 AlgId - integer identifier of the encryption algorithm from the
-       following range
-
-                     0x6601 - DES
-                     0x6602 - RC2 (version needed to extract < 5.2)
-                     0x6603 - 3DES 168
-                     0x6609 - 3DES 112
-                     0x660E - AES 128 
-                     0x660F - AES 192 
-                     0x6610 - AES 256 
-                     0x6702 - RC2 (version needed to extract >= 5.2)
-                     0x6720 - Blowfish
-                     0x6721 - Twofish
-                     0x6801 - RC4
-                     0xFFFF - Unknown algorithm
-
-        7.2.4.4 Bitlen - Explicit bit length of key
-
-                     32 - 448 bits
-               
-        7.2.4.5 Flags - Processing flags needed for decryption
-
-                     0x0001 - Password is required to decrypt
-                     0x0002 - Certificates only
-                     0x0003 - Password or certificate required to decrypt
-
-                     Values > 0x0003 reserved for certificate processing
-
-        7.2.4.6 ErdData - Encrypted random data is used to store random data that
-        is used to generate a file session key for encrypting 
-        each file.  SHA1 is used to calculate hash data used to 
-        derive keys.  File session keys are derived from a master 
-        session key generated from the user-supplied password.
-        If the Flags field in the decryption header contains 
-        the value 0x4000, then the ErdData field must be 
-        decrypted using 3DES. If the value 0x4000 is not set,
-        then the ErdData field must be decrypted using AlgId.
-
-
-        7.2.4.7 Reserved1 - Reserved for certificate processing, if value is
-        zero, then Reserved2 data is absent.  See the explanation
-        under the Certificate Processing Method for details on
-        this data structure.
-
-        7.2.4.8 Reserved2 - If present, the size of the Reserved2 data structure 
-        is located by skipping the first 4 bytes of this field 
-        and using the next 2 bytes as the remaining size.  See
-        the explanation under the Certificate Processing Method
-        for details on this data structure.
-
-        7.2.4.9 VSize - This size value will always include the 4 bytes of the
-        VCRC32 data and will be greater than 4 bytes.
-
-        7.2.4.10 VData - Random data for password validation.  This data is VSize
-        in length and VSize must be a multiple of the encryption
-        block size.  VCRC32 is a checksum value of VData.  
-        VData and VCRC32 are stored encrypted and start the
-        stream of encrypted data for a file.
-
-
-    7.2.5 Useful Tips
-
-        7.2.5.1 Strong Encryption is always applied to a file after compression. The
-        block oriented algorithms all operate in Cypher Block Chaining (CBC) 
-        mode.  The block size used for AES encryption is 16.  All other block
-        algorithms use a block size of 8.  Two IDs are defined for RC2 to 
-        account for a discrepancy found in the implementation of the RC2
-        algorithm in the cryptographic library on Windows XP SP1 and all 
-        earlier versions of Windows.  It is recommended that zero length files
-        not be encrypted, however programs should be prepared to extract them
-        if they are found within a ZIP file.
-
-        7.2.5.2 A pseudo-code representation of the encryption process is as follows:
-
-            Password = GetUserPassword()
-            MasterSessionKey = DeriveKey(SHA1(Password)) 
-            RD = CryptographicStrengthRandomData() 
-            For Each File
-               IV = CryptographicStrengthRandomData() 
-               VData = CryptographicStrengthRandomData()
-               VCRC32 = CRC32(VData)
-               FileSessionKey = DeriveKey(SHA1(IV + RD) 
-               ErdData = Encrypt(RD,MasterSessionKey,IV) 
-               Encrypt(VData + VCRC32 + FileData, FileSessionKey,IV)
-            Done
-
-        7.2.5.3 The function names and parameter requirements will depend on
-        the choice of the cryptographic toolkit selected.  Almost any
-        toolkit supporting the reference implementations for each
-        algorithm can be used.  The RSA BSAFE(r), OpenSSL, and Microsoft
-        CryptoAPI libraries are all known to work well.  
-
-
- 7.3 Single Password - Central Directory Encryption
- --------------------------------------------------
-        
-    7.3.1 Central Directory Encryption is achieved within the .ZIP format by 
-    encrypting the Central Directory structure.  This encapsulates the metadata 
-    most often used for processing .ZIP files.  Additional metadata is stored for 
-    redundancy in the Local Header for each file.  The process of concealing 
-    metadata by encrypting the Central Directory does not protect the data within 
-    the Local Header.  To avoid information leakage from the exposed metadata 
-    in the Local Header, the fields containing information about a file are masked.  
-
-    7.3.2 Local Header
-
-    Masking replaces the true content of the fields for a file in the Local 
-    Header with false information.  When masked, the Local Header is not 
-    suitable for streaming access and the options for data recovery of damaged
-    archives is reduced.  Extra Data fields that may contain confidential
-    data should not be stored within the Local Header.  The value set into
-    the Version needed to extract field should be the correct value needed to
-    extract the file without regard to Central Directory Encryption. The fields 
-    within the Local Header targeted for masking when the Central Directory is 
-    encrypted are:
-
-            Field Name                     Mask Value
-            ------------------             ---------------------------
-            compression method              0
-            last mod file time              0
-            last mod file date              0
-            crc-32                          0
-            compressed size                 0
-            uncompressed size               0
-            file name (variable size)       Base 16 value from the
-                                            range 1 - 0xFFFFFFFFFFFFFFFF
-                                            represented as a string whose
-                                            size will be set into the
-                                            file name length field
-
-    The Base 16 value assigned as a masked file name is simply a sequentially
-    incremented value for each file starting with 1 for the first file.  
-    Modifications to a ZIP file may cause different values to be stored for 
-    each file.  For compatibility, the file name field in the Local Header 
-    should never be left blank.  As of Version 6.2 of this specification, 
-    the Compression Method and Compressed Size fields are not yet masked.
-    Fields having a value of 0xFFFF or 0xFFFFFFFF for the ZIP64 format
-    should not be masked.  
-
-    7.3.3 Encrypting the Central Directory
-
-    Encryption of the Central Directory does not include encryption of the 
-    Central Directory Signature data, the Zip64 End of Central Directory
-    record, the Zip64 End of Central Directory Locator, or the End
-    of Central Directory record.  The ZIP file comment data is never
-    encrypted.
-
-    Before encrypting the Central Directory, it may optionally be compressed.
-    Compression is not required, but for storage efficiency it is assumed
-    this structure will be compressed before encrypting.  Similarly, this 
-    specification supports compressing the Central Directory without
-    requiring that it also be encrypted.  Early implementations of this
-    feature will assume the encryption method applied to files matches the 
-    encryption applied to the Central Directory.
-
-    Encryption of the Central Directory is done in a manner similar to
-    that of file encryption.  The encrypted data is preceded by a 
-    decryption header.  The decryption header is known as the Archive
-    Decryption Header.  The fields of this record are identical to
-    the decryption header preceding each encrypted file.  The location
-    of the Archive Decryption Header is determined by the value in the
-    Start of the Central Directory field in the Zip64 End of Central
-    Directory record.  When the Central Directory is encrypted, the
-    Zip64 End of Central Directory record will always be present.
-
-    The layout of the Zip64 End of Central Directory record for all
-    versions starting with 6.2 of this specification will follow the
-    Version 2 format.  The Version 2 format is as follows:
-
-    The leading fixed size fields within the Version 1 format for this
-    record remain unchanged.  The record signature for both Version 1 
-    and Version 2 will be 0x06064b50.  Immediately following the last
-    byte of the field known as the Offset of Start of Central 
-    Directory With Respect to the Starting Disk Number will begin the 
-    new fields defining Version 2 of this record.  
-
-    7.3.4 New fields for Version 2
-
-    Note: all fields stored in Intel low-byte/high-byte order.
-
-              Value                 Size       Description
-              -----                 ----       -----------
-              Compression Method    2 bytes    Method used to compress the
-                                               Central Directory
-              Compressed Size       8 bytes    Size of the compressed data
-              Original   Size       8 bytes    Original uncompressed size
-              AlgId                 2 bytes    Encryption algorithm ID
-              BitLen                2 bytes    Encryption key length
-              Flags                 2 bytes    Encryption flags
-              HashID                2 bytes    Hash algorithm identifier
-              Hash Length           2 bytes    Length of hash data
-              Hash Data             (variable) Hash data
-
-     The Compression Method accepts the same range of values as the 
-     corresponding field in the Central Header.
-
-     The Compressed Size and Original Size values will not include the
-     data of the Central Directory Signature which is compressed or
-     encrypted.
-
-     The AlgId, BitLen, and Flags fields accept the same range of values
-     the corresponding fields within the 0x0017 record. 
-
-     Hash ID identifies the algorithm used to hash the Central Directory 
-     data.  This data does not have to be hashed, in which case the
-     values for both the HashID and Hash Length will be 0.  Possible 
-     values for HashID are:
-
-              Value         Algorithm
-             ------         ---------
-             0x0000          none
-             0x0001          CRC32
-             0x8003          MD5
-             0x8004          SHA1
-             0x8007          RIPEMD160
-             0x800C          SHA256
-             0x800D          SHA384
-             0x800E          SHA512
-
-     7.3.5 When the Central Directory data is signed, the same hash algorithm
-     used to hash the Central Directory for signing should be used.
-     This is recommended for processing efficiency, however, it is 
-     permissible for any of the above algorithms to be used independent 
-     of the signing process.
-
-     The Hash Data will contain the hash data for the Central Directory.
-     The length of this data will vary depending on the algorithm used.
-
-     The Version Needed to Extract should be set to 62.
-
-     The value for the Total Number of Entries on the Current Disk will
-     be 0.  These records will no longer support random access when
-     encrypting the Central Directory.
-
-     7.3.6 When the Central Directory is compressed and/or encrypted, the
-     End of Central Directory record will store the value 0xFFFFFFFF
-     as the value for the Total Number of Entries in the Central
-     Directory.  The value stored in the Total Number of Entries in
-     the Central Directory on this Disk field will be 0.  The actual
-     values will be stored in the equivalent fields of the Zip64
-     End of Central Directory record.
-
-     7.3.7 Decrypting and decompressing the Central Directory is accomplished
-     in the same manner as decrypting and decompressing a file.
-
- 7.4 Certificate Processing Method
- ---------------------------------
-
-    The Certificate Processing Method for ZIP file encryption 
-    defines the following additional data fields:
-
-    7.4.1 Certificate Flag Values
-
-    Additional processing flags that can be present in the Flags field of both 
-    the 0x0017 field of the central directory Extra Field and the Decryption 
-    header record preceding compressed file data are:
-
-         0x0007 - reserved for future use
-         0x000F - reserved for future use
-         0x0100 - Indicates non-OAEP key wrapping was used.  If this
-                  this field is set, the version needed to extract must
-                  be at least 61.  This means OAEP key wrapping is not
-                  used when generating a Master Session Key using
-                  ErdData.
-         0x4000 - ErdData must be decrypted using 3DES-168, otherwise use the
-                  same algorithm used for encrypting the file contents.
-         0x8000 - reserved for future use
-
-
-    7.4.2 CertData - Extra Field 0x0017 record certificate data structure
-
-    The data structure used to store certificate data within the section
-    of the Extra Field defined by the CertData field of the 0x0017
-    record are as shown:
-
-          Value     Size     Description
-          -----     ----     -----------
-          RCount    4 bytes  Number of recipients.  
-          HashAlg   2 bytes  Hash algorithm identifier
-          HSize     2 bytes  Hash size
-          SRList    (var)    Simple list of recipients hashed public keys
-
-                          
-         RCount    This defines the number intended recipients whose 
-                   public keys were used for encryption.  This identifies
-                   the number of elements in the SRList.
-
-         HashAlg   This defines the hash algorithm used to calculate
-                   the public key hash of each public key used
-                   for encryption. This field currently supports
-                   only the following value for SHA-1
-
-                   0x8004 - SHA1
-
-         HSize     This defines the size of a hashed public key.
-
-         SRList    This is a variable length list of the hashed 
-                   public keys for each intended recipient.  Each 
-                   element in this list is HSize.  The total size of 
-                   SRList is determined using RCount * HSize.
-
-
-    7.4.3 Reserved1 - Certificate Decryption Header Reserved1 Data
-
-          Value     Size     Description
-          -----     ----     -----------
-          RCount    4 bytes  Number of recipients.  
-                      
-          RCount   This defines the number intended recipients whose 
-                   public keys were used for encryption.  This defines
-                   the number of elements in the REList field defined below.
-
-
-    7.4.4 Reserved2 - Certificate Decryption Header Reserved2 Data Structures
-
-
-          Value     Size     Description
-          -----     ----     -----------
-          HashAlg   2 bytes  Hash algorithm identifier
-          HSize     2 bytes  Hash size
-          REList    (var)    List of recipient data elements
-
-
-         HashAlg   This defines the hash algorithm used to calculate
-                   the public key hash of each public key used
-                   for encryption. This field currently supports
-                   only the following value for SHA-1
-
-                       0x8004 - SHA1
-
-         HSize     This defines the size of a hashed public key
-                   defined in REHData.
-
-         REList    This is a variable length of list of recipient data.  
-                   Each element in this list consists of a Recipient
-                   Element data structure as follows:
-
-
-        Recipient Element (REList) Data Structure:
-
-              Value     Size     Description
-              -----     ----     -----------
-              RESize    2 bytes  Size of REHData + REKData
-              REHData   HSize    Hash of recipients public key
-              REKData   (var)    Simple key blob
-
-
-             RESize    This defines the size of an individual REList 
-                       element.  This value is the combined size of the
-                       REHData field + REKData field.  REHData is defined by
-                       HSize.  REKData is variable and can be calculated
-                       for each REList element using RESize and HSize.
-
-             REHData   Hashed public key for this recipient.
-
-             REKData   Simple Key Blob.  The format of this data structure
-                       is identical to that defined in the Microsoft
-                       CryptoAPI and generated using the CryptExportKey()
-                       function.  The version of the Simple Key Blob
-                       supported at this time is 0x02 as defined by
-                       Microsoft.
-
-7.5 Certificate Processing - Central Directory Encryption
----------------------------------------------------------
-        
-    7.5.1 Central Directory Encryption using Digital Certificates will 
-    operate in a manner similar to that of Single Password Central
-    Directory Encryption.  This record will only be present when there 
-    is data to place into it.  Currently, data is placed into this
-    record when digital certificates are used for either encrypting 
-    or signing the files within a ZIP file.  When only password 
-    encryption is used with no certificate encryption or digital 
-    signing, this record is not currently needed. When present, this 
-    record will appear before the start of the actual Central Directory 
-    data structure and will be located immediately after the Archive 
-    Decryption Header if the Central Directory is encrypted.
-
-    7.5.2 The Archive Extra Data record will be used to store the following
-    information.  Additional data may be added in future versions.
-
-    Extra Data Fields:
-
-    0x0014 - PKCS#7 Store for X.509 Certificates
-    0x0016 - X.509 Certificate ID and Signature for central directory
-    0x0019 - PKCS#7 Encryption Recipient Certificate List
-
-    The 0x0014 and 0x0016 Extra Data records that otherwise would be 
-    located in the first record of the Central Directory for digital 
-    certificate processing. When encrypting or compressing the Central 
-    Directory, the 0x0014 and 0x0016 records must be located in the 
-    Archive Extra Data record and they should not remain in the first 
-    Central Directory record.  The Archive Extra Data record will also 
-    be used to store the 0x0019 data. 
-
-    7.5.3 When present, the size of the Archive Extra Data record will be
-    included in the size of the Central Directory.  The data of the
-    Archive Extra Data record will also be compressed and encrypted
-    along with the Central Directory data structure.
-
-7.6 Certificate Processing Differences
---------------------------------------
-
-    7.6.1 The Certificate Processing Method of encryption differs from the
-    Single Password Symmetric Encryption Method as follows.  Instead
-    of using a user-defined password to generate a master session key,
-    cryptographically random data is used.  The key material is then
-    wrapped using standard key-wrapping techniques.  This key material
-    is wrapped using the public key of each recipient that will need
-    to decrypt the file using their corresponding private key.
-
-    7.6.2 This specification currently assumes digital certificates will follow
-    the X.509 V3 format for 1024 bit and higher RSA format digital
-    certificates.  Implementation of this Certificate Processing Method
-    requires supporting logic for key access and management.  This logic
-    is outside the scope of this specification.
-
-7.7 OAEP Processing with Certificate-based Encryption
------------------------------------------------------
-
-    7.7.1 OAEP stands for Optimal Asymmetric Encryption Padding.  It is a
-    strengthening technique used for small encoded items such as decryption
-    keys.  This is commonly applied in cryptographic key-wrapping techniques
-    and is supported by PKCS #1.  Versions 5.0 and 6.0 of this specification 
-    were designed to support OAEP key-wrapping for certificate-based 
-    decryption keys for additional security.  
-
-    7.7.2 Support for private keys stored on Smartcards or Tokens introduced
-    a conflict with this OAEP logic.  Most card and token products do 
-    not support the additional strengthening applied to OAEP key-wrapped 
-    data.  In order to resolve this conflict, versions 6.1 and above of this 
-    specification will no longer support OAEP when encrypting using 
-    digital certificates. 
-
-    7.7.3 Versions of PKZIP available during initial development of the 
-    certificate processing method set a value of 61 into the 
-    version needed to extract field for a file.  This indicates that 
-    non-OAEP key wrapping is used.  This affects certificate encryption 
-    only, and password encryption functions should not be affected by 
-    this value.  This means values of 61 may be found on files encrypted
-    with certificates only, or on files encrypted with both password
-    encryption and certificate encryption.  Files encrypted with both
-    methods can safely be decrypted using the password methods documented.
-
-8.0  Splitting and Spanning ZIP files
--------------------------------------
-
-    8.1 Spanned ZIP files
-
-      8.1.1 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. 
-
-    8.2 Split ZIP files
-
-      8.2.1 File splitting is a newer derivation 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.
-
-    8.3  File Naming Differences
-
-      8.3.1 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.
-
-      8.3.2 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.
-
-      8.3.3 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
-
-      8.3.4 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.
-        
-    8.4  Spanned Self-extracting ZIP Files
-        
-      8.4.1 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.
-
-    8.5  Capacities and Markers
-        
-      8.5.1 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
-          
-      8.5.2 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.
-
-      8.5.3 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.  
-
-      8.5.4 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.
-
-      8.5.5 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.  
-
-9.0 Change Process
-------------------
-
-   9.1 In order for the .ZIP file format to remain a viable technology, this
-   specification should be considered as open for periodic review and
-   revision.  Although this format was originally designed with a 
-   certain level of extensibility, not all changes in technology
-   (present or future) were or will be necessarily considered in its
-   design.  
-
-   9.2 If your application requires new definitions to the
-   extensible sections in this format, or if you would like to 
-   submit new data structures or new capabilities, please forward 
-   your request to zipformat@pkware.com.  All submissions will be 
-   reviewed by the ZIP File Specification Committee for possible 
-   inclusion into future versions of this specification.  
-
-   9.3 Periodic revisions to this specification will be published as
-   DRAFT or as FINAL status to ensure interoperability. We encourage 
-   comments and feedback that may help improve clarity or content.
-
-
-10.0 Incorporating PKWARE Proprietary Technology into Your Product
-------------------------------------------------------------------
-
-   10.1 The Use or Implementation in a product of APPNOTE technological 
-   components pertaining to either strong encryption or patching requires 
-   a separate, executed license agreement from PKWARE. Please contact 
-   PKWARE at zipformat@pkware.com or +1-414-289-9788 with regard to 
-   acquiring such a license.
-
-   10.2 Additional information regarding PKWARE proprietray technology is 
-   available at http://www.pkware.com/appnote.
-
-11.0 Acknowledgements
----------------------
-
-   In addition to the above mentioned contributors to PKZIP and PKUNZIP,
-   PKWARE would like to extend special thanks to Robert Mahoney for 
-   suggesting the extension .ZIP for this software.
-
-12.0 References
----------------
-
-   Fiala, Edward R., and Greene, Daniel H., "Data compression with
-      finite windows",  Communications of the ACM, Volume 32, Number 4,
-      April 1989, pages 490-505.
-
-   Held, Gilbert, "Data Compression, Techniques and Applications,
-      Hardware and Software Considerations", John Wiley & Sons, 1987.
-
-   Huffman, D.A., "A method for the construction of minimum-redundancy
-      codes", Proceedings of the IRE, Volume 40, Number 9, September 1952,
-      pages 1098-1101.
-
-   Nelson, Mark, "LZW Data Compression", Dr. Dobbs Journal, Volume 14,
-      Number 10, October 1989, pages 29-37.
-
-   Nelson, Mark, "The Data Compression Book",  M&T Books, 1991.
-
-   Storer, James A., "Data Compression, Methods and Theory",
-      Computer Science Press, 1988
-
-   Welch, Terry, "A Technique for High-Performance Data Compression",
-      IEEE Computer, Volume 17, Number 6, June 1984, pages 8-19.
-
-   Ziv, J. and Lempel, A., "A universal algorithm for sequential data
-      compression", Communications of the ACM, Volume 30, Number 6,
-       June 1987, pages 520-540.
-
-   Ziv, J. and Lempel, A., "Compression of individual sequences via
-      variable-rate coding", IEEE Transactions on Information Theory,
-      Volume 24, Number 5, September 1978, pages 530-536.
-
-
-APPENDIX A - AS/400 Extra Field (0x0065) Attribute Definitions
---------------------------------------------------------------
-
-A.1 Field Definition Structure:
-
-   a. field length including length             2 bytes
-   b. field code                                2 bytes
-   c. data                                      x bytes
-
-A.2 Field Code  Description
-
-   4001     Source type i.e. CLP etc
-   4002     The text description of the library 
-   4003     The text description of the file
-   4004     The text description of the member
-   4005     x'F0' or 0 is PF-DTA,  x'F1' or 1 is PF_SRC
-   4007     Database Type Code                  1 byte
-   4008     Database file and fields definition
-   4009     GZIP file type                      2 bytes
-   400B     IFS code page                       2 bytes
-   400C     IFS Creation Time                   4 bytes
-   400D     IFS Access Time                     4 bytes
-   400E     IFS Modification time               4 bytes
-   005C     Length of the records in the file   2 bytes
-   0068     GZIP two words                      8 bytes
-
-APPENDIX B - z/OS Extra Field (0x0065) Attribute Definitions
-------------------------------------------------------------
-
-B.1 Field Definition Structure:
-
-   a. field length including length             2 bytes
-   b. field code                                2 bytes
-   c. data                                      x bytes
-
-B.2 Field Code  Description
-
-   0001     File Type                           2 bytes 
-   0002     NonVSAM Record Format               1 byte
-   0003     Reserved                
-   0004     NonVSAM Block Size                  2 bytes Big Endian
-   0005     Primary Space Allocation            3 bytes Big Endian
-   0006     Secondary Space Allocation          3 bytes Big Endian
-   0007     Space Allocation Type1 byte flag                
-   0008     Modification Date                   Retired with PKZIP 5.0 +
-   0009     Expiration Date                     Retired with PKZIP 5.0 +
-   000A     PDS Directory Block Allocation      3 bytes Big Endian binary value
-   000B     NonVSAM Volume List                 variable                
-   000C     UNIT Reference                      Retired with PKZIP 5.0 +
-   000D     DF/SMS Management Class             8 bytes EBCDIC Text Value
-   000E     DF/SMS Storage Class                8 bytes EBCDIC Text Value
-   000F     DF/SMS Data Class                   8 bytes EBCDIC Text Value
-   0010     PDS/PDSE Member Info.               30 bytes        
-   0011     VSAM sub-filetype                   2 bytes                
-   0012     VSAM LRECL                          13 bytes EBCDIC "(num_avg num_max)"
-   0013     VSAM Cluster Name                   Retired with PKZIP 5.0 +
-   0014     VSAM KSDS Key Information           13 bytes EBCDIC "(num_length num_position)"
-   0015     VSAM Average LRECL                  5 bytes EBCDIC num_value padded with blanks
-   0016     VSAM Maximum LRECL                  5 bytes EBCDIC num_value padded with blanks
-   0017     VSAM KSDS Key Length                5 bytes EBCDIC num_value padded with blanks
-   0018     VSAM KSDS Key Position              5 bytes EBCDIC num_value padded with blanks
-   0019     VSAM Data Name                      1-44 bytes EBCDIC text string
-   001A     VSAM KSDS Index Name                1-44 bytes EBCDIC text string
-   001B     VSAM Catalog Name                   1-44 bytes EBCDIC text string
-   001C     VSAM Data Space Type                9 bytes EBCDIC text string
-   001D     VSAM Data Space Primary             9 bytes EBCDIC num_value left-justified
-   001E     VSAM Data Space Secondary           9 bytes EBCDIC num_value left-justified
-   001F     VSAM Data Volume List               variable EBCDIC text list of 6-character Volume IDs
-   0020     VSAM Data Buffer Space              8 bytes EBCDIC num_value left-justified
-   0021     VSAM Data CISIZE                    5 bytes EBCDIC num_value left-justified
-   0022     VSAM Erase Flag                     1 byte flag                
-   0023     VSAM Free CI %                      3 bytes EBCDIC num_value left-justified
-   0024     VSAM Free CA %                      3 bytes EBCDIC num_value left-justified
-   0025     VSAM Index Volume List              variable EBCDIC text list of 6-character Volume IDs
-   0026     VSAM Ordered Flag                   1 byte flag                
-   0027     VSAM REUSE Flag                     1 byte flag                
-   0028     VSAM SPANNED Flag                   1 byte flag                
-   0029     VSAM Recovery Flag                  1 byte flag                
-   002A     VSAM  WRITECHK  Flag                1 byte flag                
-   002B     VSAM Cluster/Data SHROPTS           3 bytes EBCDIC "n,y"        
-   002C     VSAM Index SHROPTS                  3 bytes EBCDIC "n,y"        
-   002D     VSAM Index Space Type               9 bytes EBCDIC text string
-   002E     VSAM Index Space Primary            9 bytes EBCDIC num_value left-justified
-   002F     VSAM Index Space Secondary          9 bytes EBCDIC num_value left-justified
-   0030     VSAM Index CISIZE                   5 bytes EBCDIC num_value left-justified
-   0031     VSAM Index IMBED                    1 byte flag                
-   0032     VSAM Index Ordered Flag             1 byte flag                
-   0033     VSAM REPLICATE Flag                 1 byte flag                
-   0034     VSAM Index REUSE Flag               1 byte flag                
-   0035     VSAM Index WRITECHK Flag            1 byte flag Retired with PKZIP 5.0 +
-   0036     VSAM Owner                          8 bytes EBCDIC text string
-   0037     VSAM Index Owner                    8 bytes EBCDIC text string
-   0038     Reserved
-   0039     Reserved
-   003A     Reserved
-   003B     Reserved
-   003C     Reserved
-   003D     Reserved
-   003E     Reserved
-   003F     Reserved
-   0040     Reserved
-   0041     Reserved
-   0042     Reserved
-   0043     Reserved
-   0044     Reserved
-   0045     Reserved
-   0046     Reserved
-   0047     Reserved
-   0048     Reserved
-   0049     Reserved
-   004A     Reserved
-   004B     Reserved
-   004C     Reserved
-   004D     Reserved
-   004E     Reserved
-   004F     Reserved
-   0050     Reserved
-   0051     Reserved
-   0052     Reserved
-   0053     Reserved
-   0054     Reserved
-   0055     Reserved
-   0056     Reserved
-   0057     Reserved
-   0058     PDS/PDSE Member TTR Info.           6 bytes  Big Endian
-   0059     PDS 1st LMOD Text TTR               3 bytes  Big Endian
-   005A     PDS LMOD EP Rec #                   4 bytes  Big Endian
-   005B     Reserved
-   005C     Max Length of records               2 bytes  Big Endian
-   005D     PDSE Flag                           1 byte flag
-   005E     Reserved
-   005F     Reserved
-   0060     Reserved
-   0061     Reserved
-   0062     Reserved
-   0063     Reserved
-   0064     Reserved
-   0065     Last Date Referenced                4 bytes  Packed Hex "yyyymmdd"
-   0066     Date Created                        4 bytes  Packed Hex "yyyymmdd"
-   0068     GZIP two words                      8 bytes
-   0071     Extended NOTE Location              12 bytes Big Endian
-   0072     Archive device UNIT                 6 bytes  EBCDIC
-   0073     Archive 1st Volume                  6 bytes  EBCDIC
-   0074     Archive 1st VOL File Seq#           2 bytes  Binary
-
-APPENDIX C - Zip64 Extensible Data Sector Mappings 
----------------------------------------------------
-
-         -Z390   Extra Field:
-
-          The following is the general layout of the attributes for the 
-          ZIP 64 "extra" block for extended tape operations.  
-
-          Note: some fields stored in Big Endian format.  All text is 
-          in EBCDIC format unless otherwise specified.
-
-          Value       Size          Description
-          -----       ----          -----------
-  (Z390)  0x0065      2 bytes       Tag for this "extra" block type
-          Size        4 bytes       Size for the following data block
-          Tag         4 bytes       EBCDIC "Z390"
-          Length71    2 bytes       Big Endian
-          Subcode71   2 bytes       Enote type code
-          FMEPos      1 byte
-          Length72    2 bytes       Big Endian
-          Subcode72   2 bytes       Unit type code
-          Unit        1 byte        Unit
-          Length73    2 bytes       Big Endian
-          Subcode73   2 bytes       Volume1 type code
-          FirstVol    1 byte        Volume
-          Length74    2 bytes       Big Endian
-          Subcode74   2 bytes       FirstVol file sequence
-          FileSeq     2 bytes       Sequence 
-
-APPENDIX D - Language Encoding (EFS)
-------------------------------------
-
-D.1 The ZIP format has historically supported only the original IBM PC character 
-encoding set, commonly referred to as IBM Code Page 437.  This limits storing 
-file name characters to only those within the original MS-DOS range of values 
-and does not properly support file names in other character encodings, or 
-languages. To address this limitation, this specification will support the 
-following change. 
-
-D.2 If general purpose bit 11 is unset, the file name and comment should conform 
-to the original ZIP character encoding.  If general purpose bit 11 is set, the 
-filename and comment must support The Unicode Standard, Version 4.1.0 or 
-greater using the character encoding form defined by the UTF-8 storage 
-specification.  The Unicode Standard is published by the The Unicode
-Consortium (www.unicode.org).  UTF-8 encoded data stored within ZIP files 
-is expected to not include a byte order mark (BOM). 
-
-D.3 Applications may choose to supplement this file name storage through the use 
-of the 0x0008 Extra Field.  Storage for this optional field is currently 
-undefined, however it will be used to allow storing extended information 
-on source or target encoding that may further assist applications with file 
-name, or file content encoding tasks.  Please contact PKWARE with any
-requirements on how this field should be used.
-
-D.4 The 0x0008 Extra Field storage may be used with either setting for general 
-purpose bit 11.  Examples of the intended usage for this field is to store 
-whether "modified-UTF-8" (JAVA) is used, or UTF-8-MAC.  Similarly, other 
-commonly used character encoding (code page) designations can be indicated 
-through this field.  Formalized values for use of the 0x0008 record remain 
-undefined at this time.  The definition for the layout of the 0x0008 field
-will be published when available.  Use of the 0x0008 Extra Field provides
-for storing data within a ZIP file in an encoding other than IBM Code
-Page 437 or UTF-8.
-
-D.5 General purpose bit 11 will not imply any encoding of file content or
-password.  Values defining character encoding for file content or 
-password must be stored within the 0x0008 Extended Language Encoding 
-Extra Field.
-
-D.6 Ed Gordon of the Info-ZIP group has defined a pair of "extra field" records 
-that can be used to store UTF-8 file name and file comment fields.  These
-records can be used for cases when the general purpose bit 11 method
-for storing UTF-8 data in the standard file name and comment fields is
-not desirable.  A common case for this alternate method is if backward
-compatibility with older programs is required.
-
-D.7 Definitions for the record structure of these fields are included above 
-in the section on 3rd party mappings for "extra field" records.  These
-records are identified by Header ID's 0x6375 (Info-ZIP Unicode Comment 
-Extra Field) and 0x7075 (Info-ZIP Unicode Path Extra Field).
-
-D.8 The choice of which storage method to use when writing a ZIP file is left
-to the implementation.  Developers should expect that a ZIP file may 
-contain either method and should provide support for reading data in 
-either format. Use of general purpose bit 11 reduces storage requirements 
-for file name data by not requiring additional "extra field" data for
-each file, but can result in older ZIP programs not being able to extract 
-files.  Use of the 0x6375 and 0x7075 records will result in a ZIP file 
-that should always be readable by older ZIP programs, but requires more 
-storage per file to write file name and/or file comment fields.
diff --git a/docs/extrafld.txt b/docs/extrafld.txt
deleted file mode 100644
index 624e05c..0000000
--- a/docs/extrafld.txt
+++ /dev/null
@@ -1,1372 +0,0 @@
-The following are the known types of zipfile extra fields as of this
-writing.  Extra fields are documented in PKWARE's appnote.txt and are
-intended to allow for backward- and forward-compatible extensions to
-the zipfile format.  Multiple extra-field types may be chained together,
-provided that the total length of all extra-field data is less than 64KB.
-(In fact, PKWARE requires that the total length of the entire file header,
-including timestamp, file attributes, filename, comment, extra field, etc.,
-be no more than 64KB.)
-
-Each extra-field type (or subblock) must contain a four-byte header con-
-sisting of a two-byte header ID and a two-byte length (little-endian) for
-the remaining data in the subblock.  If there are additional subblocks
-within the extra field, the header for each one will appear immediately
-following the data for the previous subblock (i.e., with no padding for
-alignment).
-
-All integer fields in the descriptions below are in little-endian (Intel)
-format unless otherwise specified.  Note that "Short" means two bytes,
-"Long" means four bytes, and "Long-Long" means eight bytes, regardless
-of their native sizes.  Unless specifically noted, all integer fields should
-be interpreted as unsigned (non-negative) numbers.
-
-Christian Spieler, 20010517
-
-Updated to include the Unicode extra fields.  Added new Unix extra field.
-
-Ed Gordon, 20060819, 20070607, 20070909, 20080426, 20080509
-
-                        -------------------------
-
-          Header ID's of 0 thru 31 are reserved for use by PKWARE.
-          The remaining ID's can be used by third party vendors for
-          proprietary usage.
-
-          The current Header ID mappings defined by PKWARE are:
-
-          0x0001        ZIP64 extended information extra field
-          0x0007        AV Info
-          0x0009        OS/2 extended attributes      (also Info-ZIP)
-          0x000a        NTFS (Win9x/WinNT FileTimes)
-          0x000c        OpenVMS                       (also Info-ZIP)
-          0x000d        Unix
-          0x000f        Patch Descriptor
-          0x0014        PKCS#7 Store for X.509 Certificates
-          0x0015        X.509 Certificate ID and Signature for
-                        individual file
-          0x0016        X.509 Certificate ID for Central Directory
-
-          The Header ID mappings defined by Info-ZIP and third parties are:
-
-          0x0065        IBM S/390 attributes - uncompressed
-          0x0066        IBM S/390 attributes - compressed
-          0x07c8        Info-ZIP Macintosh (old, J. Lee)
-          0x2605        ZipIt Macintosh (first version)
-          0x2705        ZipIt Macintosh v 1.3.5 and newer (w/o full filename)
-          0x334d        Info-ZIP Macintosh (new, D. Haase's 'Mac3' field )
-          0x4154        Tandem NSK
-          0x4341        Acorn/SparkFS (David Pilling)
-          0x4453        Windows NT security descriptor (binary ACL)
-          0x4704        VM/CMS
-          0x470f        MVS
-          0x4854        Theos, old inofficial port
-          0x4b46        FWKCS MD5 (see below)
-          0x4c41        OS/2 access control list (text ACL)
-          0x4d49        Info-ZIP OpenVMS (obsolete)
-          0x4d63        Macintosh SmartZIP, by Macro Bambini
-          0x4f4c        Xceed original location extra field
-          0x5356        AOS/VS (binary ACL)
-          0x5455        extended timestamp
-          0x5855        Info-ZIP Unix (original; also OS/2, NT, etc.)
-          0x554e        Xceed unicode extra field
-          0x6375        Info-ZIP Unicode Comment
-          0x6542        BeOS (BeBox, PowerMac, etc.)
-          0x6854        Theos
-          0x7075        Info-ZIP Unicode Path
-          0x756e        ASi Unix
-          0x7855        Info-ZIP Unix (previous new)
-          0x7875        Info-ZIP Unix (new)
-          0xfb4a        SMS/QDOS
-
-The following are detailed descriptions of the known extra-field block types:
-
-         -OS/2 Extended Attributes Extra Field:
-          ====================================
-
-          The following is the layout of the OS/2 extended attributes "extra"
-          block.  (Last Revision 19960922)
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (OS/2)  0x0009        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed EA data size
-          CType         Short       compression type
-          EACRC         Long        CRC value for uncompressed EA data
-          (var.)        variable    compressed EA data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (OS/2)  0x0009        Short       tag for this extra block type
-          TSize         Short       total data size for this block (4)
-          BSize         Long        size of uncompressed local EA data
-
-          The value of CType is interpreted according to the "compression
-          method" section above; i.e., 0 for stored, 8 for deflated, etc.
-
-          The OS/2 extended attribute structure (FEA2LIST) is compressed and
-          then stored in its entirety within this structure.  There will only
-          ever be one block of data in the variable-length field.
-
-
-         -OS/2 Access Control List Extra Field:
-          ====================================
-
-          The following is the layout of the OS/2 ACL extra block.
-          (Last Revision 19960922)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (ACL)   0x4c41        Short       tag for this extra block type ("AL")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed ACL data size
-          CType         Short       compression type
-          EACRC         Long        CRC value for uncompressed ACL data
-          (var.)        variable    compressed ACL data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (ACL)   0x4c41        Short       tag for this extra block type ("AL")
-          TSize         Short       total data size for this block (4)
-          BSize         Long        size of uncompressed local ACL data
-
-          The value of CType is interpreted according to the "compression
-          method" section above; i.e., 0 for stored, 8 for deflated, etc.
-
-          The uncompressed ACL data consist of a text header of the form
-          "ACL1:%hX,%hd\n", where the first field is the OS/2 ACCINFO acc_attr
-          member and the second is acc_count, followed by acc_count strings
-          of the form "%s,%hx\n", where the first field is acl_ugname (user
-          group name) and the second acl_access.  This block type will be
-          extended for other operating systems as needed.
-
-
-         -Windows NT Security Descriptor Extra Field:
-          ==========================================
-
-          The following is the layout of the NT Security Descriptor (another
-          type of ACL) extra block.  (Last Revision 19960922)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (SD)    0x4453        Short       tag for this extra block type ("SD")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed SD data size
-          Version       Byte        version of uncompressed SD data format
-          CType         Short       compression type
-          EACRC         Long        CRC value for uncompressed SD data
-          (var.)        variable    compressed SD data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (SD)    0x4453        Short       tag for this extra block type ("SD")
-          TSize         Short       total data size for this block (4)
-          BSize         Long        size of uncompressed local SD data
-
-          The value of CType is interpreted according to the "compression
-          method" section above; i.e., 0 for stored, 8 for deflated, etc.
-          Version specifies how the compressed data are to be interpreted
-          and allows for future expansion of this extra field type.  Currently
-          only version 0 is defined.
-
-          For version 0, the compressed data are to be interpreted as a single
-          valid Windows NT SECURITY_DESCRIPTOR data structure, in self-relative
-          format.
-
-
-         -PKWARE Win95/WinNT Extra Field:
-          ==============================
-
-          The following description covers PKWARE's "NTFS" attributes
-          "extra" block, introduced with the release of PKZIP 2.50 for
-          Windows. (Last Revision 20001118)
-
-          (Note: At this time the Mtime, Atime and Ctime values may
-          be used on any WIN32 system.)
-         [Info-ZIP note: In the current implementations, this field has
-          a fixed total data size of 32 bytes and is only stored as local
-          extra field.]
-
-          Value         Size        Description
-          -----         ----        -----------
-  (NTFS)  0x000a        Short       Tag for this "extra" block type
-          TSize         Short       Total Data Size for this block
-          Reserved      Long        for future use
-          Tag1          Short       NTFS attribute tag value #1
-          Size1         Short       Size of attribute #1, in bytes
-          (var.)        SubSize1    Attribute #1 data
-          .
-          .
-          .
-          TagN          Short       NTFS attribute tag value #N
-          SizeN         Short       Size of attribute #N, in bytes
-          (var.)        SubSize1    Attribute #N data
-
-          For NTFS, values for Tag1 through TagN are as follows:
-          (currently only one set of attributes is defined for NTFS)
-
-          Tag        Size       Description
-          -----      ----       -----------
-          0x0001     2 bytes    Tag for attribute #1
-          Size1      2 bytes    Size of attribute #1, in bytes (24)
-          Mtime      8 bytes    64-bit NTFS file last modification time
-          Atime      8 bytes    64-bit NTFS file last access time
-          Ctime      8 bytes    64-bit NTFS file creation time
-
-          The total length for this block is 28 bytes, resulting in a
-          fixed size value of 32 for the TSize field of the NTFS block.
-
-          The NTFS filetimes are 64-bit unsigned integers, stored in Intel
-          (least significant byte first) byte order. They determine the
-          number of 1.0E-07 seconds (1/10th microseconds!) past WinNT "epoch",
-          which is "01-Jan-1601 00:00:00 UTC".
-
-
-         -PKWARE OpenVMS Extra Field:
-          ==========================
-
-          The following is the layout of PKWARE's OpenVMS attributes "extra"
-          block.  (Last Revision 12/17/91)
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (VMS)   0x000c        Short       Tag for this "extra" block type
-          TSize         Short       Total Data Size for this block
-          CRC           Long        32-bit CRC for remainder of the block
-          Tag1          Short       OpenVMS attribute tag value #1
-          Size1         Short       Size of attribute #1, in bytes
-          (var.)        Size1       Attribute #1 data
-          .
-          .
-          .
-          TagN          Short       OpenVMS attribute tage value #N
-          SizeN         Short       Size of attribute #N, in bytes
-          (var.)        SizeN       Attribute #N data
-
-          Rules:
-
-          1. There will be one or more of attributes present, which
-             will each be preceded by the above TagX & SizeX values.
-             These values are identical to the ATR$C_XXXX and
-             ATR$S_XXXX constants which are defined in ATR.H under
-             OpenVMS C.  Neither of these values will ever be zero.
-
-          2. No word alignment or padding is performed.
-
-          3. A well-behaved PKZIP/OpenVMS program should never produce
-             more than one sub-block with the same TagX value.  Also,
-             there will never be more than one "extra" block of type
-             0x000c in a particular directory record.
-
-
-         -Info-ZIP VMS Extra Field:
-          ========================
-
-          The following is the layout of Info-ZIP's VMS attributes extra
-          block for VAX or Alpha AXP.  The local-header and central-header
-          versions are identical.  (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (VMS2)  0x4d49        Short       tag for this extra block type ("JM")
-          TSize         Short       total data size for this block
-          ID            Long        block ID
-          Flags         Short       info bytes
-          BSize         Short       uncompressed block size
-          Reserved      Long        (reserved)
-          (var.)        variable    compressed VMS file-attributes block
-
-          The block ID is one of the following unterminated strings:
-
-                "VFAB"          struct FAB
-                "VALL"          struct XABALL
-                "VFHC"          struct XABFHC
-                "VDAT"          struct XABDAT
-                "VRDT"          struct XABRDT
-                "VPRO"          struct XABPRO
-                "VKEY"          struct XABKEY
-                "VMSV"          version (e.g., "V6.1"; truncated at hyphen)
-                "VNAM"          reserved
-
-          The lower three bits of Flags indicate the compression method.  The
-          currently defined methods are:
-
-                0       stored (not compressed)
-                1       simple "RLE"
-                2       deflated
-
-          The "RLE" method simply replaces zero-valued bytes with zero-valued
-          bits and non-zero-valued bytes with a "1" bit followed by the byte
-          value.
-
-          The variable-length compressed data contains only the data corre-
-          sponding to the indicated structure or string.  Typically multiple
-          VMS2 extra fields are present (each with a unique block type).
-
-
-         -Info-ZIP Macintosh Extra Field:
-          ==============================
-
-          The following is the layout of the (old) Info-ZIP resource-fork extra
-          block for Macintosh.  The local-header and central-header versions
-          are identical.  (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac)   0x07c8        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          "JLEE"        beLong      extra-field signature
-          FInfo         16 bytes    Macintosh FInfo structure
-          CrDat         beLong      HParamBlockRec fileParam.ioFlCrDat
-          MdDat         beLong      HParamBlockRec fileParam.ioFlMdDat
-          Flags         beLong      info bits
-          DirID         beLong      HParamBlockRec fileParam.ioDirID
-          VolName       28 bytes    volume name (optional)
-
-          All fields but the first two are in native Macintosh format
-          (big-endian Motorola order, not little-endian Intel).  The least
-          significant bit of Flags is 1 if the file is a data fork, 0 other-
-          wise.  In addition, if this extra field is present, the filename
-          has an extra 'd' or 'r' appended to indicate data fork or resource
-          fork.  The 28-byte VolName field may be omitted.
-
-
-         -ZipIt Macintosh Extra Field (long):
-          ==================================
-
-          The following is the layout of the ZipIt extra block for Macintosh.
-          The local-header and central-header versions are identical.
-          (Last Revision 19970130)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac2)  0x2605        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          "ZPIT"        beLong      extra-field signature
-          FnLen         Byte        length of FileName
-          FileName      variable    full Macintosh filename
-          FileType      Byte[4]     four-byte Mac file type string
-          Creator       Byte[4]     four-byte Mac creator string
-
-
-         -ZipIt Macintosh Extra Field (short):
-          ===================================
-
-          The following is the layout of a shortened variant of the
-          ZipIt extra block for Macintosh (without "full name" entry).
-          This variant is used by ZipIt 1.3.5 and newer for entries that
-          do not need a "full Mac filename" record.
-          The local-header and central-header versions are identical.
-          (Last Revision 19980903)
-
-          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
-
-
-         -Info-ZIP Macintosh Extra Field (new):
-          ====================================
-
-          The following is the layout of the (new) Info-ZIP extra
-          block for Macintosh, designed by Dirk Haase.
-          All values are in little-endian.
-          (Last Revision 19981005)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac3)  0x334d        Short       tag for this extra block type ("M3")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed finder attribute data size
-          Flags         Short       info bits
-          fdType        Byte[4]     Type of the File (4-byte string)
-          fdCreator     Byte[4]     Creator of the File (4-byte string)
-          (CType)       Short       compression type
-          (CRC)         Long        CRC value for uncompressed MacOS data
-          Attribs       variable    finder attribute data (see below)
-
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Mac3)  0x334d        Short       tag for this extra block type ("M3")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed finder attribute data size
-          Flags         Short       info bits
-          fdType        Byte[4]     Type of the File (4-byte string)
-          fdCreator     Byte[4]     Creator of the File (4-byte string)
-
-          The third bit of Flags in both headers indicates whether
-          the LOCAL extra field is uncompressed (and therefore whether CType
-          and CRC are omitted):
-
-          Bits of the Flags:
-              bit 0           if set, file is a data fork; otherwise unset
-              bit 1           if set, filename will be not changed
-              bit 2           if set, Attribs is uncompressed (no CType, CRC)
-              bit 3           if set, date and times are in 64 bit
-                              if zero date and times are in 32 bit.
-              bit 4           if set, timezone offsets fields for the native
-                              Mac times are omitted (UTC support deactivated)
-              bits 5-15       reserved;
-
-
-          Attributes:
-
-          Attribs is a Mac-specific block of data in little-endian format with
-          the following structure (if compressed, uncompress it first):
-
-          Value         Size        Description
-          -----         ----        -----------
-          fdFlags       Short       Finder Flags
-          fdLocation.v  Short       Finder Icon Location
-          fdLocation.h  Short       Finder Icon Location
-          fdFldr        Short       Folder containing file
-
-          FXInfo        16 bytes    Macintosh FXInfo structure
-            FXInfo-Structure:
-                fdIconID        Short
-                fdUnused[3]     Short       unused but reserved 6 bytes
-                fdScript        Byte        Script flag and number
-                fdXFlags        Byte        More flag bits
-                fdComment       Short       Comment ID
-                fdPutAway       Long        Home Dir ID
-
-          FVersNum      Byte        file version number
-                                    may be not used by MacOS
-          ACUser        Byte        directory access rights
-
-          FlCrDat       ULong       date and time of creation
-          FlMdDat       ULong       date and time of last modification
-          FlBkDat       ULong       date and time of last backup
-            These time numbers are original Mac FileTime values (local time!).
-            Currently, date-time width is 32-bit, but future version may
-            support be 64-bit times (see flags)
-
-          CrGMTOffs     Long(signed!)   difference "local Creat. time - UTC"
-          MdGMTOffs     Long(signed!)   difference "local Modif. time - UTC"
-          BkGMTOffs     Long(signed!)   difference "local Backup time - UTC"
-            These "local time - UTC" differences (stored in seconds) may be
-            used to support timestamp adjustment after inter-timezone transfer.
-            These fields are optional; bit 4 of the flags word controls their
-            presence.
-
-          Charset       Short       TextEncodingBase (Charset)
-                                    valid for the following two fields
-
-          FullPath      variable    Path of the current file.
-                                    Zero terminated string (C-String)
-                                    Currently coded in the native Charset.
-
-          Comment       variable    Finder Comment of the current file.
-                                    Zero terminated string (C-String)
-                                    Currently coded in the native Charset.
-
-
-         -SmartZIP Macintosh Extra Field:
-          ====================================
-
-          The following is the layout of the SmartZIP extra
-          block for Macintosh, designed by Marco Bambini.
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-          0x4d63        Short       tag for this extra block type ("cM")
-          TSize         Short       total data size for this block (64)
-          "dZip"        beLong      extra-field signature
-          fdType        Byte[4]     Type of the File (4-byte string)
-          fdCreator     Byte[4]     Creator of the File (4-byte string)
-          fdFlags       beShort     Finder Flags
-          fdLocation.v  beShort     Finder Icon Location
-          fdLocation.h  beShort     Finder Icon Location
-          fdFldr        beShort     Folder containing file
-          CrDat         beLong      HParamBlockRec fileParam.ioFlCrDat
-          MdDat         beLong      HParamBlockRec fileParam.ioFlMdDat
-          frScroll.v    Byte        vertical pos. of folder's scroll bar
-          fdScript      Byte        Script flag and number
-          frScroll.h    Byte        horizontal pos. of folder's scroll bar
-          fdXFlags      Byte        More flag bits
-          FileName      Byte[32]    full Macintosh filename (pascal string)
-
-          All fields but the first two are in native Macintosh format
-          (big-endian Motorola order, not little-endian Intel).
-          The extra field size is fixed to 64 bytes.
-          The local-header and central-header versions are identical.
-
-
-         -Acorn SparkFS Extra Field:
-          =========================
-
-          The following is the layout of David Pilling's SparkFS extra block
-          for Acorn RISC OS.  The local-header and central-header versions are
-          identical.  (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Acorn) 0x4341        Short       tag for this extra block type ("AC")
-          TSize         Short       total data size for this block (20)
-          "ARC0"        Long        extra-field signature
-          LoadAddr      Long        load address or file type
-          ExecAddr      Long        exec address
-          Attr          Long        file permissions
-          Zero          Long        reserved; always zero
-
-          The following bits of Attr are associated with the given file
-          permissions:
-
-                bit 0           user-writable ('W')
-                bit 1           user-readable ('R')
-                bit 2           reserved
-                bit 3           locked ('L')
-                bit 4           publicly writable ('w')
-                bit 5           publicly readable ('r')
-                bit 6           reserved
-                bit 7           reserved
-
-
-         -VM/CMS Extra Field:
-          ==================
-
-          The following is the layout of the file-attributes extra block for
-          VM/CMS.  The local-header and central-header versions are
-          identical.  (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
- (VM/CMS) 0x4704        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          flData        variable    file attributes data
-
-          flData is an uncompressed fldata_t struct.
-
-
-         -MVS Extra Field:
-          ===============
-
-          The following is the layout of the file-attributes extra block for
-          MVS.  The local-header and central-header versions are identical.
-          (Last Revision 19960922)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (MVS)   0x470f        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          flData        variable    file attributes data
-
-          flData is an uncompressed fldata_t struct.
-
-
-         -PKWARE Unix Extra Field:
-          ========================
-
-          The following is the layout of PKWARE's Unix "extra" block.
-          It was introduced with the release of PKZIP for Unix 2.50.
-          Note: all fields are stored in Intel low-byte/high-byte order.
-          (Last Revision 19980901)
-
-          This field has a minimum data size of 12 bytes and is only stored
-          as local extra field.
-
-          Value         Size        Description
-          -----         ----        -----------
- (Unix0)  0x000d        Short       Tag for this "extra" block type
-          TSize         Short       Total Data Size for this block
-          AcTime        Long        time of last access (UTC/GMT)
-          ModTime       Long        time of last modification (UTC/GMT)
-          UID           Short       Unix user ID
-          GID           Short       Unix group ID
-          (var)         variable    Variable length data field
-
-          The variable length data field will contain file type
-          specific data.  Currently the only values allowed are
-          the original "linked to" file names for hard or symbolic
-          links, and the major and minor device node numbers for
-          character and block device nodes.  Since device nodes
-          cannot be either symbolic or hard links, only one set of
-          variable length data is stored.  Link files will have the
-          name of the original file stored.  This name is NOT NULL
-          terminated.  Its size can be determined by checking TSize -
-          12.  Device entries will have eight bytes stored as two 4
-          byte entries (in little-endian format).  The first entry
-          will be the major device number, and the second the minor
-          device number.
-
-         [Info-ZIP note: The fixed part of this field has the same layout as
-          Info-ZIP's abandoned "Unix1 timestamps & owner ID info" extra field;
-          only the two tag bytes are different.]
-
-
-         -PATCH Descriptor Extra Field:
-          ============================
-
-          The following is the layout of the Patch Descriptor "extra"
-          block.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Patch) 0x000f        Short       Tag for this "extra" block type
-          TSize         Short       Size of the total "extra" block
-          Version       Short       Version of the descriptor
-          Flags         Long        Actions and reactions (see below)
-          OldSize       Long        Size of the file about to be patched
-          OldCRC        Long        32-bit CRC of the file about to be patched
-          NewSize       Long        Size of the resulting file
-          NewCRC        Long        32-bit CRC of the resulting file
-
-
-          Actions and reactions
-
-          Bits          Description
-          ----          ----------------
-          0             Use for autodetection
-          1             Treat as selfpatch
-          2-3           RESERVED
-          4-5           Action (see below)
-          6-7           RESERVED
-          8-9           Reaction (see below) to absent file
-          10-11         Reaction (see below) to newer file
-          12-13         Reaction (see below) to unknown file
-          14-15         RESERVED
-          16-31         RESERVED
-
-          Actions
-
-          Action       Value
-          ------       -----
-          none         0
-          add          1
-          delete       2
-          patch        3
-
-          Reactions
-
-          Reaction     Value
-          --------     -----
-          ask          0
-          skip         1
-          ignore       2
-          fail         3
-
-
-         -PKCS#7 Store for X.509 Certificates:
-          ===================================
-
-          This field is contains the information about each
-          certificate a file is signed with.  This field should only
-          appear in the first central directory record, and will be
-          ignored in any other record.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Store) 0x0014        2 bytes     Tag for this "extra" block type
-          SSize         2 bytes     Size of the store data
-          SData         (variable)  Data about the store
-
-          SData
-          Value         Size        Description
-          -----         ----        -----------
-          Version       2 bytes     Version number, 0x0001 for now
-          StoreD        (variable)  Actual store data
-
-          The StoreD member is suitable for passing as the pbData
-          member of a CRYPT_DATA_BLOB to the CertOpenStore() function
-          in Microsoft's CryptoAPI.  The SSize member above will be
-          cbData + 6, where cbData is the cbData member of the same
-          CRYPT_DATA_BLOB.  The encoding type to pass to
-          CertOpenStore() should be
-          PKCS_7_ANS_ENCODING | X509_ASN_ENCODING.
-
-
-         -X.509 Certificate ID and Signature for individual file:
-          ======================================================
-
-          This field contains the information about which certificate
-          in the PKCS#7 Store was used to sign the particular file.
-          It also contains the signature data.  This field can appear
-          multiple times, but can only appear once per certificate.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (CID)   0x0015        2 bytes     Tag for this "extra" block type
-          CSize         2 bytes     Size of Method
-          Method        (variable)
-
-          Method
-          Value         Size        Description
-          -----         ----        -----------
-          Version       2 bytes     Version number, for now 0x0001
-          AlgID         2 bytes     Algorithm ID used for signing
-          IDSize        2 bytes     Size of Certificate ID data
-          CertID        (variable)  Certificate ID data
-          SigSize       2 bytes     Size of Signature data
-          Sig           (variable)  Signature data
-
-          CertID
-          Value         Size        Description
-          -----         ----        -----------
-          Size1         4 bytes     Size of CertID, should be (IDSize - 4)
-          Size1         4 bytes     A bug in version one causes this value
-                                    to appear twice.
-          IssSize       4 bytes     Issuer data size
-          Issuer        (variable)  Issuer data
-          SerSize       4 bytes     Serial Number size
-          Serial        (variable)  Serial Number data
-
-          The Issuer and IssSize members are suitable for creating a
-          CRYPT_DATA_BLOB to be the Issuer member of a CERT_INFO
-          struct. The Serial and SerSize members would be the
-          SerialNumber member of the same CERT_INFO struct.  This
-          struct would be used to find the certificate in the store
-          the file was signed with.  Those structures are from the MS
-          CryptoAPI.
-
-          Sig and SigSize are the actual signature data and size
-          generated by signing the file with the MS CryptoAPI using a
-          hash created with the given AlgID.
-
-
-         -X.509 Certificate ID and Signature for central directory:
-          ========================================================
-
-          This field contains the information about which certificate
-          in the PKCS#7 Store was used to sign the central directory.
-          It should only appear with the first central directory
-          record, along with the store.  The data structure is the
-          same as the CID, except that SigSize will be 0, and there
-          will be no Sig member.
-
-          This field is also kept after the last central directory
-          record, as the signature data (ID 0x05054b50, it looks like
-          a central directory record of a different type).  This
-          second copy of the data is the Signature Data member of the
-          record, and will have a SigSize that is non-zero, and will
-          have Sig data.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value         Size        Description
-          -----         ----        -----------
-  (CDID)  0x0016        2 bytes     Tag for this "extra" block type
-          CSize         2 bytes     Size of Method
-          Method       (variable)
-
-
-         -ZIP64 Extended Information Extra Field:
-          ======================================
-
-          The following is the layout of the ZIP64 extended
-          information "extra" block. If one of the size or
-          offset fields in the Local or Central directory
-          record is too small to hold the required data,
-          a ZIP64 extended information record is created.
-          The order of the fields in the ZIP64 extended
-          information record is fixed, but the fields will
-          only appear if the corresponding Local or Central
-          directory record field is set to 0xFFFF or 0xFFFFFFFF.
-
-          Note: all fields stored in Intel low-byte/high-byte order.
-
-          Value      Size       Description
-          -----      ----       -----------
-  (ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
-          Size       2 bytes    Size of this "extra" block
-          Original
-          Size       8 bytes    Original uncompresseed file size
-          Compressed
-          Size       8 bytes    Size of compressed data
-          Relative Header
-          Offset     8 bytes    Offset of local header record
-          Disk Start
-          Number     4 bytes    Number of the disk on which
-                                this file starts
-
-          This entry in the Local header must include BOTH original
-          and compressed file sizes.
-
-
-         -Extended Timestamp Extra Field:
-          ==============================
-
-          The following is the layout of the extended-timestamp extra block.
-          (Last Revision 19970118)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (time)  0x5455        Short       tag for this extra block type ("UT")
-          TSize         Short       total data size for this block
-          Flags         Byte        info bits
-          (ModTime)     Long        time of last modification (UTC/GMT)
-          (AcTime)      Long        time of last access (UTC/GMT)
-          (CrTime)      Long        time of original creation (UTC/GMT)
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (time)  0x5455        Short       tag for this extra block type ("UT")
-          TSize         Short       total data size for this block
-          Flags         Byte        info bits (refers to local header!)
-          (ModTime)     Long        time of last modification (UTC/GMT)
-
-          The central-header extra field contains the modification time only,
-          or no timestamp at all.  TSize is used to flag its presence or
-          absence.  But note:
-
-              If "Flags" indicates that Modtime is present in the local header
-              field, it MUST be present in the central header field, too!
-              This correspondence is required because the modification time
-              value may be used to support trans-timezone freshening and
-              updating operations with zip archives.
-
-          The time values are in standard Unix signed-long format, indicating
-          the number of seconds since 1 January 1970 00:00:00.  The times
-          are relative to Coordinated Universal Time (UTC), also sometimes
-          referred to as Greenwich Mean Time (GMT).  To convert to local time,
-          the software must know the local timezone offset from UTC/GMT.
-
-          The lower three bits of Flags in both headers indicate which time-
-          stamps are present in the LOCAL extra field:
-
-                bit 0           if set, modification time is present
-                bit 1           if set, access time is present
-                bit 2           if set, creation time is present
-                bits 3-7        reserved for additional timestamps; not set
-
-          Those times that are present will appear in the order indicated, but
-          any combination of times may be omitted.  (Creation time may be
-          present without access time, for example.)  TSize should equal
-          (1 + 4*(number of set bits in Flags)), as the block is currently
-          defined.  Other timestamps may be added in the future.
-
-
-         -Info-ZIP Unix Extra Field (type 1):
-          ==================================
-
-          The following is the layout of the old Info-ZIP extra block for
-          Unix.  It has been replaced by the extended-timestamp extra block
-          (0x5455) and the Unix type 2 extra block (0x7855).
-          (Last Revision 19970118)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix1) 0x5855        Short       tag for this extra block type ("UX")
-          TSize         Short       total data size for this block
-          AcTime        Long        time of last access (UTC/GMT)
-          ModTime       Long        time of last modification (UTC/GMT)
-          UID           Short       Unix user ID (optional)
-          GID           Short       Unix group ID (optional)
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix1) 0x5855        Short       tag for this extra block type ("UX")
-          TSize         Short       total data size for this block
-          AcTime        Long        time of last access (GMT/UTC)
-          ModTime       Long        time of last modification (GMT/UTC)
-
-          The file access and modification times are in standard Unix signed-
-          long format, indicating the number of seconds since 1 January 1970
-          00:00:00.  The times are relative to Coordinated Universal Time
-          (UTC), also sometimes referred to as Greenwich Mean Time (GMT).  To
-          convert to local time, the software must know the local timezone
-          offset from UTC/GMT.  The modification time may be used by non-Unix
-          systems to support inter-timezone freshening and updating of zip
-          archives.
-
-          The local-header extra block may optionally contain UID and GID
-          info for the file.  The local-header TSize value is the only
-          indication of this.  Note that Unix UIDs and GIDs are usually
-          specific to a particular machine, and they generally require root
-          access to restore.
-
-          This extra field type is obsolete, but it has been in use since
-          mid-1994.  Therefore future archiving software should continue to
-          support it.  Some guidelines:
-
-              An archive member should either contain the old "Unix1"
-              extra field block or the new extra field types "time" and/or
-              "Unix2".
-
-              If both the old "Unix1" block type and one or both of the new
-              block types "time" and "Unix2" are found, the "Unix1" block
-              should be considered invalid and ignored.
-
-              Unarchiving software should recognize both old and new extra
-              field block types, but the info from new types overrides the
-              old "Unix1" field.
-
-              Archiving software should recognize "Unix1" extra fields for
-              timestamp comparison but never create it for updated, freshened
-              or new archive members.  When copying existing members to a new
-              archive, any "Unix1" extra field blocks should be converted to
-              the new "time" and/or "Unix2" types.
-
-
-         -Info-ZIP Unix Extra Field (type 2):
-          ==================================
-
-          The following is the layout of the new Info-ZIP extra block for
-          Unix.  (Last Revision 19960922)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix2) 0x7855        Short       tag for this extra block type ("Ux")
-          TSize         Short       total data size for this block (4)
-          UID           Short       Unix user ID
-          GID           Short       Unix group ID
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix2) 0x7855        Short       tag for this extra block type ("Ux")
-          TSize         Short       total data size for this block (0)
-
-          The data size of the central-header version is zero; it is used
-          solely as a flag that UID/GID info is present in the local-header
-          extra field.  If additional fields are ever added to the local
-          version, the central version may be extended to indicate this.
-
-          Note that Unix UIDs and GIDs are usually specific to a particular
-          machine, and they generally require root access to restore.
-
-
-         -ASi Unix Extra Field:
-          ====================
-
-          The following is the layout of the ASi extra block for Unix.  The
-          local-header and central-header versions are identical.
-          (Last Revision 19960916)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Unix3) 0x756e        Short       tag for this extra block type ("nu")
-          TSize         Short       total data size for this block
-          CRC           Long        CRC-32 of the remaining data
-          Mode          Short       file permissions
-          SizDev        Long        symlink'd size OR major/minor dev num
-          UID           Short       user ID
-          GID           Short       group ID
-          (var.)        variable    symbolic link filename
-
-          Mode is the standard Unix st_mode field from struct stat, containing
-          user/group/other permissions, setuid/setgid and symlink info, etc.
-
-          If Mode indicates that this file is a symbolic link, SizDev is the
-          size of the file to which the link points.  Otherwise, if the file
-          is a device, SizDev contains the standard Unix st_rdev field from
-          struct stat (includes the major and minor numbers of the device).
-          SizDev is undefined in other cases.
-
-          If Mode indicates that the file is a symbolic link, the final field
-          will be the name of the file to which the link points.  The file-
-          name length can be inferred from TSize.
-
-          [Note that TSize may incorrectly refer to the data size not counting
-           the CRC; i.e., it may be four bytes too small.]
-
-
-         -BeOS Extra Field:
-          ================
-
-          The following is the layout of the file-attributes extra block for
-          BeOS.  (Last Revision 19970531)
-
-          Local-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (BeOS)  0x6542        Short       tag for this extra block type ("Be")
-          TSize         Short       total data size for this block
-          BSize         Long        uncompressed file attribute data size
-          Flags         Byte        info bits
-          (CType)       Short       compression type
-          (CRC)         Long        CRC value for uncompressed file attribs
-          Attribs       variable    file attribute data
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (BeOS)  0x6542        Short       tag for this extra block type ("Be")
-          TSize         Short       total data size for this block (5)
-          BSize         Long        size of uncompr. local EF block data
-          Flags         Byte        info bits
-
-          The least significant bit of Flags in both headers indicates whether
-          the LOCAL extra field is uncompressed (and therefore whether CType
-          and CRC are omitted):
-
-                bit 0           if set, Attribs is uncompressed (no CType, CRC)
-                bits 1-7        reserved; if set, assume error or unknown data
-
-          Currently the only supported compression types are deflated (type 8)
-          and stored (type 0); the latter is not used by Info-ZIP's Zip but is
-          supported by UnZip.
-
-          Attribs is a BeOS-specific block of data in big-endian format with
-          the following structure (if compressed, uncompress it first):
-
-              Value     Size        Description
-              -----     ----        -----------
-              Name      variable    attribute name (null-terminated string)
-              Type      Long        attribute type (32-bit unsigned integer)
-              Size      Long Long   data size for this sub-block (64 bits)
-              Data      variable    attribute data
-
-          The attribute structure is repeated for every attribute.  The Data
-          field may contain anything--text, flags, bitmaps, etc.
-
-
-         -SMS/QDOS Extra Field:
-          ====================
-
-          The following is the layout of the file-attributes extra block for
-          SMS/QDOS.  The local-header and central-header versions are identical.
-          (Last Revision 19960929)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (QDOS)  0xfb4a        Short       tag for this extra block type
-          TSize         Short       total data size for this block
-          LongID        Long        extra-field signature
-          (ExtraID)     Long        additional signature/flag bytes
-          QDirect       64 bytes    qdirect structure
-
-          LongID may be "QZHD" or "QDOS".  In the latter case, ExtraID will
-          be present.  Its first three bytes are "02\0"; the last byte is
-          currently undefined.
-
-          QDirect contains the file's uncompressed directory info (qdirect
-          struct).  Its elements are in native (big-endian) format:
-
-          d_length      beLong          file length
-          d_access      byte            file access type
-          d_type        byte            file type
-          d_datalen     beLong          data length
-          d_reserved    beLong          unused
-          d_szname      beShort         size of filename
-          d_name        36 bytes        filename
-          d_update      beLong          time of last update
-          d_refdate     beLong          file version number
-          d_backup      beLong          time of last backup (archive date)
-
-
-         -AOS/VS Extra Field:
-          ==================
-
-          The following is the layout of the extra block for Data General
-          AOS/VS.  The local-header and central-header versions are identical.
-          (Last Revision 19961125)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (AOSVS) 0x5356        Short       tag for this extra block type ("VS")
-          TSize         Short       total data size for this block
-          "FCI\0"       Long        extra-field signature
-          Version       Byte        version of AOS/VS extra block (10 = 1.0)
-          Fstat         variable    fstat packet
-          AclBuf        variable    raw ACL data ($MXACL bytes)
-
-          Fstat contains the file's uncompressed fstat packet, which is one of
-          the following:
-
-                normal fstat packet             (P_FSTAT struct)
-                DIR/CPD fstat packet            (P_FSTAT_DIR struct)
-                unit (device) fstat packet      (P_FSTAT_UNIT struct)
-                IPC file fstat packet           (P_FSTAT_IPC struct)
-
-          AclBuf contains the raw ACL data; its length is $MXACL.
-
-
-         -Tandem NSK Extra Field:
-          ======================
-
-          The following is the layout of the file-attributes extra block for
-          Tandem NSK.  The local-header and central-header versions are
-          identical.  (Last Revision 19981221)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (TA)    0x4154        Short       tag for this extra block type ("TA")
-          TSize         Short       total data size for this block (20)
-          NSKattrs      20 Bytes    NSK attributes
-
-
-         -THEOS Extra Field:
-          =================
-
-          The following is the layout of the file-attributes extra block for
-          Theos.  The local-header and central-header versions are identical.
-          (Last Revision 19990206)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (Theos) 0x6854        Short       'Th' signature
-          size          Short       size of extra block
-          flags         Byte        reserved for future use
-          filesize      Long        file size
-          fileorg       Byte        type of file (see below)
-          keylen        Short       key length for indexed and keyed files,
-                                    data segment size for 16 bits programs
-          reclen        Short       record length for indexed,keyed and direct,
-                                    text segment size for 16 bits programs
-          filegrow      Byte        growing factor for indexed,keyed and direct
-          protect       Byte        protections (see below)
-          reserved      Short       reserved for future use
-
-            File types
-            ==========
-
-            0x80  library (keyed access list of files)
-            0x40  directory
-            0x10  stream file
-            0x08  direct file
-            0x04  keyed file
-            0x02  indexed file
-            0x0e  reserved
-            0x01  16 bits real mode program (obsolete)
-            0x21  16 bits protected mode program
-            0x41  32 bits protected mode program
-
-            Protection codes
-            ================
-
-            User protection
-            ---------------
-            0x01  non readable
-            0x02  non writable
-            0x04  non executable
-            0x08  non erasable
-
-            Other protection
-            ----------------
-            0x10  non readable
-            0x20  non writable
-            0x40  non executable Theos before 4.0
-            0x40  modified Theos 4.x
-            0x80  not hidden
-
-
-         -THEOS old inofficial Extra Field:
-          ================================
-
-          The following is the layout of an inoffical former version of a
-          Theos file-attributes extra blocks.  This layout was never published
-          and is no longer created. However, UnZip can optionally support it
-          when compiling with the option flag OLD_THEOS_EXTRA defined.
-          Both the local-header and central-header versions are identical.
-          (Last Revision 19990206)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (THS0)  0x4854        Short       'TH' signature
-          size          Short       size of extra block
-          flags         Short       reserved for future use
-          filesize      Long        file size
-          reclen        Short       record length for indexed,keyed and direct,
-                                    text segment size for 16 bits programs
-          keylen        Short       key length for indexed and keyed files,
-                                    data segment size for 16 bits programs
-          filegrow      Byte        growing factor for indexed,keyed and direct
-          reserved      3 Bytes     reserved for future use
-
-
-         -FWKCS MD5 Extra Field:
-          =====================
-
-          The FWKCS Contents_Signature System, used in automatically
-          identifying files independent of filename, optionally adds
-          and uses an extra field to support the rapid creation of
-          an enhanced contents_signature.
-          There is no local-header version; the following applies
-          only to the central header.  (Last Revision 19961207)
-
-          Central-header version:
-
-          Value         Size        Description
-          -----         ----        -----------
-  (MD5)   0x4b46        Short       tag for this extra block type ("FK")
-          TSize         Short       total data size for this block (19)
-          "MD5"         3 bytes     extra-field signature
-          MD5hash       16 bytes    128-bit MD5 hash of uncompressed data
-                                    (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."
-
-
-         -Info-ZIP Unicode Path Extra Field:
-          =================================
-
-          Stores the UTF-8 version of the entry path as stored in the
-          local header and central directory header.
-          (Last Revision 20070912)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (UPath) 0x7075        Short       tag for this extra block type ("up")
-          TSize         Short       total data size for this block
-          Version       1 byte      version of this extra field, currently 1
-          NameCRC32     4 bytes     File Name Field CRC32 Checksum
-          UnicodeName   Variable    UTF-8 version of the entry File Name
-
-          Currently Version is set to the number 1.  If there is a need
-          to change this field, the version will be incremented.  Changes
-          may not be backward compatible so this extra field should not be
-          used if the version is not recognized.
-
-          The NameCRC32 is the standard zip CRC32 checksum of the File Name
-          field in the header.  This is used to verify that the header
-          File Name field has not changed since the Unicode Path extra field
-          was created.  This can happen if a utility renames the entry but
-          does not update the UTF-8 path extra field.  If the CRC check fails,
-          this UTF-8 Path Extra Field should be ignored and the File Name field
-          in the header used instead.
-
-          The UnicodeName is the UTF-8 version of the contents of the File Name
-          field in the header.  As UnicodeName is defined to be UTF-8, no UTF-8
-          byte order mark (BOM) is used.  The length of this field is determined
-          by subtracting the size of the previous fields from TSize.  If both
-          the File Name and Comment fields are UTF-8, the new General Purpose
-          Bit Flag, bit 11 (Language encoding flag (EFS)), can be used to
-          indicate that both the header File Name and Comment fields are UTF-8
-          and, in this case, the Unicode Path and Unicode Comment extra fields
-          are not needed and should not be created.  Note that, for backward
-          compatibility, bit 11 should only be used if the native character set
-          of the paths and comments being zipped up are already in UTF-8.  The
-          same method, either bit 11 or extra fields, should be used in both
-          the local and central directory headers.
-
-
-         -Info-ZIP Unicode Comment Extra Field:
-          ====================================
-
-          Stores the UTF-8 version of the entry comment as stored in the
-          central directory header.
-          (Last Revision 20070912)
-
-          Value         Size        Description
-          -----         ----        -----------
-   (UCom) 0x6375        Short       tag for this extra block type ("uc")
-          TSize         Short       total data size for this block
-          Version       1 byte      version of this extra field, currently 1
-          ComCRC32      4 bytes     Comment Field CRC32 Checksum
-          UnicodeCom    Variable    UTF-8 version of the entry comment
-
-          Currently Version is set to the number 1.  If there is a need
-          to change this field, the version will be incremented.  Changes
-          may not be backward compatible so this extra field should not be
-          used if the version is not recognized.
-
-          The ComCRC32 is the standard zip CRC32 checksum of the Comment
-          field in the central directory header.  This is used to verify that
-          the comment field has not changed since the Unicode Comment extra field
-          was created.  This can happen if a utility changes the Comment field
-          but does not update the UTF-8 Comment extra field.  If the CRC check
-          fails, this Unicode Comment extra field should be ignored and the
-          Comment field in the header used.
-
-          The UnicodeCom field is the UTF-8 version of the entry comment field
-          in the header.  As UnicodeCom is defined to be UTF-8, no UTF-8 byte
-          order mark (BOM) is used.  The length of this field is determined by
-          subtracting the size of the previous fields from TSize.  If both the
-          File Name and Comment fields are UTF-8, the new General Purpose Bit
-          Flag, bit 11 (Language encoding flag (EFS)), can be used to indicate
-          both the header File Name and Comment fields are UTF-8 and, in this
-          case, the Unicode Path and Unicode Comment extra fields are not
-          needed and should not be created.  Note that, for backward
-          compatibility, bit 11 should only be used if the native character set
-          of the paths and comments being zipped up are already in UTF-8.  The
-          same method, either bit 11 or extra fields, should be used in both
-          the local and central directory headers.
-
-
-         -Info-ZIP New Unix Extra Field:
-          ====================================
-
-          Currently stores Unix UIDs/GIDs up to 32 bits.
-          (Last Revision 20080509)
-
-          Value         Size        Description
-          -----         ----        -----------
-  (UnixN) 0x7875        Short       tag for this extra block type ("ux")
-          TSize         Short       total data size for this block
-          Version       1 byte      version of this extra field, currently 1
-          UIDSize       1 byte      Size of UID field
-          UID           Variable    UID for this entry
-          GIDSize       1 byte      Size of GID field
-          GID           Variable    GID for this entry
-
-          Currently Version is set to the number 1.  If there is a need
-          to change this field, the version will be incremented.  Changes
-          may not be backward compatible so this extra field should not be
-          used if the version is not recognized.
-
-          UIDSize is the size of the UID field in bytes.  This size should
-          match the size of the UID field on the target OS.
-
-          UID is the UID for this entry in standard little endian format.
-
-          GIDSize is the size of the GID field in bytes.  This size should
-          match the size of the GID field on the target OS.
-
-          GID is the GID for this entry in standard little endian format.
-
-          If both the old 16-bit Unix extra field (tag 0x7855, Info-ZIP Unix)
-          and this extra field are present, the values in this extra field
-          supercede the values in that extra field.