extracted   files   to   be   set  correctly.   The  WIN32
       (Win9x/ME/NT4/2K/XP/2K3) port of unzip gets the  timezone  configuration
       from  the  registry,  assuming it is correctly set in the Control Panel.
       The TZ variable is ignored for this port.

DECRYPTION
       Encrypted archives are fully supported by Info‐ZIP software, but due  to
       United  States export restrictions, de‐/encryption support might be dis‐
       abled in your compiled binary.  However, since spring  2000,  US  export
       restrictions have been liberated, and our source archives do now include
       full  crypt code.  In case you need binary distributions with crypt sup‐
       port enabled, see the file ‘‘WHERE’’ in any Info‐ZIP  source  or  binary
       distribution for locations both inside and outside the US.

       Some  compiled versions of unzip may not support decryption.  To check a
       version for crypt support, either attempt to  test  or  extract  an  en‐
       crypted archive, or else check unzip’s diagnostic screen (see the -v op‐
       tion  above)  for ‘‘[decryption]’’ as one of the special compilation op‐
       tions.

       As noted above, the -P option may be used to supply a  password  on  the
       command  line,  but  at  a  cost  in security.  The preferred decryption
       method is simply to extract normally; if a zipfile member is  encrypted,
       unzip will prompt for the password without echoing what is typed.  unzip
       continues to use the same password as long as it appears to be valid, by
       testing a 12‐byte header on each file.  The correct password will always
       check out against the header, but there is a 1‐in‐256 chance that an in‐
       correct  password  will  as  well.   (This  is a security feature of the
       PKWARE zipfile format; it helps prevent brute‐force attacks  that  might
       otherwise  gain a large speed advantage by testing only the header.)  In
       the case that an incorrect password is given but it  passes  the  header
       test anyway, either an incorrect CRC will be generated for the extracted
       data  or  else  unzip  will fail during the extraction because the ‘‘de‐
       crypted’’ bytes do not constitute a valid compressed data stream.

       If the first password fails the header check on some  file,  unzip  will
       prompt  for  another  password, and so on until all files are extracted.
       If a password is not known, entering a null password (that  is,  just  a
       carriage  return  or ‘‘Enter’’) is taken as a signal to skip all further
       prompting.  Only unencrypted files in the archive(s) will thereafter  be
       extracted.   (In  fact,  that’s not quite true; older versions of zip(1)
       and zipcloak(1) allowed null passwords, so unzip checks  each  encrypted
       file to see if the null password works.  This may result in ‘‘false pos‐
       itives’’ and extraction errors, as noted above.)

       Archives encrypted with 8‐bit passwords (for example, passwords with ac‐
       cented  European  characters)  may not be portable across systems and/or
       other archivers.  This problem stems from the use of  multiple  encoding
       methods for such characters, including Latin‐1 (ISO 8859‐1) and OEM code
       page  850.   DOS  PKZIP 2.04g uses the OEM code page; Windows PKZIP 2.50
       uses Latin‐1 (and is therefore incompatible with  DOS  PKZIP);  Info‐ZIP
       uses  the  OEM  code  page  on DOS, OS/2 and Win3.x ports but ISO coding
       (Latin‐1 etc.) everywhere else; and Nico Mak’s WinZip 6.x does not allow
       8‐bit passwords at all.  UnZip 5.3 (or newer) attempts to  use  the  de‐
       fault character set first (e.g., Latin‐1), followed by the alternate one
       (e.g.,  OEM code page) to test passwords.  On EBCDIC systems, if both of
       these fail, EBCDIC encoding will be tested as a last resort.  (EBCDIC is
       not tested on non‐EBCDIC systems, because there are no  known