Home → Online Banking →

Moneydance ignores XML encoding attribute of downloaded OFX

• Edit

grazu

26 Mar, 2021 09:58 AM

When XML-style downloaded OFX specifies UTF-8 as the character encoding, Moneydance should interpret the XML using that encoding.

<?xml version="1.0" encoding="utf-8" ?>

Moneydance, however, parses it as Windows-1252, unless you prepend the old-style "ENCODING:UTF-8" at the top of the XML. Thus,

ENCODING:UTF-8
<?xml version="1.0" encoding="utf-8" ?>

The attached files demonstrate this. Import example.ofx and see that the "Ö" character is not parsed correctly.

Import example.workaround.ofx and the "Ö" character now appears correctly.

As I mentioned elsewhere, this resembles a similar issue GNUCash had.

I'm presently using Version 2021.1 (3034). I don't have time right now to test a newer preview, but I don't see any indication in the list of changes that this has been addressed.

• examples.zip 2.39 KB

1. 1 Posted by Stuart Beesley ... on 26 Mar, 2021 11:16 AM

   

   There is a new encoding option that pops up on imports where you choose the encoding. I have a suspicion this only appears if not a downloaded ofx file.

   (Not support, just a fellow user)

   • Edit

2. 2 Posted by grazu on 26 Mar, 2021 11:21 AM

   

   The XML encoding attribute should be enough. If it says, UTF-8, then Moneydance should treat it as UTF-8. It should not be necessary to prompt the user.

   • Edit

3. 3 Posted by grazu on 06 Apr, 2021 02:26 PM

   

   Would it be possible for someone who actually works for IK to comment on this issue?

   • Edit

4. 4 Posted by grazu on 21 Apr, 2021 08:22 AM

   

   Two weeks later, would it be possible for someone who actually works for IK to comment on this issue?

   • Edit

5. Support Staff 5 Posted by Maddy on 21 Apr, 2021 10:51 AM

   

   Hi Grazu,
   Thank you for contacting Moneydance support.

   Firstly, please accept my sincere apologies for the delay in responding to your query.
   I’m sorry to keep you waiting, but I’d like to run your query past the development team who may be able to provide further information.

   --
   Maddy, Infinite Kind Support

   • Edit

6. Support Staff 6 Posted by Sean Reilly on 21 Apr, 2021 11:15 AM

   

   Hi Grazu,

   I'm also sorry for the lack of response. It turns out that we had only been using the encoding for the SGML-based OFX 1.* messages. To be honest we hardly ever encounter OFX 2 messages so I'm not surprised that this bug has not been noticed until now.

   I've started a fix for this and it should be corrected in the next preview build. Unfortunately there isn't a workaround as the post-header parsing uses the OFX 1 defaults which is falling back to ASCII instead of UTF-8.

   Thanks,
   Sean

   --
   Sean Reilly
   Developer, The Infinite Kind
   https://infinitekind.com

   • Edit

7. 7 Posted by grazu on 21 Apr, 2021 11:27 AM

   

   Thanks, Sean, and Maddy. For what it's worth, the workaround I use at present is simply to paste the ENCODING at the top of the XML.

   I'm glad to hear you're able to fix it, and soon. I look forward to the next preview release!

   • Edit

8. 8 Posted by grazu on 01 May, 2021 05:07 PM

   

   Sean, I just tested build 3066 and it works correctly now. Thanks very much!

   • Edit

9. Support Staff 9 Posted by Maddy on 03 May, 2021 09:16 AM

   

   Thank you for reporting back, Grazu! We are very pleased to hear that.
   I'll close this discussion for now, but do not hesitate to contact us again, if you need further assistance.

   --
   Maddy, Infinite Kind Support

   • Edit

10. Maddy closed this discussion on 03 May, 2021 09:16 AM.