Re: xml type and encodings
От | Florian G. Pflug |
---|---|
Тема | Re: xml type and encodings |
Дата | |
Msg-id | 45AD0E64.2050301@phlo.org обсуждение исходный текст |
Ответ на | Re: xml type and encodings (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: xml type and encodings
|
Список | pgsql-hackers |
Peter Eisentraut wrote: > I wrote: >> We need to decide on how to handle encoding information embedded in >> xml data that is passed through the client/server encoding >> conversion. > > Tangentially related, I'm currently experimenting with a setup that > stores all xml data in UTF-8 on the server, converting it back to the > server encoding on output. This doesn't do anything to solve the > problem above, but it makes the internal processing much simpler, since > all of libxml uses UTF-8 internally anyway. Is anyone opposed to that > setup on principle? If you do that, maybe it would be the easiest and least confusing thing to just _always_ represent an xml document in utf-8, ignoring the client_encoding entirely for xml. The only good reason for not using utf-8 that comes to my mind is the increased storage size, especially for eastern scripts where nearly all characters need 2 or more bytes. But if you store it in utf-8 internally anyway, than I don't think this arguments carries a lot of weight anymore... You could warn the user about that fact whenever he sends or recieves an xml document, and the client_encoding is not set to utf-8. Not that I'm entirely conviced about this being a good idea myself - but I think I'd prefer a clear rule like that over surprises like "text and binary output have different semantics" or "the encoding information is totally misleading and must be ignored". And most software that uses xml probably uses utf-8... greetings, Florian Pflug
В списке pgsql-hackers по дате отправления: