Achtung bei Bankdaten-Aktualisierung: Bundesbank hat Zeichenkodierung geändert

[vr]

Hallo,

bei der Bankdaten-Aktualisierung (Adminbereich) mit den BLZ-Daten der Bundesbank ist mir heute aufgefallen, dass die die Zeichenkodierung der txt-Dateien von Latin auf UTF-8 umgestellt haben.

update 11.08.2019 -----------------------
Diese Umstellung wurde zwischenzeitlich zurückgenommen, die txt-Dateien sind wie früher wieder Latin-kodiert. Wer meine vorgeschlagenen Änderungen übernommen hatte, bitte zurückbauen, sonst fehlen BLZ in der DB. Mit der 2019-Juni-Sep-Datei und mb_substr bekommt man bspw nur 3386 statt 3550 BLZ.
ende update 11.08.2019 ------------------

Das hat den Effekt, dass ca 1/3 aller Sätze nicht importiert werden, gut 1000 weniger als bisher! Das wiederum führt dazu, dass im SEPA-Modul viele IBANs fälschlicherweise abgelehnt werden, aber längst nicht alle, deshalb bemerkt man das zunächst nicht. Es müssen aktuell nach dem Import der txt-Datei vom 4.3.2019 3549 Sätze da sein, wenn ihr eine 2000er Zahl angezeigt bekommt, habt ihr nicht alle. Alle Shopversionen sind betroffen.

Grund: Die txt-Datei der Bundesbank ist eine Festformat-Datei, Daten werden aus den Zeilen über Zeichenpositionen in einer Zeile extrahiert. Die admin/blz_update.php verwendet dafür die Funktion substr, und die geht davon aus, dass eine Position ein Zeichen bedeutet. Was bei UTF-8 nicht immer so ist, Umlaute bspw sind 2 oder mehr Zeichen breit. Entsprechend verschieben sich die Positionen in vielen Zeilen, und dort greift insbesondere die Ermittlung des Übernahmekennzeichens am Ende einer Zeile, Position 158, daneben und bekommt statt D, U, A oder M eine Zahl. Es werden aber nur Sätze mit U, A, oder M übernommen.

Kurzfristige Abhilfe, bis es einen offiziellen Patch gibt:
Sucht die Vorkommen von substr in admin/blz_update.php und ersetzt sie durch mb_substr, ca Zeile 106 bis 110. Bei der Ersetzung von substr durch mb_substr muss außerdem bei jedem mb_substr hinten ein vierter Parameter 'UTF-8' rein. Dh bspw, aus

vorher so

Code: PHP  [Auswählen]

$blz['blz'] = substr($line, 0, 8);

wird

Code: PHP  [Auswählen]

$blz['blz'] = mb_substr($line, 0, 8, 'UTF-8');

Damit werden zumindest wieder alle Banken importiert.

bankname braucht besondere Aufmerksamkeit, damit er nicht mit kaputten Umlauten in der Datenbank landet. Die Änderung ist abhängig davon, wie alt euer shop ist (hat er decode_utf8 in inc/html_encoding.php) und welche Zeichenkodierung eure DB verwendet:

Neuere shops mit decode_utf8
bisher:

Code: PHP  [Auswählen]

$blz['bankname'] = encode_utf8(trim(substr($line, 9, 58)), 'ISO-8859-15'); //bank name(58)

neu:

Code: PHP  [Auswählen]

$blz['bankname'] = decode_utf8(trim(mb_substr($line, 9, 58, 'UTF-8')));

Ältere shops ohne decode_utf8
bisher

Code: PHP  [Auswählen]

$blz['bankname'] = trim(substr($line, 9, 58)); //bank name(58)

neu, shop in Latin:

Code: PHP  [Auswählen]

$blz['bankname'] = mb_convert_encoding(trim(mb_substr($line, 9, 58, 'UTF-8')), 'ISO-8859-1', 'UTF-8');

neu, shop in UTF-8:

Code: PHP  [Auswählen]

$blz['bankname'] = trim(mb_substr($line, 9, 58, 'UTF-8'));

Falls ihr die Bankdaten bereits aktualisiert hattet, baut um und importiert erneut, ihr könnt gefahrlos so oft
importieren, wie ihr wollt.

Grüße, Volker

Linkback: https://www.modified-shop.org/forum/index.php?topic=40086.0

[noRiddle (revilonetz)]

Vorab:
Vielen Dank für die Information und die Arbeit.

Vielleicht verstehe ich etwas nicht, aber ich frage mich ob die Unterscheidung der Kodierung des Shops nötig ist.
In der Funktion encode_utf8() (/inc/html_encoding.php) ist doch bereits alles abgefangen, sodaß es ausreichen sollte diese Zeile

Code: PHP  [Auswählen]

$blz['bankname'] = encode_utf8(trim(substr($line, 9, 58)), 'ISO-8859-15'); //bank name(58)

mit dieser zu ersetzen (unter Nutzung des vierten Parameters in mb_substr())

Code: PHP  [Auswählen]

$blz['bankname'] = encode_utf8(trim(mb_substr($line, 9, 58, 'UTF-8')), 'UTF-8'); //bank name(58)

(Die Kodierung des Files dann noch im Backend einstellbar machen und es ist perfekt.)

Korrekt ?

Gruß,
noRiddle

[vr]

Hallo noRiddle,

die encode_utf8 ist eine relativ neue Funktion in inc/html_encoding.php und in älteren shops nicht verfügbar. Außerdem kodiert sie entweder nach UTF-8 oder lässt den Input so wie er ist. Im konkreten Fall brauchen wir aber das umgekehrte Verhalten, kodiere UTF-8 nach Zeichenkodierung der DB, falls nötig. Neuere Shops können dafür die Funktion decode_utf8 nutzen:

Code: PHP  [Auswählen]

$blz['bankname'] = decode_utf8(trim(mb_substr($line, 9, 58))); // bank name(58)

Grüße, Volker

[noRiddle (revilonetz)]

Ah, richtig, Code verkehrt gelesen. Die Funktion decode_utf8() ist die richtige, die halt nur dann greift, wenn der Shop nicht auf UTF-8 läuft.
Mich störte die Unflexibilität, aber für ältere Shops wohl unumgänglich.

Trotzdem habe ich Zweifel an deiner Version für "Shop läuft auf ISO-8859-15".
Müsste das mb_convert_encoding() nicht zuerst auf den geamten String ausgeführt werden bevor mb_substr() angewendet wird ?
und letztes außerdem mit dem Parameter für Encoding, also ISO-8859-15 bzw. $_SESSION['language_charset'], weil man ansonsten, je nach PHP-Version, Gefahr läuft daß das Internal Encoding UTF-8 ist ?

Gruß,
noRiddle

[vr]

Trotzdem habe ich Zweifel an deiner Version für "Shop läuft auf ISO-8859-15".
Müsste das mb_convert_encoding() nicht zuerst auf den geamten String ausgeführt werden bevor mb_substr() angewendet wird ?
und letztes außerdem mit dem Parameter für Encoding, also ISO-8859-15 bzw. $_SESSION['language_charset'], weil man ansonsten, je nach PHP-Version, Gefahr läuft daß das Internal Encoding UTF-8 ist ?

1. Nee, wir müssen ja in den UTF-8 shops gar nicht konvertieren.
2. Richtig, den Fall abweichendes Internal Encoding sollte man abdichten.

Hab das erste Posting mit der Umbauanleitung entsprechend aktualisiert.

Grüße, Volker

[Adam]

Danke für den Hinweis! Soeben die Codes angepasst. Bei mir sind es mit dem aktuellen Link 3386/16232 Datensätze, hoffentlich so korrekt.
Edit: Kann es sein, dass die Codierung wieder umgestellt wurde?
Nach der Anpassung der .php Datei wie oben empfohlen, habe ich die BLZ geupdatet und in der Datenbank wurden Umlaute nicht korrekt gespeichert.

Ich habe die o.g. Änderungen wieder rückgängig gemacht und nochmal die BLZ geupdatet, ich erhalte 3550/16232 Datensätze und Umlaute sind korrekt in der Datenbank gespeichert.

Die aktuelle BLZ .txt runtergeladen und Debian sagt mir mit file blz-aktuell-txt-data.txt:
blz-aktuell-txt-data.txt: ISO-8859 text, with CRLF line terminators
Also doch nicht mehr UTF-8?

[vr]

Hallo Adam,

Kann es sein, dass die Codierung wieder umgestellt wurde?
Also doch nicht mehr UTF-8?

danke, so ist es, kann alle Deine Ergebnisse bestätigen. Damit hat sich dieses Thema erledigt. Das erste Posting ist entsprechend geändert.

Grüße, Volker