readme.cms

完整的解压zip文件的源码。包含密码功能

       and the last two period-separated words are used as the
       filename and filetype.  These are truncated to a maximum of
       eight characters, if necessary.  If the filetype (extension)
       is missing, then UNZIP uses "NONAME" for the filetype.
       Any '(' or ')' characters are removed from the fileid.

    c. All files are created in upper-case.  Files in mixed-case
       cannot currently be stored into a ZIP file.

    d. Shared File System (SFS) directories are not supported.
       Files are always accessed by fn.ft.fm.  To use an SFS disk,
       Assign it a filemode, then it can be used.


 3. Wildcards in file names

    a. Wildcards are not supported in the zip filename.  The full
       filename of the zip file must be given (but the .zip is not
       necessary).  So, you can't do this:
          unzip -t *.zip

    b. Wildcards CAN be used with UNZIP to select (or exclude) files
       inside a zip file.  Examples:
          unzip myzip *.c          - Unzip all .c files.
          unzip myzip *.c -x z*.c  - Unzip all .c files but those
                                     starting with Z.

    c. Wildcards cannot currently be used to select files with ZIP.
       So, you can't do this:
          zip -a myzip *.exec

       I expect to fix this for CMS in the future.


 4. File timestamps

    a. The dates and times of files being zipped or unzipped are not
       currently read or set.  When a file is zipped, the timestamp
       inside the zip file will always be the current system date and
       time.  Likewise, when unzipping, the date and time of files
       being unzipped will always be the current system date/time.

    b. Existing files are assumed to be newer than files inside a zip
       file when using the -f freshen option of UNZIP.  This will prevent
       overwriting files that may be newer than the files inside the
       zip file, but also effectively prevents the -f option from working.


 5. ASCII, EBCDIC, and binary data

    Background
    ----------
    Most systems create data files as just a stream of bytes.  Record
    breaks happen when certain characters (new line and/or carriage
    return characters) are encountered in the data.  How to interpret
    the data in a file is up to the user.  The system must be told
    to either notice new line characters in the data or to assume
    that the data in the file is binary data and should be read or
    written as-is.

    CMS and MVS are record-based systems.  All files are composed
    of data records.  These can be stored in fixed-length files or
    in variable length files.  With fixed-length files, each record
    is the same length.  The record breaks are implied by the
    LRECL (logical record length) attribute associated with the file.
    With variable-length files, each record contains the length of
    that record.  The separation of records are not part of the
    data, but part of the file structure.

    This means you can store any type of data in either type of file
    structure without having to worry about the data being interpreted
    as a record break.  Fixed-length files may have padding at the
    end of the file to make up a full record.  Variable-length files
    have no padding, but require extra record length data be stored
    with the file data.

    Storing fixed-length files into a zip file is simple, because all
    the data can just be dumped into the zip file and the record
    format (RECFM) and logical record length (LRECL) can be stored
    in the extra data area of the zip file so they can be restored
    when UNZIP is used.

    Storing variable-length data is harder.  There is no place to put
    the record length data needed for each record of the file.  This
    data could be written to the zip file as the first two bytes of
    each record and interpreted that way by UNZIP.  That would make
    the data unusable on systems other than CMS and MVS, though.

    Currently, there isn't a solution to this problem.  Each record is
    written to the zip file and the record length information is
    discarded.  Binary data stored in variable-length files can't be put
    into a zip file then later unzipped back into the proper records.
    This is fine for binary data that will be read as a stream of bytes
    but not OK where the records matter, such as with CMS MODULEs.

    If the data is text (character data), there is a solution.
    This data can be converted into ASCII when it's stored into
    a zip file.  The end of each record is now marked in the file
    by new line characters.  Another advantage of this method is
    that the data is now accessible to non-EBCDIC systems.  When
    the data is unzipped on CMS or MVS, it is converted back into
    EBCDIC and the records are recreated into a variable-length file.


    So, here's what we have...

    a. To store readable text data into a zip file that can be used
       on other platforms, use the -a option with ZIP to convert the
       data to ASCII.  These files will unzip into variable-length
       files on CMS and should not contain binary data or corruption
       may occur.

    b. Files that were zipped on an ASCII-based system will be
       automatically translated to EBCDIC when unzipped.  To prevent
       this (to unzip binary data on CMS that was sent from an
       ASCII-based system), use the -B option with UNZIP to force Binary
       mode.  To zip binary files on CMS, use the -B option with ZIP to
       force Binary mode.  This will prevent any data conversions from
       taking place.

    c. When using the ZIP program without specifying the "-a" or "-B"
       option, ZIP defaults to "native" (EBCDIC) mode and tries to
       preserve the file information (RECFM, LRECL, and BLKSIZE).  So
       when you unzip a file zipped with ZIP under CMS or MVS, UNZIP
       restores the file info.  The output will be fixed-length if the
       original was fixed and variable-length if the original was
       variable.

    If UNZIP gives a "write error (disk full?)"  message, you may be
    trying to unzip a binary file that was zipped as a text file
    (without using the -B option)


    Summary
    -------
    Here's how to ZIP the different types of files.

    RECFM F text
       Use the -a option with ZIP to convert to ASCII for use with other
       platforms or no options for use on EBCDIC systems only.

    RECFM V text
       Use the -a option with ZIP to convert to ASCII for use with other
       platforms or no options for use on EBCDIC systems only.


    RECFM F binary
       Use the -B option with ZIP (upper-case "B").

    RECFM V binary
       Use the -B option with ZIP.  Can be zipped OK but the record
       structure is destroyed when unzipped.  This is OK for data files
       read as binary streams but not OK for files such as CMS MODULEs.


 6. Character Sets

    If you are used to running UNZIP on systems like UNIX, DOS, OS/2 or
    Windows, you will may have some problems with differences in the
    character set.

    There are a number of different EBCDIC code pages, like there are a
    number of different ASCII code pages.  For example, there is a US
    EBCDIC, a German EBCDIC, and a Swedish EBCDIC.  As long as you are
    working with other people who use the same EBCDIC code page, you
    will have no trouble.  If you work with people who use ASCII, or who
    use a different EBCDIC code page, you may need to do some
    translation.

    UNZIP translates ASCII text files to and from Open Systems EBCDIC
    (IBM-1047), which may not be the EBCDIC that you are using.  For
    example, US EBCDIC (IBM-037) uses different character codes for
    square brackets.  In such cases, you can use the ICONV utility
    (supplied with IBM C) to translate between your EBCDIC character set
    and IBM-1047.

    If your installation does not use IBM-1047 EBCDIC, messages from
    UNZIP may look a little odd.  For example, in a US EBCDIC
    installation, an opening square bracket will become an i-acute and a
    closing square bracket will become a u-grave.

    The supplied ZIP and UNZIP EXECs attempt to correct this by setting
    CMS INPUT and OUTPUT translations to adjust the display of left and
    right brackets.  You may need to change this if brackets don't
    display correctly on your system.


 7. You can unzip using VM/CMS PIPELINES so unzip can be used as
    a pipeline filter.  Example:
       'PIPE COMMAND UNZIP -p test.zip george.test | Count Lines | Cons'




Please report all bugs and problems to:
   [e-mail]


-----------------------------------------------------------------------
Original CMS/MVS port by George Petrov.
e-mail:  [e-mail]
tel:     [phone]

Philips C&P
Eindhoven
The Netherlands

-----------------------------------------------------------------------
Additional fixes and README re-write (4/98) by Greg Hartwig.
e-mail:  [e-mail]
         [e-mail]

-----------------------------------------------------------------------
Additional notes from Ian E. Gorman.
e-mail:  [e-mail]