KDE Lands More Crash Fixes, Activities Feature Working On Wayland

[oiaohm]

I know the spec, right. For example, version 4.5 (https://web.archive.org/web/20011203...rt/appnote.txt)
does only state 256 characters & ASCII. It doesn't even explain the purpose of slashes in file names.

You did not read all that appnote.txt did you.

file name: (Variable) The name of the file, with optional relative path. The path stored should not contain a drive or device letter, or a leading slash. All slashes should be forward slashes '/' as opposed to backwards slashes '\' for compatibility with Amiga and Unix file systems etc. If input came from standard input, there is no file name field.

Yes this is a direct quote out of that appnote.txt you found.

caligula slash direction is stated. Any file name with a backwards slash in is in invalid. The example foo.zip put up be Nth_man is a invalid zip file. Valid zip files don't have backward slashes in file names. Yes the mean of forward slash also should come from the Amiga/Unix meaning.

Sorry zip format states everything about slashes you. So ark rejecting to decompress a file name with a '\' in it was conforming to standard doing that. Yes under windows if you use PKzip made by the maker the standard of zip you cannot make zip file with a '\' in the file name either it just will not happen.

When something is technically invalid by standard things get tricky. Do you stick to the standard or do you support broken.

[caligula]

You did not read all that appnote.txt did you.

Yes this is a direct quote out of that appnote.txt you found.

caligula slash direction is stated. Any file name with a backwards slash in is in invalid. The example foo.zip put up be Nth_man is a invalid zip file. Valid zip files don't have backward slashes in file names. Yes the mean of forward slash also should come from the Amiga/Unix meaning.

Sorry zip format states everything about slashes you. So ark rejecting to decompress a file name with a '\' in it was conforming to standard doing that. Yes under windows if you use PKzip made by the maker the standard of zip you cannot make zip file with a '\' in the file name either it just will not happen.

When something is technically invalid by standard things get tricky. Do you stick to the standard or do you support broken.

I'm perfectly aware of specification texts - the zip appnote is pretty informal. It states that names may contain relative paths. It also states the forward slashes should be used, but it doesn't even explicitly state that the slash symbol is the path separator in relative paths. You need to deduce all that yourself. Also, The older versions of that spec like that 4.5 don't state any standard code page afaik. The more recent ones with Unicode support tell how to turn on this support, but the legacy archives may contain filenames encoded in all sorts of code pages.

[oiaohm]

I'm perfectly aware of specification texts - the zip appnote is pretty informal. It states that names may contain relative paths. It also states the forward slashes should be used, but it doesn't even explicitly state that the slash symbol is the path separator in relative paths. You need to deduce all that yourself. Also, The older versions of that spec like that 4.5 don't state any standard code page afaik. The more recent ones with Unicode support tell how to turn on this support, but the legacy archives may contain filenames encoded in all sorts of code pages.

To be correct that appnote file is not the specification. The original specification is in fact pkzip the binary.

Anyone who digs far enough there is meant to be only "CP437" and UTF-8 in an official to specification Zip

There are newer versions of appnote that detail more.

D.1 The ZIP format has historically supported only the original IBM PC character encoding set, commonly referred to as IBM Code Page 437. This limits storing file name characters to only those within the original MS-DOS range of values and does not properly support file names in other character encodings, or languages. To address this limitation, this specification will support the following change.

https://pkware.cachefly.net/webdocs/...NOTE-6.3.0.TXT Yes this bit first appears in 2006 appnote.txt


But that does not matter because early version of appnote.txt is really a application note about how pkzip did things and its the pkzip that was the standard so the fact pkzip only processed CP437 that was the zip file limitation.

All the other legacy zip files contain any other encoding have always been technically invalid zip files and perfectly acceptable to refuse to open them because the reference/standard implementation pkzip would not. Yes appnote.txt gets more detailed over the years.

There are a lot zip files people want to open that are technically invalid.

Yes the early appnote.txt left a lot of details out that you were meant to take from the reference/standard implementation that latter versions of appnote.txt state that people could not miss them.

XIV. Change Process ------------------- In order for the .ZIP file format to remain a viable definition, this specification should be considered as open for periodic review and revision. Although this format was originally designed with a certain level of extensibility, not all changes in technology (present or future) were or will be necessarily considered in its design. If your application requires new definitions to the extensible sections in this format, or if you would like to submit new data structures, please forward your request to [email protected]. All submissions will be reviewed by the ZIP File Specification Committee for possible inclusion into future versions of this specification. Periodic revisions to this specification will be published to ensure interoperability. We encourage comments and feedback that may help improve clarity or content.

This was in the appnote you quoted. If you were implement a zip implementation had a question you had a email address. For internal usage I did back then implement a zip implementation and I did email for clarification and they did answer on that CP437 point.

Using a different Char encoding is a different data structure. Yes zip file encoding mess is because people were willing to use a different data structure in zip files without approval. Asking to change the coding or what the encoding was right back to the first version of Zip before Appnote 6.3.0 got you the answer from pkware that the file names were CP437 nothing else.

Hard reality here if you are implementing something properly standard and you are not sure something and there is proper contact who does answer you are meant to use them instead of doing guess work and if you do guess work what you make could be called invalid to standard and you with your users get to keep the broken.