- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Tue, 18 Dec 2007 14:55:15 +1000
- To: "Tex Texin" <tex@yahoo-inc.com>, "public-appformats@w3.org (public)" <public-appformats@w3.org>
Hi Tex, > > > My view remains that cp437 is not well understood, and is no longer > > > used with frequency, and so its support is not required. This is generally true for OSs. However, according to the Zip spec, Zip should treat/expect file names as cp437 to conform. > > > Supporting cp437 will simply lead to misuse as unintentionally, or > > > intentionally, it will be used as a proxy for iso8859-1 or other > > > encodings and cause unnecessary problems. True. > > > Although zip has a method for declaring the encoding, and could be > > > implemented in a compliant fashion, it also may not be. > > > There isn't a good way to detect and reject a filename with an > > > encoding other than cp437 or utf-8. > > > > > > It is reasonable and prudent for Widgets to insist on UTF-8 > > > filenames with the appropriate bit setting, and eliminate the > > > ambiguity, and be 100% compatible with the zip spec. Problems with > > > the encoding are more likely to be detected if UTF-8 is required. I've now included "Encoding File Name Field in UTF-8 is recommended" into the spec. This explicitly makes it the preferred encoding format for widgets. > > > Authors can use a modern tool with support for UTF-8, or restrict > > > their names to ASCII. > > > > > > So, I do not see any reason to support the cp437 encoding. > > > > > > That said, if there isn't support for this viewpoint, it is ok to go > > > ahead, we can agree to disagree. The world is plenty polluted with > > > encodings, this won't do that much damage over what already exists. > > > I think otherwise we are (or I am) getting repetitive in stating the case. I don't think anyone disagrees. It's just that the tools are for creating UTF-8 zip archives are not all there yet. I am sure that will change with time (especially now that it is part of the Zip spec). > > > Separately, you list semicolon as a character that can be used in filenames. > > > On many systems it is a command separator and is disallowed in > > > filepaths. I would make it a reserved character. Done. > > > Plus is also used for command syntax and I would think should be reserved. > > > > > > If not reserved, then a warning should be given. > > > I've noted it as a potential issue in the spec. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Tuesday, 18 December 2007 05:39:55 UTC