PHP Umgang mit Umlauten - email-Versand

[Überkinger]

Hallo,

1. Grundsatzfrage zum PHP-Coden im Umgang mit Umlauten.

Erst umwandeln wenn sie aus DB ausgelesen wurden und zur weiteren Verarbeitung dienen oder Umlaute vor Eintrag in die DB umwandeln? Logisch erscheint mir, erst nach aus DB auslesen.

2. Ich versende HTML-eMails, was hervorragend klappt.

Mein Header:

$header .= "MIME-Version: 1.0\n";
$header .= "From: $from\n";
$header .= "Reply-To: $from\n";
$header .= "Content-Type: text/html; charset=ISO-8859-1\n";
$header .= "Content-Transfer-Encoding: 8bit\n";

Versende ich die Mail, die Umlaute enthält, werden diese auch richtig dargestellt, sofern im Browser ISO-8859-1 eingestellt ist. Wenn als UTF-8, werden diese mit schwarzen Rautern mit Fragezeichen dargestellt, auch wenn ich die Codierung auf UTF-8 umstelle.

Ist ISO-8859-1 oder UTF-8 Standard?

Meine jetzige Lösung:

$TRANS = array ("Ö" => "Oe","ö" => "oe","Ä" => "Ae","ä" => "ae","Ü" => "Ue","ü" => "ue","ß" => "ss",);
$betreff= strtr($betreff,$TRANS);
echo "$betreff";

Schaut halt blöd aus, wenn Aepfel ueber Oel schiessen, anstatt Äpfel über Öl schießen.

 

[Cai-pirinha]

Wie wäre es mit ö etc. für die Umlaute? Ist doch der einfachste Weg, oder nicht?

 

[Überkinger]

Wie wäre es mit ö etc. für die Umlaute? Ist doch der einfachste Weg, oder nicht?

Das habe ich auch schon versucht, mit dem Resultat dass die ö etc. nicht umgewandelt werden. Hab ich grad getestet auf die Thunderbird. ISO 8859-1 und ö ergibt im Betreff ö und nicht ö :-(

 

[SC6]

Hallo,

1. Grundsatzfrage zum PHP-Coden im Umgang mit Umlauten.

2. Ich versende HTML-eMails, was hervorragend klappt.

zu 1. Idealerweise legst du dich auf ein Encoding fest und verwendest dieses dann auch durchgängig. Sprich, wenn du in deiner Datenbank UTF-8 als Zeichensatz verwendest, ergibt es wenig Sinn, die Daten als ISO auszuliefern. Ich denke hier solltest du anfangen zu suchen und überall gleiche Zeichensätze verwenden. Insofern du dann den Zeichensatz überall richtig deklarierst sollte auch jeder aktuelle Browser oder Mailclient alle Zeichen richtig darstellen.

zu 2. Hier sei zumindest die Frage nach dem Sinn erlaubt. HTML hat nach meiner Ansicht nichts in EMails verloren. Ansonsten siehe unten.

Wie wäre es mit ö etc. für die Umlaute? Ist doch der einfachste Weg, oder nicht?

ACK.

@TE
Was spricht denn gegen htmlentities? Evtl html_special_chars anschauen.

 

[Cai-pirinha]

ACK.

sorry, hab vergessen, dass es um den betreff geht.. die uhrzeit..

 

[SC6]

sorry, hab vergessen, dass es um den betreff geht.. die uhrzeit..

Verstehe zwar dein Zitat nicht, aber "ACK" (Acknowledgment) heißt in diesem Fall Zustimmung.

Mir ist auch nicht bewusst, dass sich der TE nur auf den Betreff bezogen hat.

 

[Überkinger]

zu 1. Idealerweise legst du dich auf ein Encoding fest und verwendest dieses dann auch durchgängig. Sprich, wenn du in deiner Datenbank UTF-8 als Zeichensatz verwendest, ergibt es wenig Sinn, die Daten als ISO auszuliefern. Ich denke hier solltest du anfangen zu suchen und überall gleiche Zeichensätze verwenden. Insofern du dann den Zeichensatz überall richtig deklarierst sollte auch jeder aktuelle Browser oder Mailclient alle Zeichen richtig darstellen.

Danke, dann werde ich mal da beginnen, Fehler zu vermeiden.

zu 2. Hier sei zumindest die Frage nach dem Sinn erlaubt. HTML hat nach meiner Ansicht nichts in EMails verloren. Ansonsten siehe unten.

Ich bin Dienstleister und liefere täglich aktuelle Tagesinformationen per eMail an Kunden aus. Hier bietet sich HTML an um die Fülle an Informationen liefern zu können. Die Kunden bestellen nur deswegen diese Dienstleistung und wiessen worum es geht.[/QUOTE]

@TE
Was spricht denn gegen htmlentities? Evtl html_special_chars anschauen.

Diese Funktion muss ich mir erstmal ansehen.

strtr war die einfachste Methode die ich für diesen Zweck finden konnte.

 

[b03ch7]

Mails werden üblicherweise codiert wie in RFC2047 angegeben. Zwar gibt es UTF8SMTP (siehe RFC5336), das ist aber nicht verbreitet.

HTML hat wahrlich nichts im Betreff einer E-Mail verloren. Vielleicht solltest du mit RFC5322 anfangen, statt dich per trial-and-error von einem Fettnäpfchen ins nächste zu hangeln.

Falls du unbedingt UTF8 im Subject willst, dann stell =?UTF-8?B? voran, jag den Betreff durch base64_encode und dann noch ein ?= dahinter.

 

[Überkinger]

HTML hat wahrlich nichts im Betreff einer E-Mail verloren. Vielleicht solltest du mit RFC5322 anfangen, statt dich per trial-and-error von einem Fettnäpfchen ins nächste zu hangeln.

Halt mal. Niemand hat davon gesprochen, dass ich HTML in die Betreffzeile schreiben will. Lies mal richtig. Es ist eine HTML-eMail deren Subjekt noch nicht korrekt codiert wird.

Falls du unbedingt UTF8 im Subject willst, dann stell =?UTF-8?B? voran, jag den Betreff durch base64_encode und dann noch ein ?= dahinter.

Auch hier. Niemand sagt, das ich unbedingt UTF8 verwenden will. Dein Post hat mich jetzt kein bisschen weitergebracht. Und ja, an der RFC bin ich dran.

Dennoch einen guten Morgen. :-)

 

[Überkinger]

Moin,

Tabellen sind nun auf UTF-8-general um gestellt. Dokumente und Content-Type sind ebenfalls überall fix auf utf-8eingestellt. Äpfel über Öl wird als Äpfel über Öl dargestellt :-(

 

[AlbertLast]

nimm einfach utf_decode : http://de.php.net/manual/de/function.utf8-decode.php
emails sollten keine utf charcode benutzen wegen den oben genannten gründen.

 

[Trainmaster]

Zum grundsätzlichen Umgang mit Umlauten und UTF-8: Leider scheitert es oftmals daran, dass diverse Einstellungen nicht getroffen wurden. Einige der hier vorgestellten Lösungen sind schlichtweg pfusch.

Einige Dinge, die zu beachten sind:
- Kollation der Datenbank auf UTF-8 umgestellt?
- Datenbankverbindung für UTF-8 konfiguriert?
- Dateien als "UTF-8 ohne BOM" gespeichert?
- UTF-8 charset (meta, header...)?

Außerdem: Eine Mailer-Klasse zu verwenden kann ich nur empfehlen. Eine kleine Übersicht findest du hier: http://www.robo47.net/text/38-Mail-ist-tot-es-lebe-mail.

 

[Überkinger]

Zum grundsätzlichen Umgang mit Umlauten und UTF-8: Leider scheitert es oftmals daran, dass diverse Einstellungen nicht getroffen wurden. Einige der hier vorgestellten Lösungen sind schlichtweg pfusch.

Einige Dinge, die zu beachten sind:
- Kollation der Datenbank auf UTF-8 umgestellt?
- Datenbankverbindung für UTF-8 konfiguriert?
- Dateien als "UTF-8 ohne BOM" gespeichert?
- UTF-8 charset (meta, header...)?

Außerdem: Eine Mailer-Klasse zu verwenden kann ich nur empfehlen. Eine kleine Übersicht findest du hier: http://www.robo47.net/text/38-Mail-ist-tot-es-lebe-mail.

Hallo,

vielen Dank euch für die Denkanstöße hinsichtlich der vielen Verbindungen und Bindungen. Ich setze auf die Klasse PHP-Mailer.

Ich bin jetzt alle Schritte durchgegangen und habe einige Diskrepanzen festgestellt und diese ausgeräumt. Hängen bleibe ich jetzt an der Datenbankverbindung.

Wann muss ich mysql_query('set character set utf8') genau ausführen.

Reicht es, den Zeichensatz zu setzen nachdem ich die Verbindung aufgebaut habe oder
bevor ich Daten in die DB schreibe?

Ergänzung (11. Dezember 2011)

Ich bekomme es einfach nicht hin.

1. Editor (Notepad++) ist auf UTF-8 eingestellt (OHNE BOM)

2. Datenbank ist auf UTF-8 eingestellt
mysql_query ('SET CHARACTER SET utf8') or die ("Fehler");
mysql_query ('SET NAMES utf8') or die ("Fehler");

3. Document ist auf UTF-8 eingestellt.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

4. phpmailer ist auf UTF-8 eingestellt und Mails kommen auch als UTF-8
$mail->CharSet = 'utf-8';

5. PHP-Script wurde auf UTF-8 gesetzt
ini_set('default_charset', 'UTF-8');

Resulttat: Äpfel über Öl

Interessanterweise werden im HTML-Body der Mail alle Umlaute korrekt dargestellt. Wenn ich im PHPmailer $mail->Subject = 'Äpfel über Ök'; übergebe, erscheinen die Umlaute korrekt im Betreff.

Mein Workflow:

1. HTML-Datei als Quelle, codiert als UTF-8
2. Tags umschießen zu parsenden Text <!--test-->Äpfel über Öl<!--/test-->

$find_test= preg_match ("#<!--test-->(.*?)<!--/test-->#si",$content_htm,$match_test);
    if ($find_test) {
        $result = $match_test[0];
        $test= str_replace ("<!--test-->","",$result);
        $test= str_replace ("<!--/test-->","",$test);
	$test= str_replace ("\n","",$test);
	$test= trim ($schlagzeile);

$sql = "INSERT INTO test (test) VALUES ('" .mysql_real_escape_string($test). "') ";
mysql_query ('SET CHARACTER SET utf8') or die ("Fehler");
mysql_query ('SET NAMES utf8') or die ("Fehler");
$resultb = mysql_query($sql,$link_db) or die('Datenbankfehler. Abbruch des Scripts' . mysql_error());

Das Problem liegt definitiv zwischen Punkt 1 und 2. Der liefert statt Ä Ã¼ aus.

 

[Daaron]

Was passiert, wenn du einfach utf8_encode/decode verwendest? mit mb_detect_encoding kannst du sogar noch vorher prüfen, ob es überhaupt was umzucodieren gibt.

 

[Trainmaster]

mysql_query ('SET CHARACTER SET utf8') or die ("Fehler");
mysql_query ('SET NAMES utf8') or die ("Fehler");

Ersteres kannst du dir sparen, es genügt "SET NAMES 'utf8'", siehe http://dev.mysql.com/doc/refman/5.0/en/charset.html. Am besten verwendest du eine Klasse für die Datenbankverbindung und sendest diesen Befehl einmalig zu Beginn an den SQL-Server.

Interessanterweise werden im HTML-Body der Mail alle Umlaute korrekt dargestellt. Wenn ich im PHPmailer $mail->Subject = 'Äpfel über Ök'; übergebe, erscheinen die Umlaute korrekt im Betreff.

Irgendwie bin ich leicht verwirrt. Was ist den nun konkret dein Problem, sofern sowohl im Body als auch im Betreff die Umlaute korrekt angezeigt werden?

 

[Überkinger]

nimm einfach utf_decode : http://de.php.net/manual/de/function.utf8-decode.php
emails sollten keine utf charcode benutzen wegen den oben genannten gründen.

Was passiert, wenn du einfach utf8_encode/decode verwendest? mit mb_detect_encoding kannst du sogar noch vorher prüfen, ob es überhaupt was umzucodieren gibt.

Das war der entscheidende Tipp. DANKE SCHÖN!

Wichtig ist jedoch, dass en/decode vor str_replace gemacht wird, sonst verhaspelt sich PHP. damit haben wir jetzt das eigentliche Problem gelöst.

Ich hoffe, de/encode hilft mir auch weiter, wenn ich den Content jetzt in eine Tebelle schreibe die nicht UTF-8 ist. Mein CMS ist auf latin1_swedish-1 eingestellt. Wurde vom Hersteller so vorgegeben. Meine eigenen Tabellen auf utf-8_general_si

 

[Überkinger]

Wieder eine Nacht durchgezecht. Die Datenbank ist jetzt komplett auf UTF-8 umgestellt, inkl. Sortierung auf allen Feldern. Jetzt habe ich das Problem, dass ein String, der ein Umlaut enthält an der Stelle abbricht, an der der Umlaut kommen würde. Es muss vor dem Eintragen in die DB passieren, da das Ergebnis richtig ist. Oder es liegt an der DB, die hier am Umlaut abbricht.

Aus "Diese Woche ziehen einige Stürme über Deutschland (Die kommen übrigens wirklich!)"
wird
"Diese Woche ziehen einige St"

 

[Trainmaster]

Jetzt habe ich das Problem, dass ein String, der ein Umlaut enthält an der Stelle abbricht, an der der Umlaut kommen würde.

An welcher Stelle in deiner Applikation tritt dieses Problem auf. Könntest du dies genauer beschreiben und ggfs. mit einem Auszug aus deinem Code erläutern?

 

[Überkinger]

$find_schlagzeile = preg_match ("#id=sz(.*?)</td>#si",$content_htm,$match_schlagzeile);
    if ($find_schlagzeile) {
        $schlagzeile = $match_schlagzeile[0];
	$schlagzeile = utf8_decode($schlagzeile );
        echo "Schlagzeile1 $schlagzeile";
	$schlagzeile = str_replace ("id=sz>","",$schlagzeile);
        $schlagzeile = str_replace ("</td>","",$schlagzeile);
	$schlagzeile = str_replace ("\n","",$schlagzeile);
	$schlagzeile = trim ($schlagzeile);
        echo "$schlagzeile";

$sql = "SET NAMES 'utf8'";
$result = mysql_query ($sql,$link_db) or die ("Fehler");
$sql = "INSERT INTO tabelle (schlagzeile) VALUES ('" .mysql_real_escape_string($schlagzeile). "') ";
$result = mysql_query($sql,$link_db) or die('Datenbankfehler. Abbruch des Scripts' . mysql_error());
	}

Es muss beim Eintragen in die DB passieren, weil echo $schlagzeile das richtige Ergebnis liefert, ohne dass vor dem Umlaut der Text abbricht.

 

[Trainmaster]

Mit erläutern meine ich nicht, einfach nur einen Skriptfetzen zu liefern. Wo genau ist das Problem? Hast du den String an verschiedenen Stellen mit var_dump ausgeben lassen, Stichwort: Debugging? Welchen Inhalt hat die Variable $content_htm?

Ergänzung (13. Dezember 2011)

Und du bist sicher, dass die Kollation auf UTF-8 eingestellt ist? Bitte beachte, dass die Spalten einer Tabelle eine andere Kollation haben können, als die Tabelle selbst.