Kontoinhaber mit Sonderzeichen UTF-8 codiert

[mwalliczek]

Hallo,

seit ein paar Tagen beobachte ich, dass per Consorsbank einzelne Kontoinhaber als Gegenpartei bei Lastschriften o.ä. UTF-8 codiert ankommen, also im Object GVRKUms.UmsLine.other.name und name2 UTF-8 Kodierungen enthalten sind, die allerdings im Java String als ISO-8859-1 erfasst sind, und so die enthaltenen Umlaute entsprechend falsch dargestellt werden, also "ö" statt "ö".

Bisher hatte ich generell bei HBCI noch keinerlei Umlaute beobachtet, ist das jetzt erlaubt?

An welcher Stelle müsste man das innerhalb des hbci-Moduls ändern?

[willuhn]

Bevor im Code etwas geändert wird, sollte erstmal geprüft werden, ob UTF8 überhaupt zulässig ist: https://www.hbci-zka.de/spec/3_0.htm

[mwalliczek]

Spannend... In der Spec taucht überall nur ISO-8859-1 auf - außer in den XML-Headern aus den Beispielen, da wird überall UTF-8 verwendet. In ihrer App zeigt die Consorsbank das auch richtig an. Und offenbar hat auch das absendende Institut das mit UTF-8 kodiert und der Transport der Institute untereinander läuft dann wohl auch per UTF-8...

[willuhn]

Das Problem ist: Wenn du das auf UTF-8 änderst, sind danach die Umlaute bei allen anderen Banken kaputt.

[mwalliczek]

Man müsste man schauen, ob die Bank den Zeichensatz speziell mitteilt - wo sollte ich da am besten einen Breakpoint setzen?

[willuhn]

Es gibt kein Feld, in dem die Bank das mitteilt. FinTS schreibt ISO8859 vor und im Header einer XML-Datei steht meist UTF8 - auch wenn die Bank es ISO8859 codiert hat. Alle mir bekannten Banken senden ISO8859 und mir ist keine Stelle bekannt, an der man sich auf eine explizite abweichende Encoding-Angabe verlassen kann.

[OlliL]

Es gibt Bibliotheken die können (so gut es eben möglich ist) den vermeintlich gewünschten Charset erkennen. Z.B https://github.com/albfernandez/juniversalchardet

final byte[] rawFileContents = .....
final UniversalDetector detector = new UniversalDetector(null);
detector.handleData(rawFileContents, 0, rawFileContents.length);
detector.dataEnd();
String encoding = detector.getDetectedCharset();
detector.reset();
if (encoding == null) {
	encoding = "UTF-8"; // oder was auch immer als fallback
}
final String stringFileContents = new String(rawFileContents, encoding);

Ob man sowas nun nutzen will steht auf nem anderen Blatt....

[willuhn]

Dann hätten wir - nur dafür - eine Abhängigkeit zu einer externen Bibliothek. Ich finde es gut, dass HBCI4Java bisher komplett ohne externe Abhängigkeiten auskommt. Ich würde eine Bibliothek nur einbinden, wenn es wirklich nötig ist.

Ich hatte zwischenzeitlich aber mal ein vergleichbares Thema und habe es wie folgt gelöst:

Ich habe die Bytes des Textes genommen und damit einmal einen String mit ISO-8859-15 Encoding erzeugt und einmal mit UTF-8. Danach habe ich beide Strings verglichen. Wenn sie identisch sind, enthielt er keine Umlaute und es ist egal, welchen man verwendet. Wenn sie sich aber unterscheiden, habe ich geprüft, welcher von beiden mindestens eines der Zeichen "üöäÜÖÄß" enthält. Das muss dann die Variante sein, bei der das Encoding korrekt ist. Sowas könnte man auch einfach in HBCI4Java irgendwo in einer Util-Klasse als statische Methode kapseln. A la "public static String fixEncoding(String)" oder ähnlich.