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: simonsimcity at gmail 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: Related to #68296 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2010-09-26 09:46:39] cataphract@php.net The problem is that nothing guarantees a percent-encoded URL should be interpreted as containing UTF-8 data or that an (invalid) URL containing non-encoded unreserved characters should be converted to UTF-8 before being percent-encoded. In fact, while most browsers will use UTF-8 to build URLs entered in the address bar, in case of HTML anchors in HTML pages, they will prefer to use the encoding of the page instead if it's also an ASCII superset. That said, the corruption you describe seems uncalled for. In fact, I am unable to reproduce it. This is the value of $url I get in the end: string(32) "/he/פרויקטים/ByYear.html" ------------------------------------------------------------------------ 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