Re: $_GET and multiple spaces.

Andrés Robinet schreef:

-----Original Message-----

...

$name = 'mylist[myindex]';

this is almost an invite to moan about how http_build_query() was 'fixed' in 5.1.3 to escape square brackets ... which makes php nolonger do one of the coolest, imho, with regard to incoming GET/POST values - namely auto-convert bracketed request var names into native arrays. at least if those strings are used in anything other than a URL context (form inputs anyone). I would have been nice to have the encoding as an optional switch/argument.

Well, almost... the other part of the world that arguably wanted square brackets escaped in http_build_query will be very pleased (let me tell you I don't use http_build_query, but have my own as sometimes PHP 5 is not an option...). I guess they thought http_build_query would always be used in an URL context. But yes... escaping square brackets could be made optional and we get the best of both worlds. Anyway... my point was that names may need escaping, at least in some contexts. But let me ask you because maybe I'm wrong: <a href="index.php?list%5Bindex%5D=value">Click</a> Wouldn't this be translating into $_GET['list']['index'] == 'value'? As far as I've tested, it is... Also, it seems that "[" and "]" are unsafe characters according to http://www.ietf.org/rfc/rfc1738.txt

...

Maybe that's why they chose to escape square brackets. I'm not a standards freak, but rather a pragmatic man. Just trying to prove a point.

you are completely correct, and I agree. I am also pragmatic - it was pragmatism that got me using http_build_query in a non-url context ... I have a ORM-like tool with a generic frontend that creates very complex POST/GET values/strings that describe what I like to call a 'data path' .. which allows you to specify stuff like 'the list [or details] of all subitems belonging to the 3 selected subitems of the item with keyfield values ,Y and Z'. this is done using a structure which is a nested array that translates accross requests nicely using http_build_query() - but it means the resulting request parameters names are used in a GET context and in POST context which means using the parameter names in the context of INPUT tag names, and in such cases the encoding is not wanted - it maybe the that encoding is required by certain standards in such a context BUT php doesn't recognise urlencoded square brackets in the way one wants ... namely one doesn't get a neat nesed array in $_POST but rather stuff like: $_POST["e[f][n]"] = "entityname" (as opposed to:) $_POST["e"["f"]["n"] = "entityname" (which is what my ORM-like generic thingy was expecting.) the function I showed isn't name 'inputPost*' for nothing :-) it was specifically written for the task of making request parameter names as generated by http_build_query() usable in the name attribute of input tags and have them behave as they would if found in a GET query string. the only reason I remember all this about http_build_query() is because it: a) totally broke my app/tool at a time when I didn't have control of the php version and didn't have time to actually fix (well I had to make time :-) b) it was quite a headache getting the regexp in question to do exactly what I wanted (e.g. that only square brackets encountered in request variable names should be decoded and those found in request variable values should be left encoded, etc, etc). sometimes it's fun to reminisce :-P

     /* since php5.1.3 http_build_query() urlencodes square brackets -

this does not please us at all,

      * this function fixes the problem the encoding causes us when

using http_build_query() output

      * in hidden INPUT field names.
      */
     function inputPostQueryUnBorker($s)
     {
         // first version - slower? more code!
         /*
         return preg_replace('#(\?|&(?:amp;)?)([^=]*)=#eU',
                             "'\\1'.str_replace(array('%5B','%5D'),

array('[',']'), '\\2').'='",

                             $s);
         //*/

         // second version - faster? more compact! (should work

identically to the above statement.

         return preg_replace('#%5[bd](?=[^&]*=)#ei',

'urldecode("\\0")', $s);

     }

...