Hallo

als ich gestern die Anfrage von Magma bearbeitet habe, ist mir aufgefallen, dass die Mails unterschiedliche codiert werden vom Forum.

Um das Problem … nachzuvollziehen, habe ich einen Testuser angelegt …. Die Bestätigungsmail vom Forum, dass sich ein neuer Nutzer angelegt hat, war UTF-8 codiert.

Anschließend habe ich als Testuser eine Mail an einen anderen Account geschickt. Diese Mail war US-ASCII codiert.

Ich kann mich an die Diskussion mit Alex und Alfie im Januar und Februar 2010 erinnern, die durch meine Arbeit, MLF1 auf UTF-8 umzustellen, ausgelöst wurde und darum ging, dass E-Mails, auch in Bezug auf UTF-8, von unterschiedlichen Diensten unterschiedlich interpretiert werden. Die Diskussion ist in meinem alten, aber wegen eingeschränkter Funktionalität abgeschalteten Projektforum vorhanden. Wir haben damals an beiden Forengenerationen viel herumexperimentiert, um der Sache Herr zu werden. Alex hat am 6. Februar 2010 den entsprechenden Commit (57cf8fe3a45) vorgenommen. Die nämliche Funktion war nicht Bestandteil des Commits und ist bis zur Veröffentlichung der Version 2.2 am 12.05.2010, wo ich sie anhand des Tags auf Github nachweisen kann, auch nicht dazugekommen. Sie muss also schon vor dem UTF-8-Rework des E-Mail-Versands da gewesen sein.

Deshalb kommt mir die Funktion, die die Kodierung eines Textes zwischen US-ASCII oder einem Vorgabewert unterscheidet, der in MLF2 immer UTF-8 sein sollte, komisch vor. Da das Forum nicht immer mit einem Versionierungssystem entwickelt wurde, können wir nicht genau nachvollziehen, wann diese Funktion Einzug in die Software fand. In der Version 2.2 war sie jedenfalls schon da.

Frage, welchen Sinn hat die Funktion get_mail_encoding und benötigen wir diese überhaupt?

Das Forum verwendet grundsätzlich und durchgängig UTF-8 als Kodierung. Es ergibt daher für mich keinen Sinn, eine Prüfung auf eine andere Kodierung auszuführen. Da alle Zeichen der englischen Sprache und die gängigsten "Sonderzeichen" in UTF-8 an der selben Stelle wie in ASCII stehen, wird eine Prüfung ohne Zeichen, die dort nicht zu finden sind, immer US-ASCII zurückgeben, auch wenn die Kodierung UTF-8 erwünscht ist.

Wenn diese Funktion tatsächlich in der jetzigen Form sinnvoll ist, dann sollte der Aufruf in der my_mail-Funktion besser so aussehen - und zwar immer:

$mail_charset = get_mail_encoding($subject.$message.$settings['forum_name'].$settings['forum_email'].$from);

da der Name des Forums und dessen Adresse _immer_ Teil der Mail sind.

Wir könnten, wie du selbst vorschlägst, der Funktion immer den größtmöglichen/umfangreichsten String vorwerfen. Wenn in den dabei hinzukommenden Teilen ($settings['forum_name'].$settings['forum_email']) wie bei dir ein nicht im per Regex geprüften Bereich vorkommendes Zeichen enthalten ist, wird auch UTF-8 zurückgegeben. Gibt es das Zeichen auch dort nicht, kommt noch immer US_ASCII aus der Funktion, selbst wenn auch hier UTF-8 erwünscht ist.

Was denkt Ihr?

Ich gehe davon aus, dass die E-Mails immer UTF-8 kodiert versendet werden sollen. Daher halte ich die Funktion, die erwiesenermaßen vor dem 2010-er UTF-8-Rewrite vorhanden war und mit ihm unerwünschte Nebenwirkungen hat, für obsolet.

Hinzu kommt die Frage, wozu hier und überhaupt CHARSET benutzt wird? Die Konstante wird in der index.php mit dem Wert aus der zu benutzenden Sprachdatei definiert. In jeder Sprache steht dort der Wert utf-8. Ich frage mich, ob das Forum überhaupt funktionieren würde, wenn in irgendeiner Sprache ein anderer Wert als UTF-8 vermerkt wäre, oder ob dann nur Krikelkrakel zu lesen wäre, weil die Software an vielen Stellen hartkodiert von UTF-8 als zu verwendender Kodierung ausgeht.

Tschö, Auge