Re: jsonb, unicode escapes and escaped backslashes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb, unicode escapes and escaped backslashes
Date: 2015-02-01 01:25:03
Message-ID: 29369.1422753903@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I understand Andrew to be saying that if you take a 6-character string
> and convert it to a JSON string and then back to text, you will
> *usually* get back the same 6 characters you started with ... unless
> the first character was \, the second u, and the remainder hexadecimal
> digits. Then you'll get back a one-character string or an error
> instead. It's not hard to imagine that leading to surprising
> behavior, or even security vulnerabilities in applications that aren't
> expecting such a translation to happen under them.

That *was* the case, with the now-reverted patch that changed the escaping
rules. It's not anymore:

regression=# select to_json('\u1234'::text);
to_json
-----------
"\\u1234"
(1 row)

When you convert that back to text, you'll get \u1234, no more and no
less. For example:

regression=# select array_to_json(array['\u1234'::text]);
array_to_json
---------------
["\\u1234"]
(1 row)

regression=# select array_to_json(array['\u1234'::text])->0;
?column?
-----------
"\\u1234"
(1 row)

regression=# select array_to_json(array['\u1234'::text])->>0;
?column?
----------
\u1234
(1 row)

Now, if you put in '"\u1234"'::jsonb and extract that string as text,
you get some Unicode character or other. But I'd say that a JSON user
who is surprised by that doesn't understand JSON, and definitely that they
hadn't read more than about one paragraph of our description of the JSON
types.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2015-02-01 02:43:04 Re: Draft release notes up for review
Previous Message Noah Misch 2015-02-01 01:19:26 Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.)