file = 'somefile.dat'
filename = "ółśąśółąś.dat"
zip = zipfile.ZipFile('archive.zip', 'w', zipfile.ZIP_DEFLATED)
zip.write(file, filename)

above produces very nasty filename in zip archive.

file = 'somefile.dat'
filename = "ółśąśółąś.dat"
zip = zipfile.ZipFile('archive.zip', 'w', zipfile.ZIP_DEFLATED)
zip.write(file, filename.encode('cp852'))

this produces TypeError: expected an object with the buffer interface

Documentation says that:
There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write().

I convert them to byte string but it ends with an error.
If it is documentation bug, what is the proper way to have filenames like "ółśąśółąś" in zip archive?

This is not a bug. Your code that produces "very nasty filename" is the right one - the file name is actually the one you asked for. The second code is also behaving correctly: filename already *is* a bytestring, calling .encode for it is meaningless.

Oops, I take this back - I didn't notice you were using Python 3.1.

In any case, your first code is correct. What you get is the best you can ask for.

That the second case fails is indeed a bug.

See also msg79724 of bpo-4871. From looking at the code it appears that the filename must be a string, and if it contains only ASCII characters it is entered as ascii, while if it contains non-ascii it is encoded to utf-8 and the appropriate flag bits set in the archive to indicate this (I know nothing about the archive format, by the way, I'm just looking at the code).

So, in reverse of bpo-4871, it appears that in this case the API should reject bytes input with an appropriate error message.

So, in reverse of bpo-4871, it appears that in this case the API should reject bytes input with an appropriate error message.

-1. It is quite common to produce ill-formed zipfiles, and other
ziptools are interpreting them in violation of the format spec.
Python needs to support creation of such broken zipfiles,
even though it may not be able to read them back.

Well, this is the same treat-strings-and-byte-strings-equivalently-in-the-same-API problem that we've had elsewhere. It'll require a bit of refactoring to make it work.

On read zipfile decodes filenames using cp437 if the utf-8 flag isn't set. Logically, then, a binary string should be encoded using cp437. Since cp437 has a character corresponding to each of the 256 bytes, it seems to me it should be enough to decode a binary filename using cp437 and set a flag that _encodeFilenameFlags would respect and re-encode to cp437 instead of utf-8. That might produce unexpected results if someone passes in a binary filename encoded in some other character set, but it would be consistent with how zipfiles work and so should be at least as interoperable as zipfiles normally are.

This bug is very old, any development on the subject. This issue is hitting me trying to port my project (rdiffweb) to python3. It received a lot of broken filename with invalid encoding and I need to create a meaningful Zip archive with it. Currently, it just fail because zipfile doesn't accept arcname as bytes.