Re: 'Re: [xml] "Control over encoding declaration (prolog and meta)'
- From: Daniel Veillard <veillard redhat com>
- To: Kasimier Buchcik <kbuchcik 4commerce de>
- Cc: xml gnome org
- Subject: Re: 'Re: [xml] "Control over encoding declaration (prolog and meta)'
- Date: Thu, 15 Jan 2004 05:52:29 -0500
On Thu, Jan 15, 2004 at 10:34:05AM +0100, Kasimier Buchcik wrote:
Would this approach be thread-save? I would expect this procedure to
temporarily change the encoding handler for e.g. ISO-8859-1 to UTF-16LE,
but if I'm serializing an other document to ISO-8859-1 at the same time,
I would get false results. Or is the registration of encoding handlers
somehow implemented per-thread like?
No it's global.
Lying about encodings is bad. I don't know why you want to do this,
but I don't want to start making specialized APIs for this reason.
Encodings are registered globally, I think it's a sound decision, it's
a framework capacity and an API that I expect to be used once at startup.
If you have a completely broken requirement, fork, do the unclean stuff
in the forked process and be done with it. If there is a speed penalty,
then that will give people an incentive to fix the receiving side. Sorry
this is not a valuable reason to add even more confusing APIs, increase
libxml2 code and overall complexity.
XHTML is XML, the tools MUST parse it following the XML rules which are
cristal clear, if your instance says "ISO-8859-1" and is encoded in
"UTF-16LE" then it's a well formedness error, unless you get something
like an HTTP header telling what the real encoding is (and I personally
consider this a terrible bad kludge, but that's how it is).
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]