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);
}
...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
