Req #52923 [Opn]: parse_url corrupts some UTF-8 strings
| From: | cmb@php.net | 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