In general give what version you used ? CVS head ? 2.6.26 ? ...
On Mon, Oct 23, 2006 at 11:22:43AM +0200, Murray Cumming wrote:
> The xmlSaveFormatFileEnc function accepts a NULL for the encoding,
> though the documentation doesn't say what that would mean:
> http://xmlsoft.planetmirror.com/html/libxml-tree.html#xmlSaveFormatFileEnc
It means falling back to xmlSaveFormatFile() behaviour. I.e. the
encoding embedded in the document if any.
> int xmlSaveFormatFileEnc (const char * filename,
> xmlDocPtr cur,
> const char * encoding,
> int format)
>
> It does seem to default to UTF-8 encoding when NULL is used,
Not necessarilly, see before
> but NULL also means that the encoding declaration will not be written
> at the start of the XML file.
Wrong, if the document has an encoding embedded (inherited for example
from parsing) it will be advertized, and document will be saved accordingly.
> Is that ever a good thing?
If UTF-8 or UTF-16 it doesn't matter, see appendix F of the spec
http://www.w3.org/TR/REC-xml/#sec-guessing
Also note that external encoding informations (e.g. from ContentType
HTTP headers) override the XML Declaration encoding if there is one.
> It seems like a bug.
not necessarilly, no
> Would it break
> anything to make it always write the encoding declaration?
It would break people relying on no encoding being generated, like people
whol may use a post processing either for encoding or when embbeding the
XML serialization in something else.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml
