After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 639647 - OFX import does not import UTF-8 nicely.
OFX import does not import UTF-8 nicely.
Status: RESOLVED DUPLICATE of bug 627773
Product: GnuCash
Classification: Other
Component: Import - OFX
2.2.9
Other Linux
: Normal normal
: ---
Assigned To: Benoit Grégoire
Benoit Grégoire
: 629856 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-01-16 05:31 UTC by Ian Lewis
Modified: 2018-06-29 22:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example UTF-8 encoded ofx file (2.86 KB, application/octet-stream)
2011-10-09 15:48 UTC, Ian Lewis
Details

Description Ian Lewis 2011-01-16 05:31:54 UTC
When importing an OFX file in non-ascii UTF-8, Gnucash shows garbled text for description fields.

The sample file I have includes a CHARSET directive which could be used to determine the file encoding (not ideal but what can you do?). For reference, the file is intended for Microsoft Money and was downloaded from Mitsubishi UFJ Bank in Japan.
Comment 1 Christian Stimming 2011-01-17 09:07:00 UTC
*** Bug 629856 has been marked as a duplicate of this bug. ***
Comment 2 Ian Lewis 2011-01-18 00:20:57 UTC
As the other bug states that there is a normal xml header in his document, there may be several, semi-standard hints as to the encoding of the document. In my case the CHARSET tag, but an xml header may also be present?
Comment 3 Ian Lewis 2011-10-09 15:48:30 UTC
Created attachment 198655 [details]
Example UTF-8 encoded ofx file
Comment 4 Ian Lewis 2011-10-09 15:52:40 UTC
Looking into this a bit more, it looks like it might be a problem with libofx.

When libofx parses the file I get a lot of errors like the following printed to the console:

(Above message occured on Line 189, Column 7)
LibOFX ERROR: OpenSP parser: otherError (misc parse error):
/tmp/libofxtmpl5P599:189:7:E: non SGML character number 166

(Above message occured on Line 189, Column 8)
LibOFX ERROR: OpenSP parser: otherError (misc parse error):
/tmp/libofxtmpl5P599:189:8:E: non SGML character number 197

(Above message occured on Line 189, Column 9)
LibOFX ERROR: OpenSP parser: otherError (misc parse error):
/tmp/libofxtmpl5P599:189:9:E: non SGML character number 146


This seems to happen when it encounters a Japanese character (non-ascii?). I also checked the data being passed into the transaction callback ofx_proc_transaction_cb(). The name and memo fields are already garbage characters so it doesn't look like Gnucash itself is doing anything to cause the problem.
Comment 5 Ian Lewis 2011-10-23 05:45:35 UTC
It seems that that has been fixed in more recent versions of LibOFX but Ubuntu has the relatively old version 0.9.0 which is why I ran into this bug.

This is fixed and is not a gnucash issue so I'm closing the bug.

*** This bug has been marked as a duplicate of bug 627773 ***
Comment 6 John Ralls 2018-06-29 22:52:06 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=639647. Please update any external references or bookmarks.