Fehlerhafte Umlaute in Text E-Mails

[Torsten Riemer]

Quelle: ​modified eCommerce Shopsoftware 2.0.2.2 rev 10690 veröffentlicht

Den Fehler kann ich nachvollziehen und zusätzlich noch feststellen, dass die Umlaute nicht nur in der Text E-Mail Vorschau defekt sind, sondern auch in den versendeten Text E-Mails.

Das hatten wir eigentlich bereits in Ticket #431 durch das Changeset r8628 korrigiert.

[Ronald Parcinski]

Bitte den Inhalt und die Kodierung der change_order_mail.txt überprüfen

[Torsten Riemer]

Ich bin mir sicher, das Gerhard da bereits eine Korrektur vorgenommen hatte, die die Kodierung der Dateien ermittelt und entsprechend die E-Mails verschickt, egal ob der Shop unter latin1 oder utf8 läuft.

[Ronald Parcinski]

function encode_utf8 liefert falsche Ergebnisse zurück.

Due Funktion hat früher funktioniert.

[Ronald Parcinski]

In 10728:

fix #1188

[Ronald Parcinski]

In 10730:

fix #1188

[Torsten Riemer]

Ich kann nicht nachvollziehen, dass der Fehler damit behoben ist. Im Demoshop steht in der Text-Ansicht der E-Mail Vorschau immer noch:

Hallo Lara Gast,

Der Status Ihrer Bestellung Nr. 5 vom 23.06.2012 wurde ge?ndert.
[...]

Auch in den versendeten Text-Mails sind die Umlaute noch defekt:

[...]
Sehr geehrter Herr Demo Demo,

vielen Dank f?r Ihre Bestellung.
[...]

[Ronald Parcinski]

Der Cache war nicht gelöscht (templates_c). Jetzt funktioniert es.

Bleibt aber die Frage warum das an dieser Stelle so penetrant gecacht wird.

[Torsten Riemer]

Stimmt, danke!

[FräuleinGarn]

Ticket muss erneut geöffnet werden.

change_order_mail.txt und create_account_mail.txt haben Umlautfehler und ergeben folgende Warnings.

für die create_account_mail.txt

[23-09-2018 19:40:21] E_WARNING	: LoggingManager: mb_detect_encoding(): Illegal argument in File: /inc/html_encoding.php on Line: 46
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #0 - /includes/external/smarty/smarty_3/sysplugins/smarty_internal_resource_file.php called at Line 162
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #1 - /includes/external/smarty/smarty_3/sysplugins/smarty_template_source.php called at Line 210
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #2 - /includes/external/smarty/smarty_3/sysplugins/smarty_internal_templatecompilerbase.php called at Line 421
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #3 - /includes/external/smarty/smarty_3/sysplugins/smarty_internal_templatecompilerbase.php called at Line 351
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #4 - /includes/external/smarty/smarty_3/sysplugins/smarty_template_compiled.php called at Line 184
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #5 -/includes/external/smarty/smarty_3/sysplugins/smarty_template_compiled.php called at Line 141
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #6 - /includes/external/smarty/smarty_3/sysplugins/smarty_template_compiled.php called at Line 105
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #7 - /includes/external/smarty/smarty_3/sysplugins/smarty_internal_template.php called at Line 206
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #8 - /includes/external/smarty/smarty_3/sysplugins/smarty_internal_templatebase.php called at Line 232
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #9 -/includes/external/smarty/smarty_3/sysplugins/smarty_internal_templatebase.php called at Line 116
[23-09-2018 19:40:21] E_WARNING	: LoggingManager: Backtrace #10 -/create_account.php called at Line 482

für die change_order_mail zb

[23-09-2018 19:36:48] E_WARNING	: LoggingManager: mb_detect_encoding(): Illegal argument in File: /inc/html_encoding.php on Line: 46
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #0 -/includes/external/smarty/smarty_3/sysplugins/smarty_internal_resource_file.php called at Line 162
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #1 -/includes/external/smarty/smarty_3/sysplugins/smarty_template_source.php called at Line 210
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #2 -/includes/external/smarty/smarty_3/sysplugins/smarty_internal_templatecompilerbase.php called at Line 421
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #3 -/includes/external/smarty/smarty_3/sysplugins/smarty_internal_templatecompilerbase.php called at Line 351
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #4 -/includes/external/smarty/smarty_3/sysplugins/smarty_template_compiled.php called at Line 184
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #5 -/includes/external/smarty/smarty_3/sysplugins/smarty_template_compiled.php called at Line 141
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #6 - /includes/external/smarty/smarty_3/sysplugins/smarty_template_compiled.php called at Line 105
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #7 -/includes/external/smarty/smarty_3/sysplugins/smarty_internal_template.php called at Line 206
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #8 -/includes/external/smarty/smarty_3/sysplugins/smarty_internal_templatebase.php called at Line 232
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #9 -/includes/external/smarty/smarty_3/sysplugins/smarty_internal_templatebase.php called at Line 116
[23-09-2018 19:36:48] E_WARNING	: LoggingManager: Backtrace #10 - /admin/dhlgkapi_print_label.php called at Line 799

Letzter Fall liegt nicht am dhl Modul. Ist auch nachstellbar, wenn man den Status der Bestellung ändert und in Emailvorschau auf txt Mail geht. In der dhlgkapi_print_label.php wird aufgerufen

$txt_mail = $smarty->fetch(CURRENT_TEMPLATE.'/admin/mail/'.$order->info['language'].'/change_order_mail.txt');

wie es bei Statusänderungen sonst auch der Fall sein wird.

Shopversion 2.0.4.2 mit tpl_modified_responsive

[Torsten Riemer]

Kann ich nicht nachvollziehen, weder in einem latin1 Shop noch in einem auf utf8 gestellten Shop.

Bitte genaue Angaben machen, wie der Fehler nachgestellt werden kann.

[FräuleinGarn]

Der Fehler tritt nur in php 7.1.22 auf.

Wahrscheinlich wegen diesem fix
​Fixed bug #76704 (mb_detect_order return value varies based on argument type) und der damit zusammenhängenden ​Supported Character Encoding Liste

In Zeile 46 der /inc/html_encoding.php steht

mb_detect_encoding($string, ENCODE_DEFINED_CHARSETS)

in

mb_detect_encoding

steckt

string mb_detect_encoding ( string $str [, mixed $encoding_list = mb_detect_order() [, bool $strict = FALSE ]] )

und mb_detect_order wurde geändert.

Es liegt an dieser Zeile in der /inc/html_encoding.php

define('ENCODE_DEFINED_CHARSETS','ASCII,UTF-8,ISO-8859-1,ISO-8859-15,cp866,cp1251,cp1252,KOI8-R,BIG5,GB2312,BIG5-HKSCS,Shift_JIS,EUC-JP'); 

Wenn man BIG5-HKSCS daraus entfernt, dann funktioniert die Emailvorschau wieder fehlerfrei und es wird kein Fehler im log geschrieben. Anscheinend wird dieses Charset nicht mehr unterstützt. Oder es gibt noch eine andere Datei im Shopsystem, die die Charsets vorgibt und da steht es nicht drin.

GB2312 steht auch nicht in der Liste der unterstützen Charsets, führt aber nicht zu einem Fehler, wenn es drin bleibt.

[FräuleinGarn]

Thema wird hier nochmal detailliert behandelt:

​PHP 7.1.22 führt zu Umlautproblemen in Textmails und bei Neuinstallationen

[FräuleinGarn]

Ich glaube, dass aktuell kein Charset ausgemistet wurde, sondern es schon länger nicht mehr unterstützte in der html_encoding.php gab (scheinen mehrere zu sein). Nur bisher wurde das nicht geprüft. Wie im Thread geschrieben, ist die „Supported Encoding List“ in PHP 7.0.32 (was keinen aktiven Support mehr hat) gleich der in 7.1.22. Heißt da hat sich schon länger nichts getan, weil 7.0.32 schon länger nur noch security fixes erhält.

Im PHP Ticket steht:

The function mb_detect_order() can receive either a comma separated list of encodings or an array of encodings. However, its return value varies based on whether it is given a string or an array that contain the same values.

Expected result:
----------------
mb_detect_order() should return the same value regardless of which type is used for the encoding_list parameter. HHVM seems to not be affected by this.

Actual result:
--------------
When given a string, mb_detect_order() will return true if it finds at least one supported encoding in the list.

When given an array, mb_detect_order() will return false if it finds any non-supported encoding.

Die Auflistung in der html_encoding scheint ein string zu sein und kein array. Demnach wurde bisher geprüft „gibt es wenigstens ein unterstütztes Charset in dem String -> true“.

Und nun haben die es vielleicht auf die bisherige Array Lösung geändert: „ Gibt es irgendein nicht unterstütztes Charset im String -> false“.

Somit war das Ergebnis trotz nicht unterstützter Charsets bisher true, weil mindestens ein unterstütztes vorhanden war und nun ist das Ergebnis false, weil mindestens ein nicht unterstütztes vorhanden.

[Volker Rehn]

Vorschlag aus dem zitierten Thread:

In /inc/html_encoding.php entfernen wir BIG5-HKSCS, BIG5 und GB2312 aus der Definition von ENCODE_DEFINED_CHARSETS und ersetzen die drei durch GB18030.

[Torsten Riemer]

Und was ist mit dem hier beanstandeten Punkt?

Replying to FräuleinGarn:

[...]
Die Auflistung in der html_encoding scheint ein string zu sein und kein array. Demnach wurde bisher geprüft „gibt es wenigstens ein unterstütztes Charset in dem String -> true“.

Und nun haben die es vielleicht auf die bisherige Array Lösung geändert: „ Gibt es irgendein nicht unterstütztes Charset im String -> false“.

Somit war das Ergebnis trotz nicht unterstützter Charsets bisher true, weil mindestens ein unterstütztes vorhanden war und nun ist das Ergebnis false, weil mindestens ein nicht unterstütztes vorhanden.

Ich denke da wird doch das Hauptproblem liegen oder nicht?

[FräuleinGarn]

Wenn die Änderungen von vr umgesetzt werden, funktioniert es, weil kein nicht unterstütztes Charset mehr im String enthalten ist. Getestet mit PHP 7.1.22.

Dann sollte mit der vermutlich neuen Vorgehensweise aus dem PHP Ticket 76704 gelten:

Gibt es ein nicht unterstütztes Charset im string? Antwort nun: Nein -> true. Vorher wäre die Antwort Ja gewesen und somit folgte false.

Bitte aber noch überprüfen, ob Shift_JIS = SJIS ist. Hatte im Thread die unterstützten Charsets des Servers gepostet und da war Shift_JIS meiner Meinung nach nicht vorhanden.

[Volker Rehn]

Auch in ​http://php.net/manual/de/mbstring.supported-encodings.php ist Shift-JIS oder Shift_JIS nicht dabei.

Ich habe keinen Hinweis gefunden, dass sich Shift_JIS und SJIS unterscheiden.
Laut ​https://de.wikipedia.org/wiki/Shift_JIS steht das S in SJIS für Shift. Sucht man in Wikipedia nach SJIS, wird man nach Shift_JIS umgeleitet. Auch die englische Seite ​https://en.wikipedia.org/wiki/Shift_JIS sagt: "Shift JIS (Shift Japanese Industrial Standards, also SJIS, MIME name Shift_JIS) ..." Zwar ist der MIME-Name Shift_JIS, aber php listet SJIS.

Von daher kann in der Liste auch Shift_JIS durch SJIS ersetzt werden. Habe das auch mal einem shop 5.6er shop getestet:

Zusammenfassung der Änderungsvorschläge:

• In /inc/html_encoding.php entfernen wir BIG5-HKSCS, BIG5 und GB2312 aus der Definition von ENCODE_DEFINED_CHARSETS und ersetzen die drei durch GB18030.
• außerdem ersetzen wir dort Shift_JIS durch SJIS.

[Torsten Riemer]

In 11426:

Fix #1188