JSON specification WAS: Re: JSON Duplicate Keys

gaz Heyes gazheyes at gmail.com
Thu Jun 6 06:43:08 PDT 2013


On 6 June 2013 14:25, Jeremy Darling <jeremy.darling at gmail.com> wrote:

> Thinking about this for JSON that means that if you were wanting to
> serialize a complete object (prototype, setters, getters, etc) you would
> then have to escape all of those as well.  Since JavaScript doesn't really
> have a standard symbol for stating "This is a control key" then dev's would
> have to code for all possible key words in their escape/unescape sequence.
>
> Or the spec would have to be amended to contain some type of
> "isReservedKey" statement.  This just introduces a whole new can of worms
> and more breaking points.
>

Yeah I agree it's a can of worms but I wanted to throw it out there for
discussion. As we get more keywords and functionality it could bite in the
butt in a few years time.

I don't exactly understand your point in bullet 2?  Why do < and > have to
> be encoded, they are perfectly valid values inside of a string today, and
> again many libraries make use of this functionality for transporting HTML,
> XML, and Text fragments.  To Crockfords point, "should not break" becomes
> the issue with changing what should and should not be encoded.
>

 For two reasons 1) Some browsers will render json as html (sniffing) 2)
Inline JSON data will be parsed in a different order than it's intended.
For example < will be parsed first as html and then javascript. Encoding <
and > will have no effect on passing xml/html data but will prevent those
issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130606/df2e2c36/attachment.html>


More information about the es-discuss mailing list