there are cases in which filenames are stored into zip with a codify and an extra field to identify the starting filename code page, like described at http://www.artpol-software.com/ZipArchive/KB/0610051525.aspx#extra In these cases, zip-2.32 doesn't seems to handle correctly the files (issues in unzip -lv test.zip and with unzip test.zip), while debian unzip 5.52 ( http://packages.debian.org/stable/utils/unzip ) is reported handling them fine, and even kde's konqueror kio_zip kio_slave handles them fine. Reproducible: Always Steps to Reproduce: 1.python code to generate test zip : UX= open('prova.txt', 'w') UX.write('test') B = zipfile.Zipfile('test1.zip', 'w') B.write('prova.txt', 'provaèàò.txt', zipfile.ZIP_DEFLATED) B.close() UX.close() 2. another bit of python code at http://deadbeefbabe.org/paste/5626?__session_just_started__=1 that will generate another testfile, again handled fine by debian unzip. 3. in an utf-8 system, looking at these files with "unzip -lv test1.zip" outputs wrong chars and extracting them outputs wrong filenames Actual Results: inserting file named "pðkaó.txt" in a utf-8 environment, through other meanings than info-zip (as python for example), extracting the file with unzip I get : "p\255ka\276.txt" Expected Results: inserting file named "pðkaó.txt" in any correct meaning should result in extracting file named "pðkaó.txt"
I'm sorry for incomplete report, this is an issue of unzip. In debian they added a patch (look at https://bugs.launchpad.net/debian/+source/unzip/+bug/10979 ) so it seems that unzip-5.52 from debian works, however the patch at that page doesn't handles those zipfile in the right way (better to look the patch at http://packages.debian.org/stable/utils/unzip ....)
Huff, no, it seems that's fixed in ubuntu, not in debian... sorry not my day.
the linked bug is already patched upstream,my fault. I'll collect more info before reporting bug.