Should the note be removed, or should it say something like "Unicode
file names are supported. New in Python 2.6."? Is there anything else
that should be mentioned?
The note should be corrected, documenting the behaviour implemented.
More on cp437: I see where you mentioned to the patch author that a
unicode string should be encoded in cp437 if possible, but this was
not done -- it first tries ascii. What are your views on what encoding
should be assumed if the utf8 flag is not set?
There isn't any standard that is widely followed (just as the note that
you declared bafflegab says). While APPNOTE.TXT specifies it as cp437,
implementations often ignore that, because a) they didn't know, and b)
cp437 was too limited for what they want to do. So we see all kinds of
alternative implementations - often involving the locale's code page
(and on Windows, both OEMCP and ACP get used - often just as a side
effect of whatever internal representation the applications use).
In 2.x, Python doesn't need to decide, so when opening a zip file, the
file names get reported as byte strings unless they have the UTF-8
bit set (in which case they get decoded). In 3.x, file names (in the
zipfile module) uniformly use the (unicode) character string type, hence
that version implements the spec, by decoding as 437.
Upon encoding, chosing between ASCII and CP437 has trade-offs. Notice
how both are formally complying to the spec, as ASCII is a subset of
CP437 (i.e. even though it uses the ASCII codec, it *still* encodes
as CP437). The tradeoffs can be studied by looking at three groups
of file names:
- pure ASCII; choice does not matter (both ascii and cp437 can
encode the file name, and both get the same result)
- arbitrary string containing non-CP437 characters; choice does
not matter (neither ascii nor cp437 can encode, so the UTF-8
bit must be used)
- others; here are the tradeoffs. Pro ASCII: receiver can unambiguously
reproduce the original file name, as the UTF-8 bit will be set.
Pro CP437: old software (unaware of the UTF-8 bit) has a chance
of correctly guessing the file name (if it followed APPNOTE.TXT).
I (now) prefer the tradeoff being taken, as it's the one that
produces more reliable results in the long run (i.e. when more
and more zip readers support UTF-8).
Regards,
Martin
