Re: [xml] xmlSaveFormatFileEnc() doesn't always write encoding declaration.

[Daniel Veillard <veillard redhat com>]

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/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/