Testing locale change from gnucash 1.8 to gnucash-g2
linux at codehelp.co.uk
Sat Sep 24 16:25:14 EDT 2005
On Saturday 24 September 2005 8:30 pm, Derek Atkins wrote:
> Quoting Neil Williams <linux at codehelp.co.uk>:
> > Not hard - the GnuCash file backend doesn't use libxml2 for this part of
> > the file so it's a one line change in write_v2_header func in
> > src/backend/file/io-gncxml-v2.c. I'll put it into my next commit:
> > - fprintf(out, "<?xml version=\"1.0\"?>\n");
> > + fprintf(out, "<?xml version=\"1.0\" encoding="UTF-8"?>\n");
> > I need to do it in QSF too where it will be done via libxml2.
> Shouldn't this only be done IFF the datafile is actually in UTF-8? I mean,
> if the datafile is still iso-8859-1 wont this cause problems?
libxml2 works internally in UTF-8 and certainly for documents created by QSF
(exports), it was remiss of me not to express the implicit encoding in the
resulting XML. That I do need to fix.
The parser converts all incoming encoding to UTF-8. AFAICT, all existing
GnuCash XML files are going to be UTF-8 because unless you specifically
convert and tell libxml2 the new encoding, it will write out UTF-8. There is
no code I can find in G2 that recognises or stores the original encoding.
The GnuCash XML backend doesn't read or store the incoming encoding, it simply
dumps out the elements as created using sixtp in an XML wrapper that makes no
mention of encoding. This means that libxml2 will simply use UTF-8 no matter
what the original encoding may have been. In effect, we have always just
ridden roughshod over any incoming encoding and written out UTF-8 over the
top of it at the next save. libxml2 has been doing that for us, without
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050924/29f95b67/attachment.bin
More information about the gnucash-devel