ZipArchive PHP function not support filenames that contains national characters. (Reason: UTF-8 filenames not supported in ZipArchive fuction at this time, only DOS charshets supported).
Workaround:

replace (in filebrowser.module)
     $zip->addFile($file_data['path'], $file_name);
by
     $zip->addFile($file_data['path'], iconv("UTF-8","CP852",$file_name));

Change the CP852 codepage for your own code page (CP437, CP850 etc.).

Comments

Yoran’s picture

Yoran CreditAttribution: Yoran commented
Status: Active » Postponed (maintainer needs more info)

Isn't iconv in a specific php package ? I don't really like the idea of introducing a new dependency like that. Can't we manage that with mbstrings ?

Yoran’s picture

Yoran CreditAttribution: Yoran commented

It looks like even DOS code pages are bugged with this zip implementation, so I have some alternatives :
- removing zip support as it is and replacing it by a native call to zip utility (if exists).
- using transliteration module to remove all kind of national characters

any idea ?

Gozi’s picture

Gozi CreditAttribution: Gozi commented

Iconv module is part of PHP as of PHP 5 thus external module is not needed anymore.
Mbstring do not support national DOS charsets (eg: CP850, CP852, etc.). http://us2.php.net/manual/en/mbstring.supported-encodings.php
I think, using transliteration module not really good choice.

asb’s picture

asb CreditAttribution: asb commented

> I think, using transliteration module not really good choice.

The 'Transliteration' module does not remove special characters but transliterate them according to well accepted rules. I think this would be a sound option to make the 'Filebrowser' module more robust.

Yoran’s picture

Yoran CreditAttribution: Yoran commented

I think gozi know what transliteration can do, but the problem is that all special characters will be removed from the archive, thing that we don't want. I still don't know what to do about this.

Yoran’s picture

Yoran CreditAttribution: Yoran commented
Status: Postponed (maintainer needs more info) » Closed (fixed)
asb’s picture

asb CreditAttribution: asb commented

I still don't know what to do about this.

= closed (fixed)

Seriously?

Yoran’s picture

Yoran CreditAttribution: Yoran commented
Status: Closed (fixed) » Active

my mistake. sorry. But I still don't have any idea :)

asb’s picture

asb CreditAttribution: asb commented

I still don't understand what the problem with transliteration is; it's the only sane way to handle security and naming issues, it's used as well for Drupal core's "files" directory as for CCK filefields storage, so why it's not good enough for Filebrowser?

Please construct one hypothetical case where transliteration would cause an inacceptable loss of information or cause any serious problem. In #3 it was just claimed that using transliteration would not be a good choice. Please elaborate.

Yoran’s picture

Yoran CreditAttribution: Yoran commented

Community projects is all about agreement on what to do or not. When I write "I don't know what to do", you should understand "I don't see any solution that can make everyone pleased" :-) I proposed transliteration at the first place and #3 gave an objection. So for me there is kind of a stand-by situation.

But I do agree with you, at one point I'll decide to go to transliteration as there is no further explanation why not to :-)

"My mistake" when I closed this ticket was just to select the wrong status, not to close the conversation about it ;-)

BTW, in other tickets (ex. #1188938) we are more and more thinking about moving all archive stuff (zip, but also proto unzip, etc.) in a stand alone module using this time OS binaries for archiving tasks (bzip2, zip, rar, etc..). This will solve this encoding problem by dropping bugger PHP/Zip implementation. Any objection about this ?

Nicolas Georget’s picture

Nicolas Georget CreditAttribution: Nicolas Georget commented

Subscribe

clivesj’s picture

clivesj CreditAttribution: clivesj commented
Issue summary: View changes
Status: Active » Closed (outdated)