Hallo zusammen,
zunächst der Hinweis, dass ich im Forum neu bin und hoffe an der richtigen Stelle gelandet zu sein; ansonsten bitte ich um einen entsprechenden freundlichen Hinweis - Danke.
Ich bin von StarMoney Business auf Hibiscus umgestiegen und habe nun ein Problem beim Import von DTAUS-Dateien. Aktuell habe ich zunächst die DTAUS online geteset mit dem Ergebnis, dass diese in Ordnung ist. Zuvor hatte ich noch die Gültigkeit der enthaltenen Zeichen geklärt.
Beim Import in Hibiscus erhalte ich jedoch die Fehlermeldung: Ungültiges Zeichen: e(0x65) an Position 156.
Was ist zu tun?

Die Position 156 ist die viertletzte Stelle der Kontonummer im ersten C-Satz.
Da darf kein kleines a stehen, das Feld ist rein nummerisch.
Bist du wirklich 100 % sicher, dass diese Datei in Ordnung ist? Falls ja, gibt es Beweise?

Ich habe das Ganze Heute nochmals getestet; es bleibt bei der Fehlermeldung ( es ist in der Zeile auch kein entsprechendes Zeichen vorhanden ) und die Datei ist definitiv fehlerfrei lt. Online-Überprüfung.
Leider kenne ich mich mit Foren noch nicht so gut aus und weiß nicht, wie ich den Snapshot dieser Online-Überprüfung und/oder der Fehlermeldung hier hinein bekomme. kann ich das irgendwie per EMail zusenden?

Nachtrag: Das hat dann ja wohl mit den Anhängen doch geklappt; ich hoffe das hilft für die Lösung weiter!

Dann schlage ich vor, du schickst die DTAUS Datei an Stefan http://hbci4java.kapott.org/index.html#kontakt und nimmst auf diesen Thread hier Bezug.
Wobei das wirklich erschreckend wäre, wenn da ein Fehler drin wäre. Das Produkt ist ja nicht erst seit gestern auf dem Markt.
Bist du sicher, dass du die selben Dateien verwendest?

Da bin ich mir sicher! Ich arbeite beruflich seit langer Zeit mit dem OnlineBanking und bisher hat der Import in StarMoney Business mit diesen Dateien auch problemlos geklappt. Nur eben mit Hibiscus gibt es da noch Probleme. Aber die sind ja dazu da um gelöst zu werden. Vielen Dank bis hierhin - ich werde die Datei an Stefan schicken.

Stefan ist hier der falsche Ansprech-Partner. Der DTAUS-Parser stammt aus dem "obantoo"-Projekt von Heiner (der auch der Autor von JVerein ist). http://obantoo.berlios.de/

Hab grad mal etwas im Source gestoebert. Kann es sein, dass in dem geschwaerzten Teil von http://www.onlinebanking-forum…hp?id=1017 ein "e" mit Akzent (wie in Andr´e) enthalten ist?

Ich seh naemlich grad, dass in Hibiscus zwar die (gemaess http://obantoo.berlios.de/changelog.shtml) aktuelle Version 1.4.11 vom 09.07.2008 enthalten ist (plugins/hibiscus/lib/obantoo-bin-1.4.11.jar). Im CVS aber am 04.06.2009 nochmal was geaendert wurde und vermutlich exakt das betreffen koennte:

http://cvs.berlios.de/cgi-bin/…f_format=h

In der Diff-Ansicht werden die "e" mit Akzent zwar leider nicht korrekt angezeigt. In meiner IDE seh ich aber, dass es sich um diese franzoesischen Laute handelt.

Vielleicht koenntest du Heiner ja bitten, eine aktualisierte Version 1.4.12 (bzw. 1.5.0 - so steht es zumindest schon im CVS) von obantoo zu veroeffentlichen, in der die inzwischen im CVS angefallenen Aenderungen mit enthalten sind. Denn meiner Meinung nach ist der Fehler bereits seit laengerer Zeit behoben - hatte nur noch nicht den Weg in Hibiscus gefunden.

Ich aktualisiere derweil mal Hibiscus mit einer aktuellen selbst-compilierten Version von obantoo 1.5.0 - ist ab morgen im Nightly-Build. Siehe http://www.willuhn.de/wiki/dok…lds_nutzen

Update: Die 3 Zeilen mit der Ersetzung der "e" mit Akzent ist da nicht hinzugekommen sondern entfernt worden. Stattdessen geschieht das jetzt in "Tr.normalizeUTF8". Und dort sind auch noch eine ganze Reihe weiterer Sonderlaute- und Zeichen enthalten, die entsprechend ersetzt werden.

Aktualisierte Obantoo-Version 1.5.0 ist eingecheckt und ab morgen im Nightly-Build. Mit der sollte es dann gehen.

Unabhaengig davon: Sollte das mit dem franzoesischen "e" (oder einem anderen Sonder-Laut) tatsaechlich die Ursache gewesen sein, waere das streng genommen KEIN Fehler von Obantoo. Gemaess http://de.wikipedia.org/wiki/D…ge_Zeichen sind solche Zeichen im DTAUS-Standard gar nicht zulaessig. Viele Anwendungen tolerieren diese Zeichensatz-Verstoesse es aber scheinbar trotzdem.

Dieses "ungültige" Zeichen ist es gerade, dass mich selber stutzig macht, denn es ist überhaupt nicht enthalten. Die von mir unkenntlich gemachten Zeichen enthalten entweder nur Zahlen oder den Text aus dem Verwendungszweck Zeile 1 ( nur zugelassene Zeichen ) und dann den Auftraggeber.
Ich hatte zu Testzwecken Gestern auch bereits versucht, den Fehler näher einzugrenzen, indem ich die DTAUS im Editor geändert hatte, damit auf keinen Fall irgendwelche Sonderzeichen oder ähnliches enthalten waren; das hatte leider keine Auswirkungen. Anschließend habe ich die Überweisungsdaten selber nochmals geändert und die DTAUS neu erstellt; auch kein Erfolg. Es blieb bei der Fehlermeldung, ohne dass ich das ungültige Zeichen lokalisieren konnte. Damit waren dann leider meine Möglichkeiten erschöpft.
Ich habe die betreffende ursprüngliche DTAUS-Datei inzwischen an Heiner gesendet, damit er sich dies ansehen kann. Die "Interna" gehen hier leider über mein Verständnisvermögen hinaus - sorry.

Und wieso Position 156? Das ist quasi mitten in der Kontonummer. Warum ist diese Angabe denn auch falsch? Da stimmt doch was grundsätzliches nicht.

Die Offset-Angabe (also Pos. 156) bezieht sich bei Obantoo auf das aktuell zu parsende Segment. Da ich den kompletten Stacktrace der Fehlermeldung jetzt nicht kenne, weiss ich nicht, auf was sich die Pos. 156 im konkreten Fall bezieht. Es muss also nicht zwingend mitten in der Kontonummer sein.

OK, also mal wieder eine der Fehlermeldungen, mit denen der Nutzer rein garnichts anfangen kann.
Warum einfach, wenn es auch anders geht :evil:

@Mat Birdy:mit welchem Editor hast Du die Datei abgespeichert ? Dadurch kann es sein, dass Du Dir Zeilenumbrüche eingehandelt hast. Solche darf die DTAUS-Datei nicht enthalten.

Das DTAUS-Format ist so absurd haesslich und IMHO hoffnungslos veraltet (es stammt immerhin aus Zeiten, als Daten noch auf Magnet-Baendern(!) uebertragen wurden), dass ein normalsterblicher User ohnehin nichts sinnvolles drin erkennen kann, wenn er sie in einem Texteditor oeffnet. Welchen Sinn haette dann hier eine verstaendlichere Fehlermeldung? Mit der kann der User auch nichts anfangen. Schliesslich kann er die Datei eh nicht in einem Text-Editor bearbeiten, weil er dabei mit ziemlicher Sicherheit Offsets aendert und damit die ganze Datei erst recht unlesbar wird.

Welcher Editor fügt denn in ein Dokument Zeilenumbrüche ein, wo vorher keine waren?
Dass aus Newline ein Newline+CR wird OK aber doch nicht ganz neu einfügen. So einen Editor hab ich noch nicht gesehen.


Sehe ich anders. Gerade weil das Format so schön, gleichmäßig und alt ist ist es auch hinreichend dokumentiert. Insofern könnte man damit durchaus etwas anfangen. Aber das ist Geschmacksache. Ich bin immer für sprechende Fehlermeldungen, die erstmal dem Nutzer zur Selbsthilfe helfen könnten/sollten. Und erst in zweiter Linie dem Entwickler. Sonst braucht man sich nicht darüber wundern, dass es immer mehr DAU's gibt, die können ja garnicht anders bei solchen Fehlermeldungen.......

Eben weil ich mir bei der Änderung der Daten mit dem Editor ( Windows Editor ) nicht sicher war habe ich die Änderungen dann ja auch noch einmal direkt im Programm ( das ich zur Erstellung der Überweisungen nutze - Hausverwaltung ) geändert und die DTAUS sozusagen frisch noch einmal erstellt. Wie gesagt, ohne Erfolg!

Wie haette denn im konkreten Fall die Fehlermeldung aussehen koennen, damit der Nutzer das Problem haette selbst loesen koennen? Selbst wenn die Meldung verstaendlich rueberbringt, was falsch ist, kann es der Normal-User trotzdem nicht loesen, weil er die Datei in einem Text-Editor nicht sinnvoll bearbeiten kann.

M.E. hätte es gereicht, die korrekte Position anzuzeigen. Und es kommt immer drauf an, wie man "Normal-User" definiert. Dem Fragesteller hier hätte ich schon zugetraut zu erkennen, dass ein merkwürdiges Zeichen drin ist und dies im Editor zu ändern, wenn er die korrekte Position oder den Namen des Feldes gewußt hätte. Denn wieso sollte man mit einem Editor eine DTAUS Datei nicht sinnvoll bearbeiten können? Überschreib-Modus eingeschaltet damit die Satzlänge nicht geändert wird und los. Ob es damit abschließend gelöst gewesen wäre kann ich auch nicht vorhersehen.
Aber eine Chance wäre zumindest da gewesen.

In meinem Bekanntenkreis kenne ich unter den Nicht-Experten keinen, der diese Aufgabe haette loesen koennen.