Abbruchmeldung in Zahlungsmodul Sofortüberweisung: Doppelte UTF-8 Kodierung

[BTS]

Shopversion: 2.0.3.0
Modul: sofort_sofortueberweisung_gateway (auch in classic)

In der Abbruchmeldung sind die Umlaute doppelt nach UTF-8 konvertiert, d.h. es erscheinen UTF-8 Hieroglyphen (zwei Zeichen) statt der Umlaute. Die Darstellung der Umlaute bei den Anmerkungen zur Zahlung sind hingegen korrekt.
(Der Shop läuft bei mir fehlerfrei auf UTF-8, es gibt sonst keine Darstellungsfehler bei den Seiten/Produkten, die Seiten haben auch den korrekten "meta charset=utf-8" Header, etc.)

Die Darstellung stimmt wieder, wenn ich in "includes/external/sofort/SofortLibPayment.php" in Funktion "get_error()" die folgende Zeile

Code: PHP  [Auswählen]

'error' => decode_htmlentities(constant('MODULE_PAYMENT_'.strtoupper($this->code).'_TEXT_ERROR_MESSAGE'))

durch

Code: PHP  [Auswählen]

'error' => decode_htmlentities(constant('MODULE_PAYMENT_'.strtoupper($this->code).'_TEXT_ERROR_MESSAGE'),ENT_COMPAT,"ISO-8859-15")

ersetze.
Irgendwo scheint danach noch eine weitere UTF-8 Konvertierung stattzufinden, die das dann wieder richtig (von 8859-15 zu utf8) hinbiegt.

Ich bin mir aber nicht sicher, ob sich das negativ auswirkt, wenn eine nicht-mitteleuropäische Kodierung (griechisch, kyrillisch) zugrunde liegt.

Gruß,
Thorsten

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

[WeXsler]

Der Fehler ist mir auch aufgefallen. Nutze auch das Gateway. Ich habe die Umlaute in den Zeilen 106 bis 107 der  sofort_payment.php (/lang/german/modules/payment/sofort_payment.php) auf ü bzw. Ü, ä und ö gesetzt. Das kann aber nicht die Lösung des Problems sein - die Abbruchmeldung sieht bei mir dann aber immerhin erst mal wieder richtig aus.

Ein ähnliches Problem habe ich in der Emailnachricht die das System zuschickt, wenn man sein Passwort vergessen hat. In der Zeile 421 in der german.php (/lang/german/german.php) steht ja, dass man "ä und ü für korrekte E-Mail Betreffszeile lassen" soll. Die Datei ist in ANSI kodiert. Das habe ich dann mal versuchsweise in UTF-8 ohne BOM umkodiert und hochgeladen. Jetzt passt das wieder - aber ist das die richtige Lösung?

[BTS]

Ein ähnliches Problem habe ich in der Emailnachricht die das System zuschickt, wenn man sein Passwort vergessen hat. In der Zeile 421 in der german.php (/lang/german/german.php) steht ja, dass man "ä und ü für korrekte E-Mail Betreffszeile lassen" soll. Die Datei ist in ANSI kodiert. Das habe ich dann mal versuchsweise in UTF-8 ohne BOM umkodiert und hochgeladen. Jetzt passt das wieder - aber ist das die richtige Lösung?

Grundsätzlich schon, aber bei den Mails gibt es noch ein weiteres Problem:
Ich meine, hier irgendwo gelesen zu haben, dass bei UTF-8 Umstellung des Shops folgende Dateien nach UTF-8 konvertiert werden sollen:

Code: [Auswählen]

templates/<TEMPLATENAME>/mail/<SPRACHE>/*.txt
templates/<TEMPLATENAME>/admin/mail/<SPRACHE>/*.txt
lang/<SPRACHE>/<SPRACHE>.php
Bei den Betreffzeilen und dem HTML-Part der Nachrichten klappt das, soweit ich bisher erkennen konnte, gut, aber die Mails haben noch einen Plaintext-Part (was ja sehr löblich ist) und der ist z.T. falsch kodiert: Der Part ist angegeben mit:

Code: [Auswählen]

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Aber der Textkörper enthält unkonvertierte Zeichen in ISO-8859-X - diese müssten zuerst nach UTF-8 und dann nach quoted-printable konvertiert werden. Im Mailfooter wird das sogar richtig gemacht (Bsp.: "Gesch=C3=A4ftsf=C3=BChrer:"), aber halt nicht im Fließtext darüber.
Allerdings dürfte das wohl nur altmodischen Spinnern auffallen, die HTML-Mails für Teufelszeug halten (me too).

[web28]

Es gibt eine Anleitung im Wiki (teilweise veraltet)

https://www.modified-shop.org/wiki/Modified_eCommerce_v1.06_rev_4642_als_UTF-8

und auf meiner Homepage

https://www.rpa-com.de/info-modified-shop-utf8.htm

Das evtl. Problem mit decode_htmlentities werden wir überprüfen.

Gruss Web28

[longchuan]

Danke hat soweit funktioniert.
Bin nach der Anleitung von https://www.rpa-com.de/info-modified-shop-utf8.htm
vorgegangen und sieht gut aus.
LG