[Kmymoney] Re: Text encoding problem with aqbanking ofx

Alexander 'Leo' Bergolth leo at strike.wu.ac.at
Mon Jan 17 11:43:16 CET 2011


On 01/17/2011 07:25 AM, Thomas Baumgart wrote:
> on Sunday 16 January 2011 20:30:31 Alexander 'Leo' Bergolth wrote:
> 
>> I just used the aqofxconnect backend of the aqbanking plugin for the
>> first time.
>>
>> Unfortunately I noticed problems when importing transactions containing
>> 8 bit latin1-characters like umlauts:
>>
>> <MEMO>Abbuchung Einzugsermächtigung
>> becomes:
>> Abbuchung Einzugserm chtigung
>>
>> in kmymoney.
>>
>> I traced the ofx-packets using AQOFX_LOG_COMM=1 and verified that the
>> character encoding on the wire is latin1.
>>
>> My locale settings are LANG=en_US, (i.e. latin1).
>>
>> I couldn't find any way to specify an import-encoding in kmymoney...
> 
> ... because there isn't an option for it. The interface at that point expects 
> UTF-8. Here's the relevant code line:
> 
>       s += QString::fromUtf8(p);
> 
> 's' is the string inside KMyMoney and 'p' points to the data received by AqB.
> 
> It would be handsome to keep the encoding with AqB's OFX settings of the bank 
> and maintain a generic interface between AqB and KMyMoney (as we have it today 
> with UTF-8).

Agreed. That would be great. And most likely it would also solve
encoding problems for other programs using aqbanking. (Like gnucash.)

Actually the client requests encoding and charset in the OFX header of
the request:

ENCODING:USASCII
CHARSET:1252

OFX Spec, Chapter 5.1 Language and Encoding:
--------------------------------------------
Current encoding values are USASCII and UNICODE. For USASCII, character
set values are code pages. UNICODE ignores the character set per se
although it still requires the syntax. Servers must respond with the
encoding and character set requested by the client.

So far I have only seen examples using ENCODING:USASCII and CHARSET:1252.

So if the client always requested this combination, aqbanking would only
need to implement a fixed conversion between CP1252 (which is quite
similar to latin1) and UTF-8.

> Do you see the same problems when using KMyMoney's own OFX implementation?

Unfortunately, since my bank uses a very strict and stubborn parser, I
couldn't get KMyMoneys own implementation work. (I need aqbankings
sendShortDate option, for example.)

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax      ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria



More information about the KMyMoney mailing list