Gnucash and utf-8 : summary

Didier Vidal didier-devel at
Sun Sep 25 13:08:42 EDT 2005

First, I apologize for an error I made in parent email. The libxml
version I tested that fixed the problem is 2.6.22. It didn't require any
change in the gnucash code (ie: still using xmlNodeDump)

The actual bug report in libxml is

Daniel Veillard considers the fix 'risky business' that 'may be changed
again'. I think his previous behavior was buggy anyway, because he
didn't escape utf-8 chars, but ISO-8859-1 chars, at least from what I
observed on my fedora.

Didier Vidal.

Le dim 25/09/2005 à 18:51, Neil Williams a écrit :
> On Sunday 25 September 2005 4:40 pm, Didier Vidal wrote:
> > gnucash looks fine with utf-8. Neil's suggestion to write the encoding
> > in write_v2_header in io-gncxml-v2.c makes a lot of sense.
> (I wish my other code problems were so easy to solve!)
> > The error I observed ("é" written with an ISO-8859-1 encoding) was due
> > to a bug in libxml. I had libxml 2.6.16 on my machine.
> I'm not so sure that it was confirmed as a bug. The question about whether it 
> should be filed as a bug was not answered in the archive. It was more that 
> the API changed and new calls created to provide the level of control the 
> enquirer wanted over the encoding. That is a risk with all libraries. As I 
> read it, using the new function did solve the problem. It may not have been 
> good to change an existing function behaviour but there was a hint that the 
> problem arose from engaging with the API at too low a level.
> > > Except for the fact that FC3 ships 2.6.16...  But yes, definitely a 
> > > good thing.
> > > :)
> > Even with 2.6.16 of libxml, there is no *visible* problem as long as you
> > keep opening your file with libxml.
> With the encoding specified in future XML, even this theoretical problem 
> should disappear, including on FC3. (Which is why the standard exists, after 
> all.)
> > I downloaded libxml 2.6.20 and the bug disappeared. The fix might be
> > related to this email
> >
> As I read that, it relates to outputbuffers that GnuCash never used - at least 
> not directly.
> > So, there is no encoding problem.
> But there is a net benefit. Thanks for highlighting this - it's something I'd 
> missed and now there is a fix on it's way. Good news all round.

More information about the gnucash-devel mailing list