Bug #62119 [Ver->Ana]: basename broken with non-ASCII-chars

Edit report at https://bugs.php.net/bug.php?id=62119&edit=1 ID: 62119 Updated by: cmb@php.net Reported by: thomas dot hebinck at digionline dot de Summary: basename broken with non-ASCII-chars -Status: Verified +Status: Analyzed Type: Bug Package: *Directory/Filesystem functions Operating System: Linux/Ubuntu PHP Version: 5.3.13 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > This is still an issue in PHP 5.6 and it is PHP's problem, since > PHP roll its own implementation of basename. Yes. The actual culprit is that php_basename() uses mblen(3) if available, and that is locale dependend. If an invalid character is passed to mblen(3), -1 is returned, and the length is assumed to be 1[1], what appears to be doubtful. Bailing out returning FALSE, or at least a notice/warning might be more useful. > On way to solve this is to set the LC_TYPE to UTF-8, but I guess > that PHP should handle this. As of November 2010 it is documented[1]: | basename() is locale aware, so for it to see the correct | basename with multibyte character paths, the matching locale | must be set using the setlocale() function. So clearly, setting the appropriate locale is the job of callers of basename(). I'm going to move the notes up on the page, and will suggest adding a notice/warning in case of unrecognized characters. [1] <https://github.com/php/php-src/blob/PHP-7.0.12/ext/standard/string.c#L1531-L1532> [2] <http://php.net/manual/en/function.basename.php#refsect1-function.basename-notes> Previous Comments: ------------------------------------------------------------------------ [2016-10-14 16:31:00] cmb@php.net Related To: Bug #67756 ------------------------------------------------------------------------ [2015-06-10 08:56:20] christiansen dot jacob at gmail dot com This is still an issue in PHP 5.6 and it is PHP's problem, since PHP roll its own implementation of basename. The problem seems to occur when running basename on a string that have a multibyte char as the first char when LC_TYPE is set to POSIX. Which seems to be default for PHP. On way to solve this is to set the LC_TYPE to UTF-8, but I guess that PHP should handle this. ------------------------------------------------------------------------ [2014-08-04 17:04:32] bugs dot php dot net at dw-perspective dot org dot uk In https://bugzilla.redhat.com/show_bug.cgi?id=1126399, a glibc developer says that glibc's basename() is not locale-dependent - and therefore that if PHP's basename() is locale dependent, then that points to a PHP issue. ------------------------------------------------------------------------ [2014-08-04 10:36:04] bugs dot php dot net at dw-perspective dot org dot uk I have this problem too, on a Fedora 20 (=current) system. Interestingly, the system's "basename" binary, which I'd assume is making the same glibc call, does not have this problem: # LANG=C basename '/test/äaä.txt' äaä.txt So perhaps the problem is more subtle that a simple glibc bug? ------------------------------------------------------------------------ [2012-07-03 15:29:18] pollita@php.net Verified on Debian, but since this is the behavior of the underlying libc implementation, I'm not sure it's PHP's role to fix it. Leaving open for now since we could potentially detect this case and deal with it, but on initial look I'm inclined to push it off on the OS. ------------------------------------------------------------------------ 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=62119 -- Edit this bug report at https://bugs.php.net/bug.php?id=62119&edit=1