This patch fixes UnicodeDecodeError when attempting to write files to zipfile with filename of unicode class.

This patch is incorrect. It relies on the system encoding, and allows non-string things as file names. What it really should do is to encode in code page 437; bonus points if it falls back to the UTF-8 feature of zip files when that encoding fails.

File Added: python-zipfile-unicode-filenames-utf8.patch

File Added: python-zipfile-unicode-filenames-utf8-2.patch

File Added: python-zipfile-unicode-filenames-utf8-3.patch

Any chance of this making it in sometime?
The current behaviour is rather limiting/annoying.

Any chance of this making it in sometime?

I'll see what I can do for 2.6, but perhaps it gets delayed until
2.7/3.1.

Thanks for the patch, committed as r62724. I didn't see the need to
clear the UTF-8 flag, so I left it in (in case somebody wants to inspect
it).

Martin, I cleared the flag bit because filename was changed in-place, to
mark that filename does not need further processing. This was primarily
compatibility concern, to accommodate for situations where users try to
do such decoding in their own code (this way flag won't be there, so
their code won't trigger). Without clearing the flag bit, calling
_decodeFilenameFlags second time will fail, as well as any similar user
code.

I suggest that if users want to know if filename is unicode, they should
check that filename is of class unicode.

Martin, I cleared the flag bit because filename was changed in-place, to
mark that filename does not need further processing. This was primarily
compatibility concern, to accommodate for situations where users try to
do such decoding in their own code (this way flag won't be there, so
their code won't trigger). Without clearing the flag bit, calling
_decodeFilenameFlags second time will fail, as well as any similar user
code.

I'm not concerned about the compatibility; code that actually does the
decoding still might break since it would expect the filename to be a
byte string if it doesn't explicitly decode. Such assumption would still
break under your change.

I am concerned about silently faking data. The library shouldn't do
that; it should present the flags unmodified, as some application might
perform further processing (such as displaying the flags to the user).
It would then be confusing if the data processed isn't the one that was
read from disk.

I suggest that if users want to know if filename is unicode, they should
check that filename is of class unicode.

That won't work in Py3k, which will always decode the filename.