Req #52923 [Opn]: parse_url corrupts some UTF-8 strings

From: Date: Sun, 19 Jan 2020 09:07:10 +0000
Subject: Req #52923 [Opn]: parse_url corrupts some UTF-8 strings
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-224987@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=52923&edit=1 ID: 52923 Updated by: cmb@php.net Reported by: masteram at gmail dot com Summary: parse_url corrupts some UTF-8 strings Status: Open Type: Feature/Change Request Package: URL related Operating System: MS Windows XP PHP Version: 5.3.3 Block user comment: N Private report: N New Comment: The internal implementation php_url_parse_ex()[1] uses a mix of ctype functions (such as isalpha()) and hard-coded character values, what looks wrong to me. [1] <https://github.com/php/php-src/blob/php-7.3.13/ext/standard/url.c#L94-L321> Previous Comments: ------------------------------------------------------------------------ [2016-03-08 00:08:13] me at evertpot dot com Chiming in with "me too". This snippet works correctly on linux: https://3v4l.org/OSlSY On a mac the output gets corrupted. Output: %2F%E6__%E8%AF_%E6%B3_%E5_%AB%E5__.zh I can definitely see the reasoning behind parse_url only support valid urls, however... IF that's the intended behavior it should be consistent across platforms and fail instead of corrupting the input. My use-case for parse_url is to actually to actually correct (and normalize) these urls, but I was assuming that unknown octets are just passed through. This is true for some octets, but not all. ------------------------------------------------------------------------ [2016-01-15 08:10:46] simonsimcity at gmail dot com Related to #68296 ------------------------------------------------------------------------ [2016-01-15 07:57:52] simonsimcity at gmail dot com This seems to be a quite old bug but still valid. I also stumbled on it and went a bit further: It works on Ubuntu Linux. My locale is set to "en_US.UTF-8", so bugsphpnet@lumental.com's comment could be the reason for Linux installations. It does NOT work using OS X, contrary to what dextercowley@gmail.com said. I tried it with several PHP versions (up to 7.0.2). I tried it by any locale-setting I could find that differed from my Linux-server-settings. Related conversations: https://github.com/symfony/symfony/issues/16776, A post on the general mailinglist: http://news.php.net/php.general/325346 (wasn't able to find a URL that shows the related responses ...) I guess this one also is related to 68296, where it's about the handling of newlines in parse_url(). ------------------------------------------------------------------------ [2014-01-28 21:42:02] derkontrollfreak+9hy5l at gmail dot com If you use the default "C" locale you should be fine, too. ------------------------------------------------------------------------ [2012-10-11 20:51:26] bugsphpnet at lumental dot com On our Debian 4.3.2-1.1 server, changing the locale from LANG=en_US to LANG=en_US.UTF-8 seems to have fixed this problem. In my opinion, parse_url() should treat all extended characters (octets 80-FF) as opaque characters and copy them as-is without modification. Then, the function will work fine for both utf-8 and iso-8859-1 strings. The behaviour of parse_url() should not depend on the LANG setting. In my opinion, this function is buggy. ------------------------------------------------------------------------ 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=52923 -- Edit this bug report at https://bugs.php.net/bug.php?id=52923&edit=1

« previous php.bugs (#224987) next »