Quoted from Al Dunsmuir

The assumption that each platform has a defined line termination may be justified in some cases, but not all.

For good or bad, this is the base assumption in the Zip and UnZip code and the zip standard.  If a platform gets more complicated, that needs to be a platform-specific fix.

Quoted from Al Dunsmuir

Any assumption breaks down when the ZIP archive is moved across platforms.  Think about the case where an archive is created on one platform, grown on one or more, and delivered to a final platform. 

In our case, I could see:
       z/OS MVS ->  z/OS USS -> AIX -> Linux -> Windows

Each of these 5 platforms has a different default line termination:
       record length prefix,  EBCDIC NL, ASCII LF, UTF-8 NEL, CRLF

Each entry has a field that records the platform that entry was created on.  The fact that entries were added on different platforms does not matter.  All that matters is what platform that entry says it was created on.  Line termination is handled on a per entry basis.

Quoted from Al Dunsmuir

Both of the z/OS platforms have a native mode that preserves their EBCDIC data.  Both z/OS ports have to understand the other's format.    Currently one must decide to encode the text files in an archive destined for a native-ASCII platform with the '-a' or '--ascii' option.  This translates the file data to ASCII (currenly using a simple translate table) and uses the ASCII LF line term.

If an entry has line end translation done (through selecting an option) when it is added to an archive, it might make sense to change the platform designation recorded for that entry.  I'm not sure if this is currently done.  Would have to check the code, but don't think it is.  So converting Windows line ends to Unix line ends with -ll might also result in the platform recorded for that entry being changed from DOS to Unix. Any Windows extra field information would remain and I believe UnZip uses that if the entry is unzipped on a Windows platform, regardless of what the platform setting is.  Still, this would need some research.

Quoted from Al Dunsmuir

Guessing at the current line terminator for a given file seems error prone, where a per-file flag would remove all doubt.

Sounds like a new extra field for recording line ends is being suggested.  It's still not clear, though, what that would provide over making sure the current platform field is set to correctly represent the intended target of the entry.

Quoted from Al Dunsmuir

Part of this is to ensure that unzip generates a reasonable message if a properly encoded archive is encountered that can not be decoded (since there is no --ebcdic flag for ASCII-based
unzips).

Giving UnZip a way to convert an entry with EBCDIC encoding, maybe as noted in the platform field, to the current platform encoding seems something to work on also.

Another thing to consider is handling archives from other tools.  Relying too much on non-standard information can cause trouble.  Ideally any tool should be able to do something intelligent with an entry.

Ed,
>Giving UnZip a way to convert an entry with EBCDIC encoding, maybe as
>noted in the platform field, to the current platform encoding seems
>something to work on also.

I think it is reasonable for unzip and other tools to simply recognize the EBCDIC encoding.
-  Each should be able to fully support displaying or even modifying the archive directory entry.
   That is in ASCII (and possibly UTF-8 with defined attributes.
- When asked to extract the data, however, the ASCII-based utility should emit a message
   such as "EBCDIC    zip archive member must be extracted on EBCDIC platform".  That
   would be z/OS, CMS, or perhaps I-Series one day. 


There are many different EBCDIC code pages, and you would have to replicate all of the logic
in the z/OS (or CMS) port and the z/OS (or CMS) C runtime iconv routine and tables to do
the right thing.

An alternative is for the ASCII-based platforms to support the --ebcdic flag to request a basic
translation of the data using the same translate tables that are currently present in unzip.  If
a more precise translation is required, then they can always extract on an EBCDIC platform.
There could even be a simple check and message issued if non-translatable characters are
encountered.


Al

Ed,
>Giving UnZip a way to convert an entry with EBCDIC encoding, maybe as
noted in the platform
>field, to the current platform encoding seems
something to work on also.

I think it is reasonable for unzip and other tools to simply recognize the EBCDIC encoding.
-  Each should be able to fully support displaying or even modifying the archive directory entry.
   That is in ASCII (and possibly UTF-8) with defined attributes.
- When asked to extract the data, however, the utility should emit a message such as "EBCDIC
   zip archive member must be extracted on EBCDIC platform".  That would be z/OS, CMS, or
   perhaps I-Series one day. 


There are many different EBCDIC code pages, and you would have to replicate all of the logic
in the z/OS (or CMS) port and the z/OS (or CMS) C runtime iconv routine and tables to do
the right thing. 

An alternative is for the ASCII-based platforms to support the --ebcdic flag to request a basic
translation of the data using the same translate tables that are currently present in unzip.  If
a more precise translation is required, then they can extract on an EBCDIC platform.


Al