Moin, On Sonntag, 15. Juni 2008, Thomas Baumgart wrote: [...] > yyyyy zzzzzzz/zzzzzzzzz - S^M > TETTINER STR. 14 ^M > > Das taucht dann als > > 'xxxxxxxxx, xxxxxx yyyyy zzzzzzz/zzzzzzzzz - S TETTINER STR. > 14 ' > > als Returnwert von GWEN_StringListEntry_Data auf. Die Frage ist jetzt, was > mit den Blanks los ist? Vor dem ^M stehen ja immer die uns allen bekannten > 27 Zeichen aus dem Verwendungszweck. [...]
Das Problem ist hier: Wie soll auf ein Linefeed reagiert werden? In Deinem Fall gehoert offensichtlich das S der ersten Zeile zum ersten Wort der 2. Zeile. Das muss aber nicht immer so sein, es kommt eher noch haeufiger vor, dass beim Linefeed das Wort endet, und in der naechsten Zeile tatsaechlich etwas neues anfaengt. Man sollte hier vielleicht ueberlegen, ob man da nicht irgendwie Filter einfuehrt (auch fuer das Extrahieren des Gegenkontos, was QBankManager ja auch macht). Allerdings waeren solche Filter wieder eher Aufgabe der Anwendung, und nicht unbedingt etwas fuer die Ebene von AqBanking :-/ Ich nehme an, dass die Probleme ueberhaupt erst dadurch entstehen, dass die Bank die Angagen zum Gegenkonte kuenstlich in den Verwendungszweck einbaut. Das macht auch die HaSpa so, und die NetBank. Meine Sparkasse Wilhelmshaven verwendet aber dafuer z.B. vernuenftigerweise die anderen :86:-Tags, die extra fuer diese Angaben definiert wurden. Warum manche Banken immer noch in :86: einfach pauschal ein einzelnes Feld liefert, in das alles hineingewuerfelt wird, ist mir echt schleiderhaft... Das ist auch die Erklaerung, warum es bei der anderen Bank bei Dir korrekt gefiltert wird: Da wird fuer jede Zeile des Verwendungszweckes ein eigenes Tag geliefert (also ?21-?24), mit dieser Information koennen die CRLF ausgefiltert werden, weil in solchen Tags im Prinzip ein Linefeed nicht gewollt sein kann (schliesslich wird ja das Zeilenden explizit durch das Ende des Tags angegeben). Die andere Bank liefert aber als Code im :86: nur "999", was soviel heisst wie "freies Textfeld, unformatiert". Die Bank hat da zwar offensichtlich ihr eigenes Format intern definiert, aber das kann AqBanking nicht wissen. Folglich kann es hier nicht unbedingt die CR/LF ignorieren, denn die koennten hier tatsaechlich das Ende einer Zeile anzeigen... Das Problem ist also der Datensatz von der Bank, und um den fuer Deinen Fall korrekt zu filtern, muesste man halt pro-Bank-Filter haben... Sowas koennte man ja definierten und z.B. einem Konto zuordnen (also quasi: Beim Umsatzabruf fuer Bank X auch Filter X verwenden), aber das sind alles Dinge, die eher in die Anwendung gehoeren :-/ Zumindest ist das in AqBanking nicht so gut transparent einzubauen... Gruss Martin -- "Things are only impossible until they're not" Martin Preuss - http://www.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
