Opened 3 years ago

Closed 2 years ago

#1188 closed Bug/Fehler (fixed)

Fehlerhafte Umlaute in Text E-Mails

Reported by: Tomcraft Owned by: somebody
Priority: hoch Milestone: modified-shop-2.0.5.0
Component: Shop Version: 2.0.4.2

Description

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.

Attachments (3)

html_encoding.php (4.8 KB) - added by web28 3 years ago.
Bildschirmfoto 2018-09-27 um 10.47.41.png (54.1 KB) - added by anonymous 2 years ago.
changeset_11426.zip (1000 bytes) - added by Tomcraft 22 months ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 3 years ago by web28

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

comment:2 Changed 3 years ago by Tomcraft

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.

comment:3 Changed 3 years ago by web28

function encode_utf8 liefert falsche Ergebnisse zurück.

Die Funktion hat früher funktioniert.

Last edited 3 years ago by Tomcraft (previous) (diff)

Changed 3 years ago by web28

comment:4 Changed 3 years ago by web28

  • Resolution set to fixed
  • Status changed from new to closed

In 10728:

fix #1188

comment:5 Changed 3 years ago by web28

In 10730:

fix #1188

comment:6 Changed 3 years ago by Tomcraft

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.
[...]

comment:7 Changed 3 years ago by web28

  • Resolution set to fixed
  • Status changed from reopened to closed

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

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

comment:8 Changed 3 years ago by Tomcraft

Stimmt, danke!

comment:9 Changed 2 years ago by 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

Last edited 2 years ago by Tomcraft (previous) (diff)

Changed 2 years ago by anonymous

comment:10 Changed 2 years ago by Tomcraft

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.

comment:11 Changed 2 years ago by 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.

comment:12 Changed 2 years ago by Tomcraft

  • Milestone changed from modified-shop-2.0.3.0 to modified-shop-2.0.5.0
  • Priority changed from normal to hoch
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 2.0.2.2 to 2.0.4.2

comment:13 Changed 2 years ago by FräuleinGarn

comment:14 follow-up: Changed 2 years ago by 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.

Last edited 2 years ago by Tomcraft (previous) (diff)

comment:15 Changed 2 years ago by vr

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.

comment:16 in reply to: ↑ 14 Changed 2 years ago by Tomcraft

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?

comment:17 Changed 2 years ago by 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.

comment:18 Changed 2 years ago by vr

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.

comment:19 Changed 2 years ago by Tomcraft

  • Resolution set to fixed
  • Status changed from reopened to closed

In 11426:

Fix #1188

Changed 22 months ago by Tomcraft

Add Comment

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.