#36183 [Com]: urlencode wrongly decodes %00-chars

ID: 36183 Comment by: me at evancarroll dot com Reported By: karel at linux dot be Status: Feedback Bug Type: URL related Operating System: Linux PHP Version: 4.4.0 New Comment: ecarroll@x60s:~$ php --version PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23 2009 14:35 :05) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies ecarroll@x60s:~$ md5sum /usr/bin/php5 5c83d3bd430c8673a9124c3adbb662f5 /usr/bin/php5 This is packaged php5 that Ubuntu ships with. It might be the Suhosin patch that is causing this problem. Previous Comments: ------------------------------------------------------------------------ [2009-06-23 18:07:14] rasmus@php.net Works fine on 64-bit Linux with PHP 5.2.10 Also fine on 32-bit OSX with PHP 5.3.0 So, if you still see this problem, please be more specific about your PHP and OS versions. ------------------------------------------------------------------------ [2009-06-23 17:15:26] me at evancarroll dot com I've still got this problem. (this was not the subject of the below conversation) 11:51 < rasmus> main/php_variables.c has the php_default_treat_data() function which implements the actual default string parsing logic in PHP. And no, you can't change it. It would break every PHP app ever written ... 11:52 < rasmus> the point is that it isn't broken 11:53 < rasmus> and if you think it is, then you are simply wrong. 11:53 < EvanCarroll> http://www.google.com/search?q=site%3Abugs.php.net+parse_str&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a 11:54 < rasmus> your point? 11:54 < rasmus> those are all people who don't understand how to use it 11:54 < rasmus> like I said, it is exactly the same code as PHP uses to parse incoming user data 11:55 < rasmus> and it adheres to all the same rules Apparently, not reviewing the bug tracker is an indicator that everyone else doesn't know what they're doing. 32bit build ------------------------------------------------------------------------ [2006-03-23 02:09:35] judas dot iscariote at gmail dot com Somebody needs to change the summary, and the PHP version, It can be reproduced with 5.1.3-dev CVS. ------------------------------------------------------------------------ [2006-03-23 02:05:50] judas dot iscariote at gmail dot com odd.. Im getting other different result with a 10 minutes ago source code from the CVS (in amd64) string(42) "x%DAs%CE%CF-%28J-.V%C8M%05%5C0%19%BD%04%3F" string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F" the previuos result mentioned was from my system PHP compiled yesterday... :S ------------------------------------------------------------------------ [2006-03-23 01:52:33] judas dot iscariote at gmail dot com Folks, this seems to be a real bug 64 bit related I think since the OP test in x86 says me: string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F" string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F" the expected result, Hoever in my linux amd64 I get string(38) "x%DAs%CE%CF-%28J-.V%C8M%05%19%BD%04%3F" string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F" if this is not a bug,It have an unconsistent behaviuor... ------------------------------------------------------------------------ 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 http://bugs.php.net/36183 -- Edit this bug report at http://bugs.php.net/?id=36183&edit=1