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 "XXX;". 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 по дате отправления: