Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON

Поиск
Список
Период
Сортировка
От Joey Adams
Тема Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON
Дата
Msg-id CAARyMpAcC7O99Nk4BGHQqMgLVi7vNTGD9Ff4tHbPVQA2MrHpqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON  (Florian Pflug <fgp@phlo.org>)
Ответы Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON
Список pgsql-hackers
On Wed, Jul 20, 2011 at 6:49 AM, Florian Pflug <fgp@phlo.org> wrote:
> Hm, I agree that we need to handle \uXXXX escapes in JSON input.
> We won't ever produce them during output though, right?

We could, to prevent transcoding errors if the client encoding is
different than the server encoding (and neither is SQL_ASCII, nor is
the client encoding UTF8).  For example, if the database encoding is
UTF-8 and the client encoding is WIN1252, I'd think it would be a good
idea to escape non-ASCII characters.

> How does that XML type handle the situation? It seems that it'd have
> the same problem with unicode entity references "&#XXXX;".

From the looks of it, XML operations convert the text to UTF-8 before
passing it to libxml.  The XML type does not normalize the input;
SELECT '♫♫'::xml; simply yields ♫♫.  Escapes of any
character are allowed in any encoding, from the looks of it.

- Joey


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [v9.1] sepgsql - userspace access vector cache
Следующее
От: Kohei Kaigai
Дата:
Сообщение: Re: [v9.1] sepgsql - userspace access vector cache