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

Edit report at https://bugs.php.net/bug.php?id=52923&edit=1 ID: 52923 Comment by: me at evertpot dot com 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: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2010-12-08 22:15:23] dextercowley at gmail dot com This issue seems to be platform dependent. For example, on Windows Vista with PHP 5.3.1, parse_url('http://mydomain.com/path/道') returns $array['path'] = "/path/". However, on a MAC, it works correctly and returns "/path/道". We can work around it by uuencoding each part of the array and then decoding the various legal URL characters ("/", ":", "&", and so on) before running parse_url, then decoding the path. However, a parse_url_utf8 function would be very convenient and probably faster. Thanks. ------------------------------------------------------------------------ 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