GNOME Bugzilla – Bug 147717
Character encoding saved data depends on the locale
Last modified: 2018-06-29 20:45:21 UTC
The same data are saved differently in the file if entered using different locales. The display is also bad. I set my locale like this: LANG=POSIX LC_CTYPE=en_US.UTF-8 LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= then start gnucash, type in a register description or memo field some accented characters, save the file. For example, I have entered "bevásárlás 95,85?" then I can unset LC_CTYPE (or set it to hu_HU.utf8, the same thing happens), start gnucash, the previous entry is displayed like this: "bev??s??rl??s (95,85â ?)". I enter the same text as above (except that I cannot type the Euro sign), save the file. This is in the file: <trn:description>bevásárlás (95,85Eur)</trn:description> <trn:splits> <trn:split> <split:id type="guid">6d89152f4b64c794d02a4fd7cdade468</split:id> <split:memo>bevásárlás (95,85€)</split:memo> The problem here is that I have entered the same text, and I expect to see the same text in the file regardless of my locale settings, which should only affect the display of this text on screen. Instead I have a file, with two strings and the two strings cannot be read at the same time. I think that instead of á and á gnucash should save á or it should stick to one codepage ex. converting everything to utf8.
This isn't an XML issue, it's actually a gnome/register issue. I've changed the component, because the SQL backend would fail in the same way.
Actually I think this is quite well an XML or rather a backend issue, because right now we don't have any notion of the "character encoding of the given backend". The backend itself should store the information about which encoding has been used for a given book. Right now that's not the case, which results in precisely the reported error: The character encoding of the saved XML file depends on the locale, because implicitly it is assumed that the book is encoded in the current locale's encoding. Of course this will break down as soon as you happen to change your locale. This needs to be fixed by adding a property "character encoding" to the gnc-book. The gnome/register issue is rather a question of correctly convert from the backend's encoding to the gnucash internal encoding to the gnome display encoding. But the original problem is orthogonal to the display encoding and needs to be solved nevertheless.
Note: Development on 1.8.x has stopped, so we won't fix anything there. However this issue *is* still a problem in the upgrading to 1.9.x/2.0, which is discussed in that other bugreport. In 1.9.x/2.0, this problem is already fixed. *** This bug has been marked as a duplicate of 329202 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=147717. Please update any external references or bookmarks.