nicht angemeldet
echo $begrüßung;
1.) 2.) 3.) 6.) 7.)
Soweit richtig, wobei aber 3. und 7. doppelt ist. Solange du nicht davon ausgehen musst, dass der Hoster die AddType-Direktive sperrt, kannst du die nehmen und auf header() verzichten.
4.) _Alle_ meine css-Ressourcen beginnen mit einer "@charset "utf-8";" Angabe.
Auch richtig, aber vielleicht überflüssig. Notwendig ist das nur, wenn du UTF-8-relevante Zeichen verwendest. Die kommen beispielsweise dann ins Spiel, wenn du http://de.selfhtml.org/css/eigenschaften/pseudoformate.htm#before_after@title=:before/:after und dort mittels "content:" Texte mit Nicht-ASCII-Zeichen einfügst. Die anderen Eigenschaften verwenden nur ASCII und dafür braucht es keine charset-Angabe. Kommentare sind zwar davon betroffen, doch die spielen keine Rolle.
5.) Wenn ich Daten (mit $kommando=$db->prepare($sql), $kommando->bind_param und $kommando->execute)an meine mysql datenbank schicke, dann kommt davor _immer_ eine "$db->set_charset("utf8");" Angabe.
Einmalig nach dem Verbindungsaufbau reicht. Ich gehe davon aus, dass diese Methode irgendwie zu einem Aufruf von mysql_set_character_set() aus der MySQL-Client-API führt oder zumindest ein "SET NAMES"-Statement ausführt.
Ich gehe davon aus, das ist alles, was ich tun kann sowie soll/muß, damit wirklich _überall_ die Verwendung von utf-8 gewährleistet wird. Ist das richtig so?
Ja. Vergessen in der Aufzählung hast du die Kodierung der Datenfelder in deinen Datenbanktabellen.
Das Ziel ist der Versand einer Mail [...]
Dazu habe ich nun folgenden PHP-Code:
Das sieht soweit in Ordnung aus, außer an dieser Stelle:
$mailinhalt="Sehr geehrter Herr Mustermann-Weiß,\r\rbitte bestätigen Sie uns noch Ihre Bestellung der 3 Kühe Björn, Gülle und Agnätha.\r\rMfG\r\rJörg Mustarmann-Spär";
Ein \r alleinstehend ist sicherlich ungünstig, da diese Form des Zeilenumbruchs hauptsächlich in nicht mehr aktuellen Systemen verwendet wurde. Üblicher sind \n und \r\n.
Das führ zu Folgenden Ergebnissen:
Bei gmx.de steht [...] nun alle Umlaute/Sonderzeichen _richtig_ dargestellt.
Das zeigt, dass GMX seine Hausaufgaben gemacht hat.
Bei der Webmailapplikation meines Webspace-Providers [...] steht also als Betreff: "Bestellbestätigung Ihrer 3 Wunschkühe - M ailtest 003". Woran das liegt, ist mir unerklärlich.
Da kann man zwar Vermutungen anstellen, doch anhand des originalen Text der Betreff-Headerzeile kann man dies deutlich besser tun.
Bei yahoo.de ein _sehr_ seltsames Verhalten. Alle Sonderzeichen werden richtig dargestellt, allerdings gibt es in der Mail selbst _keine_ Zeilenumbrüche.
Das wird an den komischen Zeilenumbruchszeichen liegen, beziehungsweise daran, dass Yahoo diese anscheinend als Zeilenumbruch nicht erkennt.
Bei cooltoad.com, einem Freemailprovider, das _absolute_ Chaos:
Seine Webseiten verwenden ISO-8859-1. Und so wie es aussieht hat er viel Verbesserungspotential ...
Da steht beim Empfänger nur ein "=?UTF-8?Q?J=C3=BCrgen=20Mustermann-Wei=C3=9F?=", als Absender "=?UTF-8?Q?J=C3=B6rg=20Mustermann-Sp=C3=A4r?="
Beides richtig, aber von der unkalten Kröte beim Dekodieren der Mail unberücksichtigt gelassen.
und als Mailinhalt, wieder in einer Wurst durchgeschrieben, steht: "Sehr geehrter Herr Mustermann-Weiß,bitte bestätigen Sie uns noch Ihre Bestellung der 3 Kühe Björn, Gülle und Agnätha.MfGJörg Mustarmann-Spär".
Sieht aus, als ob er von Zeichenkodierungen noch nicht viel gehört hat. Die Wurst wird wieder auf \r zurückzuführen sein.
Liegen die genannten Darstellungsfehler an mir?
Zusammenfassend: Bis auf den Zeilenumbruch bist du unschuldig. Workarounds, außer auf ISO-8859-1 umzustellen, scheinen mir auch nicht erfolgversprechend.
echo "$verabschiedung $name";