压缩解压

开发平台：
MultiPlatform

3rdparty.bug：源码内容
							Known, current PKZIP bugs/limitations:
-------------------------------------
 - PKUNZIP 2.04g is reported to corrupt some files when compressing them with
   the -ex option; when tested, the files fail the CRC check, and comparison
   with the original file shows bogus data (6K in one case) embedded in the
   middle.  PKWARE apparently characterized this as a "known problem."
 - PKUNZIP 2.04g considers volume labels valid only if originated on a FAT
   file system, but other OSes and file systems (e.g., Amiga and OS/2 HPFS)
   support volume labels, too.
 - PKUNZIP 2.04g can restore volume labels created by Zip 2.x but not by
   PKZIP 2.04g (OS/2 DOS box only??).
 - PKUNZIP 2.04g gives an error message for stored directory entries created
   under other OSes (although it creates the directory anyway), and PKZIP -vt
   does not report the directory attribute bit as being set, even if it is.
 - PKZIP 2.04g mangles unknown extra fields (especially OS/2 extended attri-
   butes) when adding new files to an existing zipfile [example:  Walnut Creek
   Hobbes March 1995 CD-ROM, FILE_ID.DIZ additions].
 - PKUNZIP 2.04g is unable to detect or deal with prepended junk in a zipfile,
   reporting CRC errors in valid compressed data.
 - PKUNZIP 2.04g (registered version) incorrectly updates/freshens the AV extra
   field in authenticated archives.  The resultant extra block length and total
   extra field length are inconsistent.
 - [Windows version 2.01] Win95 long filenames (VFAT) are stored OK, but the
   file system is always listed as ordinary DOS FAT.
 - [Windows version 2.50] NT long filenames (NTFS) are stored OK, but the
   file system is always listed as ordinary DOS FAT.
 - PKZIP 2.04 for DOS encrypts using the OEM code page for 8-bit passwords,
   while PKZIP 2.50 for Windows uses Latin-1 (ISO 8859-1).  This means an
   archive encrypted with an 8-bit password with one of the two PKZIP versions
   cannot be decrypted with the other version.
 - PKZIP for Windows GUI (v 2.60), PKZIP for Windows command line (v 2.50) and
   PKZIP for Unix (v 2.51) save the host's native file timestamps, but
   only in a local extra field. Thus, timestamp-related selections (update
   or freshen, both in extraction or archiving operations) use the DOS-format
   localtime records in the Zip archives for comparisons. This may result
   in wrong decisions of the program when updating and first archiv creations
   are carried out in different local time zones.
 - PKUNZIP 2.04g is reported to have problems with archives created on and/or
   copied from Iomega ZIP drives (irony, eh?).
Known, current WinZip bugs/limitations:
--------------------------------------
 - [16-bit version 6.1a] NT short filenames (FAT) are stored OK, but the
   file system is always listed as NTFS.
 - WinZip doesn't allow 8-bit passwords, which means it cannot decrypt an
   archive created with an 8-bit password (by PKZIP or Info-ZIP's Zip).
 - WinZip (Version 6.3 PL1) fails to remove old extra fields when freshening
   existing archive entries. When updating archives created by Info-ZIP's Zip
   that contain UT time stamp extra field blocks, UnZip cannot display or
   restore the updated (DOS) time stamps of the freshened archive members.
Known, current other third-party Zip utils bugs/limitations:
------------------------------------------------------------
 - Asi's PKZip clones for Macintosh (versions 2.3 and 2.10d) are thoroughly
   broken. They create invalid Zip archives!
   a) For the first entry, both compressed size and uncompressed length
      are recorded as 0, despite the fact that compressed data of non-zero
      length has been added.
   b) Their program creates extra fields with an (undocumented) internal
      structure that violates the requirements of PKWARE's Zip format
      specification document "appnote.txt": Their extra field seems to
      contain pure data; the 4-byte block header consisting of block ID
      and data length is missing.
Possibly current PKZIP bugs:
---------------------------
 - PKZIP (2.04g?) can silently ignore read errors on network drives, storing
   the correct CRC and compressed length but an incorrect and inconsistent
   uncompressed length.
 - PKZIP (2.04g?), when deleting files from within a zipfile on a Novell
   drive, sometimes only zeros out the data while failing to shrink the
   zipfile.
Other limitations:
-----------------
 - PKZIP 1.x and 2.x encryption has been cracked (known-plaintext approach;
   see http://www.cryptography.com/ for details).
[many other bugs in PKZIP 1.0, 1.1, 1.93a, 2.04c and 2.04e]

						