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
