"=" encoded as "\u003d", why?

[One Way]

Why "=" is encoded when converting to json string? How can I undo it?

For example,
gson.toJson(new String[] {"abc="})

I got:
["abc\u003d"]


Thanks.

[inde...@gmail.com]

If this is true, it is a bug that we will fix in our next release.
Can you log it in http://code.google.com/p/google-gson/issues/list

[inde...@gmail.com]

I did more investigation of this and added a few more tests:
http://code.google.com/p/google-gson/source/detail?r=311

= is a special javascript character that must be escaped to unicode in
JSON so that a string literal can be embedded in XHTML without further
escaping.

See JS_ESCAPE_CHARS in
http://code.google.com/p/google-gson/source/browse/trunk/gson/src/main/java/com/google/gson/Escaper.java
for the list of characters that we escape in JSON.

[Ka-Ping Yee]

Hi,

I'm puzzled by this -- I'm having trouble understanding why any of

' < > & =

need to be escaped in a JSON string -- since the string is already in
double-quotation marks, these characters can't affect any surrounding
JSON or JavaScript, right?. Could you explain a bit more about the use
case of embedding in XML that you mentioned? Is there a reason why
Gson's output is intended to work for such a use case without any further
escaping? Why not let those who have such a use case do their own
escaping appropriate to the use case?

On a separate note, I am curious why some whitespace characters are
escaped (e.g. \u2028) but others are not (e.g. \t). If the JSON is
intended just for transmission over the wire, then none of these
characters will be affected; the only characters that ever need to be
escaped are " and \. If the JSON is intended to be handled by editors
or other programs that collapse whitespace, then all whitespace will
need to be escaped. Maybe there is an organizing principle that I'm
missing here?

Perhaps it will help me understand these design choices if you can
describe the set of use cases for which Gson's JSON output is intended.

Thanks!

-- ?!ng

[joel....@gmail.com]

I replied directly to Ka-Ping earlier this week, but I thought I
should extend my response out to a wider audience.

Characters such as <, >, =, etc. are escaped because if the JSON
string evaluated by Gson is embedded in an XHTML page then we do not
know what characters are actually wrapping this JSON string.
Therefore, if there was an open quote, then the embedded JSON followed
by a closing quote then we do not know what will happen. Maybe if the
Gson string contains a abc=123 and there happens to be a "var abc"
defined then the embedded the Gson output in the page may cause the
abc JavaScript variable to be assigned the value 123. The same thing
can happen with < and > or even &.

As for the whitespace escaping, \t is an escaped character for a tab.
Likewise, \n and \r are escape characters for newlines and carriage
returns. Escaping whitespace like this should ensure that any editor
will show the proper whitespace (if the editor properly evaluates
these escaped characters).

Regards,
Joel

On Nov 25, 10:00 am, Ka-Ping Yee <p...@zesty.ca> wrote:
> Hi,
>

> On Tue, 25 Nov 2008, inder...@gmail.com wrote:
> > I did more investigation of this and added a few more tests:
> >http://code.google.com/p/google-gson/source/detail?r=311
>
> > = is a special javascript character that must be escaped to unicode in
> > JSON so that a string literal can be embedded in XHTML without further
> > escaping.
>
> > See JS_ESCAPE_CHARS in

> >http://code.google.com/p/google-gson/source/browse/trunk/gson/src/mai...

[Rami Lara]

Still, JSON encoding must be only JSON encoding, it must not contain encoding for other purposes (XHTML in this case)

In my case (as many others), the receiver expects that field to be a "json" encoded string, and not some-other-encoded-string