view release on metacpan or  search on metacpan

unzip-6.0/macos/README.TXT  view on Meta::CPAN

   - Extraction of ZipIt archives is supported. This support
     is not complete: Filenames are correct but Directory names
     are sometimes mangled to a DOS compatible form. Segmented
     archives are not supported.
   - PKZiP/mac archive files are extracted without resource-forks
     and without any Finder info. I have no information about
     that zip format.

Compatibility of my port; Compression:
   - My port supports only the new Info-ZIP format (introduced
     with this port). Therefore archives created by MacZip 1.0
     (March 1999) must be extracted with this version or later
     releases of Info-ZIP's UnZip to restore the complete set of
     Macintosh attributes.

Note: This port is complete unrelated to the shareware ZipIt.
Even more, handling of special Macintosh attributes is
incompatible with ZipIt. This port (MacZip) may be used to
extract archives created by ZipIt, but make sure that you
get the result as you expected.



Macintosh Files; File Forks:
----------------------------

All Macintosh files comprise two forks, known as the data
fork and the resource fork.  Unlike the bytes stored in the
resource fork, the bytes in the data fork do not have to
exhibit any particular internal structure. The application
is responsible for interpreting the bytes in the data fork
in whatever manner is appropriate. The bytes in the resource
fork usually have a defined internal structure and contain
data object like menus, dialog boxes, icons and pictures.
Although all Macintosh files contain both a data fork and a
resource fork, one or both of these forks may be empty.

MacZip stores data-forks and resource-forks separately. The
Zipfile format does not allow to store two archive entries
using exactly the same name. My solution is to modify the
Path name of the resource-fork. All resource-fork names are
prepended with a leading special directory named
"XtraStuf.mac". So, when extracting on a Mac, you should
never see this directory "XtraStuf.mac" on your *disk*.

On all foreign systems that support directories in filenames
(e.g.: OS/2, Unix, DOS/Windows, VMS) you will get a
directory "XtraStuf.mac" when extracting MacZip archives.
You can delete the complete directory "XtraStuf.mac" since
Mac resources do not make much sense outside the MacOS
world.



Text encoding; Charsets of the Filenames:
-----------------------------------------

The following information is only important if you plan to
transfer archives across different platforms/language systems:

A typical Zip archive does not support different charsets.
All filenames stored in the public area (= accessible by
foreign systems other than MacOS) must be coded in the
charset ISO-8859-1 (CP1252 in the Microsoft Windows world)
or CP850 (DOSLatin1). The latter should only be used by Zip
programs that mark the archive entries as "created under
DOS". Apart from Macs, the commonly used platforms either
support ISO-8859-1 directly, or are compatible with it. To
achieve maximum compatibility, MacZip convert filenames from
the Mac OS Roman character set to ISO-8859-1 and vice versa.
But not every char of the charset MacRoman has their
equivalent in ISO-8859-1. To make the mapping in most cases
possible, I chose most similar chars or at least the MIDDLE
DOT.

Mac OS Roman character set is used for at least the
following Mac OS localizations: U.S., British, Canadian
French, French, Swiss French, German, Swiss German, Italian,
Swiss Italian, Dutch, Swedish, Norwegian, Danish, Finnish,
Spanish, Catalan, Portuguese, Brazilian, and the default
International system.

In all Mac OS encodings, character codes 0x00-0x7F are
identical to ASCII, except that
  - in Mac OS Japanese, yen sign replaces reverse solidus
  - in Mac OS Arabic, Farsi, and Hebrew, some of the
    punctuation in this range is treated as having strong
    left-right directionality, although the corresponding
    Unicode characters have neutral directionality
So, for best compatibility, confine filenames to the standard
7-bit ASCII character set.

If you generate a filename list of your archive (unzip -l),
you will see the converted filenames. Your can also extract
the archive with the switch '-i' (= ignore mac filenames),
and test your result.

This MacZip port uses its own filename stored in the
archive. At the moment, the filename will be not converted.
However, I'm planning to add support for Unicode.

Currently, the following Mac OS encodings are NOT supported:
Japanese, ChineseTrad, Korean, Arabic, Hebrew, Greek,
Cyrillic, Devanagari, Gurmukhi, Gujarati, Oriya, Bengali,
Tamil, Telugu Kannada, Malayalam, Sinhalese, Burmese, Khmer,
Thai, Laotian, Georgian, Armenian, ChineseSimp, Tibetan,
Mongolian, Ethiopic, Vietnamese, ExtArabic and finally:
Symbol - this is the encoding for the font named "Symbol".
Dingbats - this is the encoding for the font named "Zapf Dingbats".
If you extract an archive coded with one of these
charsets you will probably get filenames with funny
characters.

These problems apply only to filenames and NOT to the file
content.
of course: The content of the files will NEVER be converted !!



File-/Creator Type:
-------------

This port uses the creator type 'IZip' and it is registered
at Apple (since 08. March 1998). File types can not be
registered any more. This port uses 'ZIP ' for Zip archive
files. The creator 'IZip' type should be used for all future
versions of MacZip.



Hints for proper restoration of file-time stamps:
-------------------------------------------------

UnZip requires the host computer to have proper time zone
information in order to handle certain tasks correctly (see
unzip.txt).  To set the time zone on the Macintosh, go to
the Map Control Panel and enter the correct number of hours
(and, in a few locales, minutes) offset from Universal
Time/Greenwich Mean Time.  For example, the US Pacific time
zone is -8 hours from UTC/GMT during standard (winter) time
and -7 hours from UTC/GMT during Daylight Savings Time.  The
US Eastern time zone is -5 hours during the winter and -4
hours during the summer.

Discussion of Daylight Savings Time
-----------------------------------
The setting in the Date & Time control panel for Daylight
Savings time is a universal setting. That is, it assumes
everybody in the world is observing Daylight Savings time
when its check box is selected.

If other areas of the world are not observing Daylight
Savings time when the check box is selected in the Date &
Time control panel, then the Map control panel will be off
by an hour for all areas that are not recognizing Daylight
Savings time.

Conversely, if you set the Map control panel to an area that
does not observe Daylight Savings time and deselect/uncheck
the check box for Daylight Savings time in the Date & Time
control panel, then time in all areas celebrating Daylight
Savings time will be off by an hour in the Map control
panel.

Example:
     In the case of Hawaiians, sometimes they are three hours
     behind Pacific Standard Time (PST) and sometimes two hours
     behind Pacific Daylight Time (PDT). The Map control panel
     can only calculate differences between time zones relative
     to Greenwich Mean Time (GMT). Hawaii will always show up as
     three hours past the Pacific time zone and five hours past