Bug #72200 [Ver]: ZipArchive::open() creates invalidly encoded filenames

From: Date: Thu, 19 May 2016 12:16:41 +0000
Subject: Bug #72200 [Ver]: ZipArchive::open() creates invalidly encoded filenames
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-201193@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72200&edit=1 ID: 72200 User updated by: thomas dot kuhn dot berlin at gmail dot com Reported by: thomas dot kuhn dot berlin at gmail dot com Summary: ZipArchive::open() creates invalidly encoded filenames Status: Verified Type: Bug Package: Zip Related Operating System: Windows PHP Version: 7.0.6 Block user comment: N Private report: N New Comment: @cmb: great that you noticed that mistake and that you can verify the problem. thank you for your time! your suggestions sound plosible to me but i have no real insight and therefor can't participate in discussing the matter much. but it seems evident that ZipArchive behaves differently then "the rest" of PHP. Previous Comments: ------------------------------------------------------------------------ [2016-05-18 10:56:44] cmb@php.net Thanks for testing the script. But actually, I have to apologize, because I didn't carefully check my test results which were wrong as I did run the script with PHP 5.6 first, which created the zip file as expected, and later running with PHP 7.0.6 found the zip created by the earlier run. So, I can reproduce the issue with PHP 7.0.6 (both x86 and x64). While file_put_contents("m\xc3\xbcller", …) creates the file müller as expected, ZipArchive creates the file müller. Apparently, ZipArchive maps filenames from UTF-8 to UTF-16/UCS-2, while the plain file functions do not. That might be caused by recent builds of the bundled libzip using the *W*idechar instead of the *A*nsi variants of the WinAPI. ------------------------------------------------------------------------ [2016-05-17 15:57:07] thomas dot kuhn dot berlin at gmail dot com @cmb: oh, sorry, you are right, i apologize :) i copyNpasted your script and executed it on my system, the output was as follows: bool(true) bool(true) bool(true) bool(false) Windows NT 6.1 build 7601 (Windows 7 Professional Edition Service Pack 1) AMD64 PHP/7.0.6 Compiler: MSVC14 (Visual C++ 2015) Architecture: x64 ------------------------------------------------------------------------ [2016-05-17 13:34:42] cmb@php.net > @cmb: you missed the point: When filenames contain > !!non-us-ascii-letters!! like !!öäü!! or !!asian chars!! etc., Yes, I understood this point. The filename in my script is actually müller encoded as UTF-8. I just wanted to make sure, that we're really dealing with UTF-8, what's not necessarily the case with your script (consider it was stored encoded as something else than ISO-Latin-1; then utf8_encode() might fail). Furthermore I wanted to make the script more portable and generic so it could serve as basis for a .phpt. And it might be useful to check the return value of $zip->close(), too. ------------------------------------------------------------------------ [2016-05-17 12:40:56] thomas dot kuhn dot berlin at gmail dot com @cmb: you missed the point: When filenames contain !!non-us-ascii-letters!! like !!öäü!! or !!asian chars!! etc., ZipArchive creates filenames in a way that those files are not accessible via PHP because the encoding is wrong. and btw !!adding!! files to an archive containing such letters in their filename fails as well. i have to copy them to to tmp-files first :( ------------------------------------------------------------------------ [2016-05-17 12:32:10] cmb@php.net Using the following slightly modified script, I can't reproduce the issue with PHP 7.0.6 (VC14 x86 Non Thread Safe (2016-Apr-29 00:38:17)) on Windows 10: <?php $filename = "m\xc3\xbcller"; $zip = new ZipArchive; var_dump($zip->open($filename, ZipArchive::CREATE|ZipArchive::OVERWRITE)); var_dump($zip->addFromString('foo', 'bar')); var_dump($zip->close()); var_dump(file_exists($filename)); Output bool(true) bool(true) bool(true) bool(true) What results do you get running this script? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=72200 -- Edit this bug report at https://bugs.php.net/bug.php?id=72200&edit=1

« previous php.bugs (#201193) next »