Hi All,
Basic types were added to our JSON decoder to PHP 5.2.1, this allows
one to use json_encode / json_decode on any of our scalar types. Omar
correctly identified #38680 as not a bug but it appears that Ilia
added support for this anyway violating the RFC [1]. Maybe there was a
reaso
Fri, Dec 12, 2008 at 7:50 PM, Scott MacVicar wrote:
> The problem here is that none of the other JSON parsers in any other
> language support this and more importantly the browsers [2] which are now
> adding native JSON support. Users are frequently expecting the result from a
> json_encode in P
Le samedi 13 décembre 2008 à 03:50 +, Scott MacVicar a écrit :
> Hi All,
>
> Basic types were added to our JSON decoder to PHP 5.2.1, this allows
> one to use json_encode / json_decode on any of our scalar types. Omar
> correctly identified #38680 as not a bug but it appears that Ilia
>
Mark Karpeles wrote:
> Le samedi 13 décembre 2008 à 03:50 +, Scott MacVicar a écrit :
>> Hi All,
>>
>> Basic types were added to our JSON decoder to PHP 5.2.1, this allows
>> one to use json_encode / json_decode on any of our scalar types. Omar
>> correctly identified #38680 as not a bug bu
> For reference I saw people use json_encode() to pass a string to
> javascript into their page while avoiding bugs/XSS with stuff like
> .
>
> var foo = ;
> ... (yes, they maybe heared somewhere that JSON is *not* javascript, I
> told 'em too).
This is not correct. JSON *is* valid JavaScript, bu
var foo = ;
... (yes, they maybe heared somewhere that JSON is *not* javascript, I
told 'em too).
JSON is a strict subset of JavaScript, and the above scenario is something I
also do often.
Since PHP generates web pages, any time I need to generate a JS literal
json_encode() is the natural e
Stan Vassilev | FM wrote:
>>> var foo = ;
>>> ... (yes, they maybe heared somewhere that JSON is *not* javascript, I
>>> told 'em too).
>
> JSON is a strict subset of JavaScript, and the above scenario is
> something I also do often.
>
> Since PHP generates web pages, any time I need to generate
>
> I'm not sure if that is the right way of looking at it though. I think
> the only question is how to represent the scalar types, not whether they
> should be allowed. As far as I am concerned it is obvious that they be
> allowed and the JSON spec is quite explicit that JSON can be used to
> r
Sorry for top posting. I see no reason why php should not interop with
javascript 100% as it should. I do not see a reason to create new
functions, parameters, etc. The existing should be expected to both
encode and decode json with javascript properly. If there is a
mismatch right now, the
mike wrote:
> Sorry for top posting. I see no reason why php should not interop with
> javascript 100% as it should. I do not see a reason to create new
> functions, parameters, etc. The existing should be expected to both
> encode and decode json with javascript properly. If there is a mismatch
>
I can't give specifics (I'm mobile and I don't remember where the code
would be anyway) but we had an issue with php and javascript exchange
via json where the php output using json_encode and we had to wrap it
with additional braces for it to be usable. Sorry for being vague,
this thread r
Yes, but that would be going to a json_parse thing somewhere, not pure
Javascript.
-Rasmus
mike wrote:
> I can't give specifics (I'm mobile and I don't remember where the code
> would be anyway) but we had an issue with php and javascript exchange
> via json where the php output using json_encode
Do you mean a json_parse in javascript (like a better eval() I
assume)? Thats what we were doing. Json is not supposed to be pure
javascript either, but a serialized representation of variables like
php's serialize(). So I would not expect a json string to be usable
without using eval or so
mike wrote:
> Do you mean a json_parse in javascript (like a better eval() I assume)?
> Thats what we were doing. Json is not supposed to be pure javascript
> either, but a serialized representation of variables like php's
> serialize(). So I would not expect a json string to be usable without
> us
On Sun, Dec 14, 2008 at 12:39 AM, Rasmus Lerdorf wrote:
> Eh? Read what you wrote there. If json wasn't pure javascript, how in
> the world would eval() work on it?
Sorry. I guess I meant it didn't execute by itself, but needed to be
interpreted using something like eval and/or thrown into a v
mike wrote:
> On Sun, Dec 14, 2008 at 12:39 AM, Rasmus Lerdorf wrote:
>
>> Eh? Read what you wrote there. If json wasn't pure javascript, how in
>> the world would eval() work on it?
>
> Sorry. I guess I meant it didn't execute by itself, but needed to be
> interpreted using something like eva
>
> var foo = ;
>
>
> will always work. The only question is what sort of variable foo will
> end up being. The RFC says we have to wrap basic types in an array or
> object, while currently we let the basic types through without the
> wrapper.
He problem her eis:
Le dimanche 14 décembre 2008 à 00:39 -0800, Rasmus Lerdorf a écrit :
>
> var foo = ;
>
>
> will always work. The only question is what sort of variable foo will
> end up being. The RFC says we have to wrap basic types in an array or
> object, while currently we le
Původní zpráva
Předmět: [PHP-DEV] Removing basic types from our JSON parser
Od: theta...@php.net (Uwe Schindler)
Komu:
Datum: 14.12.2008 10:40
var foo = <?php echo json_encode($foo)?>;
will always work. The only question is what sort of variable foo will
end up being
19 matches
Mail list logo
