Sonderzeichen bei Mail mit Inhalt aus Formular

[Brombeermilchtrinker]

Hallo Forum,

ich schreibe gerade an einem Gästebuch, in dem jeder, der sich in selbiges einträgt, nach dem korrekten Ausfüllen des Formulars eine Mail mit einem Bestätigungslink, mit dem er seinen Eintrag freischalten kann, bekommt.

In dieser Mail wird unter anderem auch der Eintrag selbst gesendet. Also nach der Art "Wenn Sie auf diesen Bestätigungslink klicken, dann wird Ihr untenstehender Eintrag veröffentlicht".

Jetzt ist mir aufgefallen, dass ich ein Problem mit Sonderzeichen habe.

Gibt jemand zB. folgenden Text ein...

Das ist schon <b>wieder</b> ein Test.   <<<

...und der Text der Mail wird _unter anderem_ aus $_POST['eintrag'] gebildet, dann steht in der Mail:

Das ist &lt;b&gt;wieder&lt;/b&gt; ein Test.

Wieso werden hier die Sonderzeichen _automatisch_ umgewandelt, obwohl ich das nicht explizit angeordnet habe bzw. was muß ich tun, um dies zu verhindern?

MfG

Der Brombeermilchtrinker

PS: Ich habe ansonst mit der Codierung keine Probleme. Sowohl der Inhalt der Mail, als auch der Header sind utf-8 codiert und das funktioniert auch (bis auf das Webmailsystem meines Providers, wenn ich das selbst teste) wunderbar.

[Brombeermilchtrinker]

Hallo Forum,

ich muß mich entschuldigen, ich hatte irrtümlich und ohne es zu merken, mit einer COPY&PASTE Aktion ein "htmlspecialchars" miteingebaut. Dann darf man sich natürlich über das Ergebnis nicht wundern.

Allerdings hab ich jetzt eine andere Frage.

Wie ich schon geschrieben habe, ist sowohl der Header, als auch der Inhalt der Mail utf-8 codiert. Sende ich jetzt eine Mail mit dem Betreff "Gärung und Glück" und dem selben Inhalt an eine gmx- oder hotmail-Adresse, dann wird sowohl der Betreff, als auch der eigentliche Inhalt richtig dargestellt.

Sende ich an www.cooltoad.com, ebenfalls ein Gratismailprovider, dann werden zwar die Umlaute des Betreffs richtig dargestellt, nicht aber die in der Mail. Wenn ich das Webmailsystem meines Providers verwende, um das Genze zu testen, ist es genau _ungekehrt_. Umlaute im Betreff werden nicht dargestellt, dafür die in der Nachricht.

Ich nehme an, der Grund dafür liegt nicht bei mir und ich kann dieses Verhalten somit nicht beeinflußen, oder?

MfG

Der Brombeermilchtrinker

PS: Der Code, der die Mail generiert:

  
$empfaenger=$_POST['mail'];  
$betreff="Bitte bestätigen Sie Ihren Gästebucheintrag";  
$text="Hallo ".$_POST['name']."!\r\rSie bekommen diese Mail, weil Sie sich gerade in unser Gästebuch eingetragen haben.\r\rIhr Eintag lautet:\r\r- - - - - - - - - - - - - - - - - - - -\r\r".htmlspecialchars($_POST['eintrag'])."\r\r- - - - - - - - - - - - - - - - - - - -\r\r".$permittext."\r\rWenn Sie diesen Eintrag so veröffnetlicht haben möchten, dann bestätigen Sie das bitte nun, in dem Sie auf folgenden Link klicken bzw. die Adresse kopieren und in einem neuen Browserfenster öffnen.\r\rhttp://www.example.com/test.php?check=".$csvname."\r\rWir wünschen Ihnen einen schönen Tag!\r\rDer Brombeermilchtrinker\r\r\rAchtung: Dies ist eine automatisch generierte Mail. Antworten an diese Mailadresse erreichen keinen Empfänger!";  
$header="";  
$header.="MIME-Version: 1.0\n";  
$header.="Content-type: text/plain; charset=utf-8\n";  
$header.="Content-Transfer-Encoding: 8bit\n";  
$header.="From: Der Brombeermilchtrinker <[e-mail]>\n";  
mail($empfaenger,utf8_decode($betreff),$text,$header, "[e-mail]");

[Markus**]

teile dem Formular mit, welche Art Content-Type und charset Du überträgst. http://de.selfhtml.org/html/referenz/attribute.htm#form

[Brombeermilchtrinker]

Hi Markus,

teile dem Formular mit, welche Art Content-Type und charset Du überträgst. http://de.selfhtml.org/html/referenz/attribute.htm#form

_das_ ist natürlich _nicht_ der Grund.

Ganz abgesehen davon, dass mein Formular eine entsprechende Angabe hat, ist dies, wie hier von dedlfix schön erklärt, überhaupt nicht nötig.

Und wie gesagt, das Problem tritt nicht bei gmx oder hotmail auf. Darum nehme ich an, dass das Problem eher nicht bei mir liegt. Der von mir gepostete Code zeigt zumindest mir keine diesbezüglichen Fehler.

MfG

Der Brombeermilchtrinker

[Sven Rautenberg]

Moin!

$betreff="Bitte bestätigen Sie Ihren Gästebucheintrag";
mail($empfaenger,utf8_decode($betreff),$text,$header, "[e-mail]");

  
Unter der Vorraussetzung, dass das Skript in UTF-8 gespeichert ist, wandern in dieser Konstellation ISO-8859-1-Umlaute in die Betreffzeile, obwohl es keine strikten ASCII-Zeichen sind.  
  
Alles, was nicht ASCII (Code 0 bis 127) ist, ist in Mailheadern böse und muss durch Encodingangaben entschärft werden. Die fehlt bei dir.  
  
Doppelt böse dürfte es dann sein, dass der Mailbody dann noch in einem komplett anderen Encoding auftritt, als der Subject-Header. Das können manche Heuristiken ausbügeln, andere offensichtlich aber nicht.  
  
 - Sven Rautenberg

[Brombeermilchtrinker]

Hi Sven,

Unter der Vorraussetzung, dass das Skript in UTF-8 gespeichert ist, wandern in dieser Konstellation ISO-8859-1-Umlaute in die Betreffzeile, obwohl es keine strikten ASCII-Zeichen sind.

Um ehrlich zu sein ... ich weiß nicht, wovon Du sprichst. Ich habe bisher Alles, was mit utf-8 zu tun hat, nur sehr suspekt verstanden. Ich verstehe das ganze Technik-Sprech bei all den Erklärungen einfach nicht.

Alles, was nicht ASCII (Code 0 bis 127) ist, ist in Mailheadern böse und muss durch Encodingangaben entschärft werden. Die fehlt bei dir.

Das stimmt nicht, dafür ist ja das "Content-Transfer-Encoding" da. (Siehe den Link von dedlfix.)

Doppelt böse dürfte es dann sein, dass der Mailbody dann noch in einem komplett anderen Encoding auftritt, als der Subject-Header.

Das stimmt doch gar nicht, wie kommst Du da drauf? Beides ist eindeutig utf-8!

$empfaenger="[e-mail]";  
$betreff="Bitte bestätigen Sie Ihren Gästebucheintrag";  
$text="Hänsel und Gretel wünschen Sich Hörnchen über alles";  
$header="";  
$header.="MIME-Version: 1.0\n";  
$header.="Content-type: text/plain; charset=utf-8\n";  
$header.="Content-Transfer-Encoding: 8bit\n";  
$header.="From: Max Mustermann <[e-mail]>\n";  
mail($empfaenger,utf8_decode($betreff),$text,$header, "[e-mail]");

Zusätzlich haben die php Ressourcen einen utf8-header:

  
header("Content-type:text/html;charset=utf-8");

_und_ sind utf-8 codiert gespeichert.

Das können manche Heuristiken ausbügeln, andere offensichtlich aber nicht.

Hm. =(

MfG

Der Brombeermilchtrinker

[Sven Rautenberg]

Moin!

Unter der Vorraussetzung, dass das Skript in UTF-8 gespeichert ist, wandern in dieser Konstellation ISO-8859-1-Umlaute in die Betreffzeile, obwohl es keine strikten ASCII-Zeichen sind.

Um ehrlich zu sein ... ich weiß nicht, wovon Du sprichst. Ich habe bisher Alles, was mit utf-8 zu tun hat, nur sehr suspekt verstanden. Ich verstehe das ganze Technik-Sprech bei all den Erklärungen einfach nicht.

Eine Zeichencodierung ist eine Zuordnung, welches Byte bzw. welche Bytekombination für welches menschliche Buchstabenzeichen steht. Wenn man Text tippt, wird aus dem eingegebenen Zeichen eine Bytekombination erstellt, und wenn diese Bytes wieder als Text dargestellt werden, wird anhand der Zuordnung wieder ermittelt, welches Zeichen darzustellen ist.

Praktisch, aber auch problematisch, ist die Tatsache, dass für die meisten Codierungen gilt, dass sehr viele Bytezuordnungen identisch sind. Man bemerkt also nur anhand der eher selten auftretenden abweichenden Zeichenzuordnungen, dass etwas falsch gelaufen ist. Oder eben daran, dass die gewählte Codierung irgendwo angegeben ist.

Alles, was nicht ASCII (Code 0 bis 127) ist, ist in Mailheadern böse und muss durch Encodingangaben entschärft werden. Die fehlt bei dir.

ASCII ist ein 7-Bit-Zeichensatz. Der wurde als Grundlage genommen für das Mailprotokoll SMTP.

Das stimmt nicht, dafür ist ja das "Content-Transfer-Encoding" da. (Siehe den Link von dedlfix.)

Mailheader sind etwas anderes, als der Mailbody. Wenn du den Link nochmal genau anschaust, dann steht dort eindeutig, das sich "Content-Transfer-Encoding" auf den Mailbody bezieht, nicht auf den Mailheader.

Weil der Mailheader dem Empfänger grundlegende Informationen liefert, wie der Mailbody zu verstehen ist, dürfen diese Informationen nicht schon in potentiell unverständlichen Codierungen geliefert werden. Wenn bei dir ein Chinese anruft und auf chinesisch fragt "Ich spreche jetzt chinesisch mit ihnen, ist das OK?", dann wirst du das schlicht nicht verstehen. Fragt er hingegen in einer international verständlichen Sprache, würdest du es verstehen und könntest den chinesischen Dolmetscher dazwischenschalten.

Der Mailheader erlaubt keinerlei andere Zeichen als nur 7-Bit-ASCII im SMTP-Dialog. Das Subject ist ebenfalls Bestandteil des Mailheaders. Also dürfen darin auch nur 7-Bit-ASCII-Zeichen vorkommen. Alle anderen Zeichen müssen so umgeformt werden, dass sie diese Forderung erfüllen. Dazu ist im Link von dedlfix aber auch Info enthalten.

Doppelt böse dürfte es dann sein, dass der Mailbody dann noch in einem komplett anderen Encoding auftritt, als der Subject-Header.

Das stimmt doch gar nicht, wie kommst Du da drauf? Beides ist eindeutig utf-8!

Erstens: Der Mailheader darf nur 7-Bit-ASCII sein, ein darin befindliches UTF-8-Umlautzeichen verstößt gegen diese Forderung.

Zweitens: Du dekodierst extra den UTF-8-Betreff in ISO-8859-1 - danach ist der Betreff also nicht mehr UTF-8, sondern ISO-8859-1. Das kann man so machen, aber auch ISO-8859-1 erfordert zwingend, das alle Zeichen, die nicht in 7-Bit-ASCII vorkommen, codiert werden müssen.

Nur für den Body kannst du durch die Angaben "Content-type" und "Content-transfer-encoding" im Mailheader global das Encoding und die Verwendung von 8-Bit-Zeichen angeben und musst dich dann um nichts mehr kümmern.

Hier ist ein Beispiel angedeutet: http://forum.de.selfhtml.org/archiv/2008/2/t166627/#m1087923

Zusätzlich haben die php Ressourcen einen utf8-header:

header("Content-type:text/html;charset=utf-8");

  
Irrelevant, weil dieser Header ja nicht in der versendeten Mail auftaucht, sondern an den Browser geht. Es ist allerdings hilfreich, das alles auf UTF-8 ausgerichtet ist.  
  

> \_und\_ sind utf-8 codiert gespeichert.  
  
Dito.  
  
 - Sven Rautenberg

[Brombeermilchtrinker]

Hi Sven,

zunächst danke für die schon verständlicheren Ausführungen.

Aber was muß ich nun praktisch tun mit dem Betreff?

Ich bin überhaupt so verwirrt jetzt, nachdem gmx und hotmail die Mails so darstellen wie ich es erwartet habe, ein anderer Service macht den Inhalt richtig und den Betreff falsch, ein anderer wiederum genau umgekehrt.

Ich verliere den Überblick und weiß jetzt bei meinem geposteten Codebeispiel nicht mehr .. was ist gut so, was nicht, was gehört anders.

Der Brombeermilchtrinker

[Jens Holzkämper]

Tach,

Alles, was nicht ASCII (Code 0 bis 127) ist, ist in Mailheadern böse und muss durch Encodingangaben entschärft werden. Die fehlt bei dir.

Das stimmt nicht, dafür ist ja das "Content-Transfer-Encoding" da. (Siehe den Link von dedlfix.)

nein, denn das regelt nur den Content nicht die Header.

Doppelt böse dürfte es dann sein, dass der Mailbody dann noch in einem komplett anderen Encoding auftritt, als der Subject-Header.

Das stimmt doch gar nicht, wie kommst Du da drauf? Beides ist eindeutig utf-8!

nein, die Strings mögen ursprünglich UTF-8 sein, du wandelst den Betreff schließlich von UTF-8 in ISO-8859-1 um.

mfg
Woodfighter

[dedlfix]

echo $begrüßung;

Ich nehme an, der Grund dafür liegt nicht bei mir und ich kann dieses Verhalten somit nicht beeinflußen, oder?

Ja, wenn du dich an allgemein übliche Standards hältst und die Freemailer nicht, dann ist das erstmal nicht dein Problem. Die Frage ist, inwieweit du eine Lösung findest, so du das willst, zu der alle Freemailer fähig sind. (Beispielsweise auf UTF-8 verzichten und ISO-8859-1 verwenden, und dabei die Nachteile der nur 255 Zeichen in Kauf nehmen.)

PS: Der Code, der die Mail generiert:

Im Prinzip ist wie bei jedem clientseitigen Problem nur das interessant, was der Client bekommt, nicht wie ein Server das zusammenbaut.

$empfaenger=$_POST['mail'];

Unnötig. Verwende $_POST['mail'] direkt an den Stellen, an denen du $empfaenger verwendest. Zumindest in dem Ausschnitt ist das ja nur eine Stelle.

$betreff="Bitte bestätigen Sie Ihren Gästebucheintrag";
mail($empfaenger,utf8_decode($betreff),$text,$header, "[e-mail]");[/code]

Die Betreffzeile verwendet einen eigenen Kodiermechanismus. Da du Nicht-ASCII-Zeichen (Umlaute) verwendest, solltest du diesen anwenden. Siehe z.B. http://www.paefken.westfalen.de/de.newusers/umlaute-faq.txt

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Hi Dedlfix,

Ja, wenn du dich an allgemein übliche Standards hältst und die Freemailer nicht, dann ist das erstmal nicht dein Problem. Die Frage ist, inwieweit du eine Lösung findest, so du das willst, zu der alle Freemailer fähig sind. (Beispielsweise auf UTF-8 verzichten und ISO-8859-1 verwenden, und dabei die Nachteile der nur 255 Zeichen in Kauf nehmen.)

Weiß nicht, ob ich das will. Naja, für _diesen_ Verwendungszweck könnte ich das andenken.

Die Betreffzeile verwendet einen eigenen Kodiermechanismus. Da du Nicht-ASCII-Zeichen (Umlaute) verwendest, solltest du diesen anwenden. Siehe z.B. http://www.paefken.westfalen.de/de.newusers/umlaute-faq.txt

BITTE nicht. Ich kenne diese Seite, Du hast den Link schon des öfteren gepostet. Abgesehen davon: Ich habe genau das gemacht, was dort steht, nämlich mit dem "Content-Transfer-Encoding" dafür gesorgt, daß auch der Betreff als utf-8 codiert wird.

MfG

Der Brombeermilchtrinker

PS: Mich würds trotzdem interessieren, wieso gmx und hotmail die Mails richtig darstellen und es an anderen Stellen _nicht_ funktioniert.

[dedlfix]

echo $begrüßung;

Die Betreffzeile verwendet einen eigenen Kodiermechanismus. Da du Nicht-ASCII-Zeichen (Umlaute) verwendest, solltest du diesen anwenden. Siehe z.B. http://www.paefken.westfalen.de/de.newusers/umlaute-faq.txt
BITTE nicht. Ich kenne diese Seite, Du hast den Link schon des öfteren gepostet. Abgesehen davon: Ich habe genau das gemacht, was dort steht, nämlich mit dem "Content-Transfer-Encoding" dafür gesorgt, daß auch der Betreff als utf-8 codiert wird.

Die Betreff-Zeile ist ein Mailheader und kein Teil des Contents. Deshalb wirkt keine Content-Angabe darauf. Wenn du nicht willst, dass die Clients raten sollen, dann kodiere deine Betreffzeile ordentlich.

PS: Mich würds trotzdem interessieren, wieso gmx und hotmail die Mails richtig darstellen und es an anderen Stellen _nicht_ funktioniert.

Frag dort nach, was die da programmiert haben.

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Hi dedlfix,

Kannst Du mir _BITTE_ statt einem

Wenn du nicht willst, dass die Clients raten sollen, dann kodiere deine Betreffzeile ordentlich.

direkt hinschreiben, wie ich den Code ändern muß?

Ich lese jetzt seit heute Früh sämtliche Archivbeiträge zum Thema Mails, utf-8, etc und komme einfach nicht weiter.

Ich _BITTE_ Dich, sag mir:

Ist folgendes Beispiel jetzt OK für utf-8 Codierung im Content _und_ im Betreff?

$empfaenger="[e-mail]";  
$betreff="Bitte bestätigen Sie Ihren Gästebucheintrag";  
$text="Hänsel und Gretel wünschen Sich Hörnchen über alles";  
$header="";  
$header.="MIME-Version: 1.0\n";  
$header.="Content-type: text/plain; charset=utf-8\n";  
$header.="Content-Transfer-Encoding: 8bit\n";  
$header.="From: Max Mustermann <[e-mail]>\n";  
mail($empfaenger,utf8_decode($betreff),$text,$header, "[e-mail]");

Falls nein, _was_ muß ich _wo_ anders schreiben?

Und wie müßte das Ganze aussehen, um Deinen anderen Vorschlag mit dem "Beispielsweise auf UTF-8 verzichten und ISO-8859-1 verwenden" zu realisieren?

MfG

Der Brombeermilchtrinker

[dedlfix]

echo $begrüßung;

Kannst Du mir _BITTE_ statt einem

Wenn du nicht willst, dass die Clients raten sollen, dann kodiere deine Betreffzeile ordentlich.
direkt hinschreiben, wie ich den Code ändern muß?

Nun, das Subjekt muss ungefähr wie folgt aussehen. In deinem Fall vielleicht mit UTF-8 und den Bytewerten der UTF-8-Zeichen.

=?ISO-8859-1?Q?L=FCsung?= des Umlautproblems

echo "$verabschiedung $name";

[Sven Rautenberg]

Moin!

Nun, das Subjekt muss ungefähr wie folgt aussehen. In deinem Fall vielleicht mit UTF-8 und den Bytewerten der UTF-8-Zeichen.

=?ISO-8859-1?Q?L=FCsung?= des Umlautproblems

Das ist nicht UTF-8, sondern ISO-8859-1 - steht ja auch drin. :)

- Sven Rautenberg

[Brombeermilchtrinker]

Hallo!

Nun, das Subjekt muss ungefähr wie folgt aussehen. In deinem Fall vielleicht mit UTF-8 und den Bytewerten der UTF-8-Zeichen.

=?ISO-8859-1?Q?L=FCsung?= des Umlautproblems

Und was soll ich jetzt tun???

MfG

Der Brombeermilchtrinker

[dedlfix]

echo $begrüßung;

Nun, das Subjekt muss ungefähr wie folgt aussehen. In deinem Fall vielleicht mit UTF-8 und den Bytewerten der UTF-8-Zeichen.
  =?ISO-8859-1?Q?L=FCsung?= des Umlautproblems
Und was soll ich jetzt tun???

Sollen gar nichts, aber wenn du was richtig machen willst, bringst du deinen Betreff in eine Form wie diese Beispielzeile.

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Hi!

Sollen gar nichts, aber wenn du was richtig machen willst, bringst du deinen Betreff in eine Form wie diese Beispielzeile.

Und woher soll ich wissen, wie ich den vn mir gewünschten Betreff zu schreiben habe? Kan man das mit php automatisch umwandeln lassen????

BMT

[Jens Holzkämper]

TacTach,

Und woher soll ich wissen, wie ich den vn mir gewünschten Betreff zu schreiben habe? Kan man das mit php automatisch umwandeln lassen????

meine Suchstrategie zur möglichen Problemlösung:

1. Du möchtest die Funktion mail() in php nutzen, also sind meine Suchbegriffe in google mail und php.

2. Der zweite Treffer führt mich zum PHP-Handbuch der Funktion mail().

3. Unter Parameters steht bei subject "Subject must satisfy RFC 2047. " RFC sind nicht immer einfach zu lesen, also hoffe ich darauf, dass jemand anderes das Problem schonmal gelöst hat, vielleicht ist ja der Quelltext einfacher zu lesen.

4. Suche ich auf der oben aufgerufenen Handbuchseite nach 2047 finde ich ganz unten einen Kommentar in dem eine Funktion zum kodieren von E-Mail-Headern enthalten ist. Viel spannender ist allerdings der Einleitungssatz "If your server doesn't have mb_send_mail()", PHP scheint also eine eigene Lösung für das Problem zu haben. Wie du Informationen zu mb_send_mail bekommst, hast du jetzt hoffentlich verstanden.

mfg
Woodfighter

[Vinzenz Mai]

Hallo,

Sollen gar nichts, aber wenn du was richtig machen willst, bringst du deinen Betreff in eine Form wie diese Beispielzeile.

Und woher soll ich wissen, wie ich den vn mir gewünschten Betreff zu schreiben habe? Kan man das mit php automatisch umwandeln lassen????

ja. Achte auf den richtigen Wert für den Parameter charset. Quoted-Printable wäre das bevorzugte Transfer-Encoding.

Freundliche Grüße

Vinzenz

[Brombeermilchtrinker]

Hi Vinzenz,

trotzdem, ich versteh die Welt nicht mehr. Ich habe mich nicht nur mit dem Handbuch und vielen Tutorials aus dem Netz beschäftigt, sondern auch _unzählige_ Posts aus dem Archiv zu diesem Thema gelesen.

Aus letzteren geht ganz klar hervor, daß man prinzipiell utf-8 verwenden sollte, weil da einfach die Vorteile überwiegen. Gut, ich habe somit in jeder html-Seite ein <meta http-equiv="content-type" content="text/html; charset=utf-8" />, jede php-Ressource bekommt bei mir ein header("Content-type:text/html;charset=utf-8");, jede css-Datei fängt bei mir mit einem @charset "utf-8"; an, bei einem Senden von Daten an eine DB ist immer ein $db->set_charset("utf8"); _und_ ich habe auch noch eine .htaccess-datei mit einem AddType text/html;charset=UTF-8 .htm und einem AddType text/css;charset=UTF-8 .css für alle Ordner. Das ist, soweit ich das sehe, alles, was ich tun kann (und soll). Richtig? Oder habe ich auf etwas vergessen bzw. dabei etwas nicht gut gemacht?

OK, dann habe ich durch das Forum gelernt, ich soll, wenn ich eine Mail mit PHP versenden will, dies _so_ tun:

<?php  
 header("Content-type:text/html;charset=utf-8");  
 error_reporting(E_ALL | E_STRICT);  
?>  
  
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">  
  
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">  
  
 <head>  
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />  
  <title>Mailtest</title>  
 </head>  
  
 <body>  
  <?php  
   $empfaenger="[e-mail]";  
   $betreff="Bitte bestätigen Sie Ihren Gästebucheintrag";  
   $text="Hänsel und Gretel wünschen sich Hörnchen über alles.";  
   $header="";  
   $header.="MIME-Version: 1.0\n";  
   $header.="Content-type: text/plain; charset=utf-8\n";  
   $header.="Content-Transfer-Encoding: 8bit\n";  
   $header.="From: Max Mustermann <[e-mail]>\n";  
   mail($empfaenger,utf8_decode($betreff),$text,$header, "[e-mail]");  
  ?>  
 </body>  
  
</html>

Das Ganze speichere ich ab als mailtest.php, utf-8 codiert, ohne BOM. Nun meine Fragen:

1.) Zunächst mal: _Ist_ das jetzt richtig so oder nicht?

2.) Wenn ich das alles so mache, wie oben beschrieben, ist auf jeden Fall mal der Inhalt der Mail utf-8-codiert, oder?

3.) Woran kann es dann liegen, dass ein Webmailprovider bei der Anzeige des Inhalts Umlaute trotzdem nicht richtig darstellt? Ich dachte immer, man verwendet utf-8 gerade deshalb, _damit_ es nicht zu solchen Problemen kommt?

4.) Wenn ich das alles so mache, wie oben beschrieben, dann ist doch der Betreff durch das utf8_decode($betreff) _nicht_ utf-8 codiert - zumindest hatte ich das angenommen. Ich nehme an, das ist mal falsch, oder?

5.) Um bei obigem Beispiel zu bleiben, wie _genau_ müßte dann die Zeile, die das Versenden bewirkt _anders_ aussehen als mail($empfaenger,utf8_decode($betreff),$text,$header, "[e-mail]"); ?

6.) Da ich kein PHP-Profi bin und, wie schon gesagt, immer schon Verständnisschwierigkeiten mit Allem, was mit Codierung, Mimetype, etc. zu tun hat, hatte, verstehe ich die angebotene Funktion mb_encode_mimeheader nicht ganz. Die dient dazu, dass der Header _nur_ durch US-ASCII-Zeichen übermittelt wird und würde mir ein $betreff="Bitte bestätigen Sie Ihren Gästebucheintrag"; automatisch umformen? Wie genau muß ich das einbauen? (Siehe Frage 5)

7.) Wenn ich also eine Text-Mail mit dem Betreff "Bitte bestätigen Sie Ihren Gästebucheintrag" und dem Inhalt "Hänsel und Gretel wünschen sich Hörnchen über alles." versenden möchte und will, daß die Umlaute sowohl im Header als auch im Inhalt richtig dargestellt werden, dann soll ich _doch nicht_ mit utf-8 arbeiten? Was ist denn nun die Standardlösung?

Ich hatte mit dieser Thematik immer schon leichte Probleme, hatte das Gefühl, das Wesentliche verstanden zu haben - aber seit meinen Tests gestern und dem bisherigen Verlauf dieses Threads bin ich noch verunsicherter und dümmer als vorher. Dabei würd ich das wirklich gerne richtig und ordentlich lernen - und auch richtig und ordentlichen Code schreiben, der ein gewünschtes Ergebnis bringt.

*verzweifelt schaue* =..(

MfG

Der Brombeermilchtrinker

[Vinzenz Mai]

Hallo,

OK, dann habe ich durch das Forum gelernt, ich soll, wenn ich eine Mail mit PHP versenden will, dies _so_ tun:

<?php
   $empfaenger="[e-mail]";
   $betreff="Bitte bestätigen Sie Ihren Gästebucheintrag";
   mail($empfaenger,utf8_decode($betreff),$text,$header, "[e-mail]");

Das Ganze speichere ich ab als mailtest.php, utf-8 codiert, ohne BOM. Nun meine Fragen:

1.) Zunächst mal: _Ist_ das jetzt richtig so oder nicht?

Nein.

4.) Wenn ich das alles so mache, wie oben beschrieben, dann ist doch der Betreff durch das utf8_decode($betreff) _nicht_ utf-8 codiert - zumindest hatte ich das angenommen. Ich nehme an, das ist mal falsch, oder?

Ja. Was macht utf8_decode(), wenn es so aufgerufen wird, wie Du es hier machst: Es wandelt den Inhalt von $betreff von UTF-8 in ISO-8859-1 um. Damit hast Du *nichts* gewonnen. Ob UTF-8 oder ISO-8859-1 ist hier wurscht, wenn es um Sonderzeichen geht. Also bleib' zuerst mal bei UTF-8.

Sind Sonderzeichen wie das "ä" in Deinem Beispiel im Mailbetreff zulässig?
Nein.

Wie können sie korrekt codiert werden?
a) Quoted Printable
b) base64

Welche Funktion kann dies für uns erledigen?
Die von mir verlinkte mb_encode_mimeheader.

Was bewirkt bei Deinem Beispiel:

mb_encode_mimeheader($betreff, "UTF-8", "Q")

Schau's Dir an.

7.) Wenn ich also eine Text-Mail mit dem Betreff "Bitte bestätigen Sie Ihren Gästebucheintrag" und dem Inhalt "Hänsel und Gretel wünschen sich Hörnchen über alles." versenden möchte und will, daß die Umlaute sowohl im Header als auch im Inhalt richtig dargestellt werden, dann soll ich _doch nicht_ mit utf-8 arbeiten? Was ist denn nun die Standardlösung?

Doch natürlich. Bleib' bei UTF-8. Nur denke daran, dass Du in den Mail-Headern kein UTF-8 verwenden darfst, sondern nur 7-Bit-ASCII. Das ist ein Protokollproblem, kein UTF-8-Problem und soll kein Widerspruch sein.

Netterweise gibt es eine Encodiervorschrift, mit der man UTF-8 in Mailheadern verwenden kann. Der Zwischenschritt mit utf8_decode ist nicht nur überflüssig, sondern sogar kontraproduktiv, wenn Zeichen enthalten sind, die in ISO-8859-1 nicht enthalten sind. Beispiel gefällig: ISO-8859-1 enthält *kein* Eurozeichen.

Übrigens ist der Betreff-Header-Body nicht der einzige, der so behandelt werden muss. Es gilt für jeden Header-Body, zum Beispiel auch für die Empfänger-Adresse:

"Jürgen Mustermann-Weiß" [e-mail]

Freundliche Grüße

Vinzenz

[Brombeermilchtrinker]

Hi Vinzenz,

Aha, also ich muß sowohl beim Empfänger, als auch beim Betreff die mb_encode_mimeheader-Funktion verwenden. Um bei Deinem "Mustarmann-Weiß" Beispiel zu bleiben, wäre der Code also _so_ richtig? ==>

<?php  
 header("Content-type:text/html;charset=utf-8");  
 error_reporting(E_ALL | E_STRICT);  
?>  
  
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">  
  
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">  
  
 <head>  
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />  
  <title>Mailtest</title>  
 </head>  
  
 <body>  
  <?php  
   $empfaenger="Jürgen Mustermann-Weiß <[e-mail]>";  
   $betreff="Bitte bestätigen Sie Ihren Gästebucheintrag";  
   $text="Hänsel und Gretel wünschen sich Hörnchen über alles.";  
   $header="";  
   $header.="MIME-Version: 1.0\n";  
   $header.="Content-type: text/plain; charset=utf-8\n";  
   $header.="Content-Transfer-Encoding: 8bit\n";  
   $header.="From: Max Mustermann <[e-mail]>\n";  
   mail(mb_encode_mimeheader($empfaenger, "UTF-8", "Q"),mb_encode_mimeheader($betreff, "UTF-8", "Q"),$text,$header, "[e-mail]");  
  ?>  
 </body>  
  
</html>

Oder hab ich das falsch verstenden? Weißt Du auf meine anderen Fragen aus meinem letzten Posting auch Rat?

Danke übrigens für die Hilfe!

MfG

Der Brombeermilchtrinker

[Brombeermilchtrinker]

Nachtzrag zu meinem letzten Posting:

Wenn ich es so mache wie im letzten Posting beschrieben, kommt _überhaupt nichts_ an.

Wenn ich es _so_ mache =>

  
$empfaenger="Jürgen Mustermann-Weiß <[e-mail]>","UTF-8", "Q");  
$betreff=mb_encode_mimeheader("Bitte bestätigen Sie Ihren Gästebucheintrag mailtest5 ","UTF-8", "Q");  
$text="Hänsel und Gretel wünschen sich Hörnchen über alles.";  
$header="";  
$header.="MIME-Version: 1.0\n";  
$header.="Content-type: text/plain; charset=utf-8\n";  
$header.="Content-Transfer-Encoding: 8bit\n";  
$header.="From: Max Mustermann <[e-mail]>\n";  
mail ($empfaenger,$betreff,$text,$header, "[e-mail]");

dann kommt zwar was an, allerdings steht jetzt beim Betreff: Bitte bestätigen Sie Ihren Gästebucheintrag - also VÖLLIGES Chaos, selbiges beim Namen des Empfängers, auch dort eine Falschdarstellung.

Ich stelle fest, je mehr ich versuche, um so weniger klappt es. =(((

[Harlequin]

Yerf!

dann kommt zwar was an, allerdings steht jetzt beim Betreff: Bitte bestätigen Sie Ihren Gästebucheintrag - also VÖLLIGES Chaos, selbiges beim Namen des Empfängers, auch dort eine Falschdarstellung.

Nicht völliges Chaos, sondern eine Verwechslung von UTF-8 und ISO. Der oberste Kommentar auf der Handbuchseite von mb_encode_mimeheader könnte die Lösung sein. Vermutlich ist mbstring.internal_encoding nicht richtig gesetzt.

Ich seh grad, der 3. Kommentar bestätigt es: "Before you use mb_encode_mimeheader with UTF-8 set mb_internal_encoding('UTF-8')."

Gruß,

Harlequin

[Sven Rautenberg]

Moin!

Nicht völliges Chaos, sondern eine Verwechslung von UTF-8 und ISO. Der oberste Kommentar auf der Handbuchseite von mb_encode_mimeheader könnte die Lösung sein. Vermutlich ist mbstring.internal_encoding nicht richtig gesetzt.

Ich seh grad, der 3. Kommentar bestätigt es: "Before you use mb_encode_mimeheader with UTF-8 set mb_internal_encoding('UTF-8')."

Außerdem ist es ungünstig, die Mailadresse auf diese Weise zu codieren (dort kommt sowieso nur ASCII drin vor), das mag der Mailserver wahrscheinlich nicht. Zu codieren ist ausschließlich der Benutzername. Siehe dazu auch das Beispiel Nr. 1 auf der Handbuchseite.

- Sven Rautenberg

[Brombeermilchtrinker]

Hi Harlequin,

Nicht völliges Chaos, sondern eine Verwechslung von UTF-8 und ISO. Der oberste Kommentar auf der Handbuchseite von mb_encode_mimeheader könnte die Lösung sein. Vermutlich ist mbstring.internal_encoding nicht richtig gesetzt.
Ich seh grad, der 3. Kommentar bestätigt es: "Before you use mb_encode_mimeheader with UTF-8 set mb_internal_encoding('UTF-8')."

Das bringt mich auch nicht weiter. Leider. Das bereinigt zwar die Darstellungsfehler des Betreffs, nicht aber die im Namen des Empfängers.

Nur so nebenbei, weil mir das einfach grad so im Kopf herumgeistert: Wieso gibt es eigentlich für so eine simple Drecksaufgabe wie das Versenden einer beschissenen Mail nicht eine einzige seriöse Seite im Netz, wo das _verständlich_ erklärt wird und ein funktionierender Code steht. Ich mach jetzt seit 2 Tagen nichts anderes, als hunderte von Seiten und Postings zu lesen, überall steht was anderes, oder immer nur ein par Worte, oder Verweise zu Seiten, wo ich 10 Minuten vorher schon war - oder ein Technik-Sprech, das ein normaler Mensch nicht mal mit 2 Promill im Blut verstehen würde. Mir reicht das schon so, das _kann doch nicht sein_ , daß das so kompliziert und unlösbar ist ?!?!?!? Ich weiß bald nicht mehr, ob ich heulen soll oder diesen Dreckscomputer beim Fenster rauswerfen soll.

Das _einzige_, das ich will ist, eine utf-8 codierte php Ressource, die mir eine Mail mit dem Betreff "Gästebuchaktivierung für Dich" und dem Inhalt "Hänsel und Gretel wünschen sich Hörnchen über alles." an die Adresse "Jürgen Mustermann-Weiß [e-mail]" und mit dem Absender "Björn Testmann [e-mail]" versendet.

ALso:

$absender="Björn Testmann <[e-mail]>";  
$empfaenger="Jürgen Mustermann-Weiß <[e-mail]>";  
$betreff="Gästebuchaktivierung für Dich";  
$inhalt="Hänsel und Gretel wünschen sich Hörnchen über alles.";

Da muß es doch einen simplen php-Code geben, um diese lächerliche Mail verschicken zu können, und zwar so, daß einfach _alle_ in der Mail vorkommende Umlaute und Sonderzeichen richtig dargestellt werden.

Der Brombeermilchtrinker

[Jens Holzkämper]

Tach,

Nur so nebenbei, weil mir das einfach grad so im Kopf herumgeistert: Wieso gibt es eigentlich für so eine simple Drecksaufgabe wie das Versenden einer beschissenen Mail nicht eine einzige seriöse Seite im Netz, wo das _verständlich_ erklärt wird und ein funktionierender Code steht. Ich mach jetzt seit 2 Tagen nichts anderes, als hunderte von Seiten und Postings zu lesen, überall steht was anderes, oder immer nur ein par Worte, oder Verweise zu Seiten, wo ich 10 Minuten vorher schon war - oder ein Technik-Sprech, das ein normaler Mensch nicht mal mit 2 Promill im Blut verstehen würde. Mir reicht das schon so, das _kann doch nicht sein_ , daß das so kompliziert und unlösbar ist ?!?!?!? Ich weiß bald nicht mehr, ob ich heulen soll oder diesen Dreckscomputer beim Fenster rauswerfen soll.

hast du schonmal darüber nachgedacht, dass der Verständnisfehler nicht bei "hunderten" von Autoren sondern auf deiner Seite liegen könnte?

Da muß es doch einen simplen php-Code geben, um diese lächerliche Mail verschicken zu können, und zwar so, daß einfach _alle_ in der Mail vorkommende Umlaute und Sonderzeichen richtig dargestellt werden.

Gibt es, der Name der Funktion wurde von mir in diesem Thread bereits erwähnt.

mfg
Woodfighter

[Brombeermilchtrinker]

Hi,

hast du schonmal darüber nachgedacht, dass der Verständnisfehler nicht bei "hunderten" von Autoren sondern auf deiner Seite liegen könnte?

selbstverständlich liegt der bei mir. Das Problem ist nur, daß Leute, die die Thematik verstehen in ihren Erklärungen davon ausgehen, daß das Gegenüber ein genau so gutes und großes grundlegendes Wissen und Verständnis hat wie sie. Leider ist dem so nicht und deshalb hilft oft auch der 100. Hinweis auf iregnd eine Seite eines Manuals nichts. Und das schlimmste daran ist, daß diese Tatsache von eben angesprochenen leuten nicht mal nachvollzogen werden kann, wenn man es ausspricht.

Das ist ungefähr so, als ob ich (mit Medizinausbildung) Dir erkläre, wieso der Hämatokrit bei großem, plötzlichen Blutverlust zB. nach einem Unfall unlogischerweise _steigt_. Das kann ich auch so machen, daß ich es zwar richtig erkläre, Du aber von vorne bis hinten nur Bahnhof verstehst und am Ende _noch_ verwirrter bist.

Gibt es, der Name der Funktion wurde von mir in diesem Thread bereits erwähnt.

Und _ich_ habe seit der Eröffnung dieses Threats jetzt schon mehrmals erwähnt, daß ich nicht weiterkomme und die genannten Links entweder nicht verstehe bzw. die mir nicht weiterhelfen.

Ich gehöre _ganz bestimmt_ nicht zu der Sorte von Leuten, die hier her kommen, nach Code fragen, den ohne zu hinterfragen übernmehmen, ihn nicht mal verstehen wollen und wieder gehen. Aber ich komm einfach nicht mehr weiter. Wieso kann mir denn _ B I T T E _ keiner hier einfach den Code hinschreiben, um aus

$absender="Björn Testmann <[e-mail]>";  
$empfaenger="Jürgen Mustermann-Weiß <[e-mail]>";  
$betreff="Gästebuchaktivierung für Dich";  
$inhalt="Hänsel und Gretel wünschen sich Hörnchen über alles.";

einen Mailversand zu machen????

Oder bekomme ich jetzt erst Recht wieder einen Link zu einer Manuelseite? =(

MfG

Der Brombeermilchtrinker

[Jens Holzkämper]

Tach,

Das ist ungefähr so, als ob ich (mit Medizinausbildung) Dir erkläre, wieso der Hämatokrit bei großem, plötzlichen Blutverlust zB. nach einem Unfall unlogischerweise _steigt_.

ich schätze mal der Körper merkt, dass Blut fehlt und kurbelt die Produktion von Blutkörperchen an, der Flüssigkeitsverlust durch den Blutverlust wurde noch nicht ausgeglichen und zusätzliche Flüssigkeit auch noch nicht

Gibt es, der Name der Funktion wurde von mir in diesem Thread bereits erwähnt.

Und _ich_ habe seit der Eröffnung dieses Threats jetzt schon mehrmals erwähnt, daß ich nicht weiterkomme und die genannten Links entweder nicht verstehe bzw. die mir nicht weiterhelfen.

Dann mußt du entweder an deinen Grundlagen arbeiten oder jemanden bezahlen, der dein Problem für dich löst.

Ich gehöre _ganz bestimmt_ nicht zu der Sorte von Leuten, die hier her kommen, nach Code fragen, den ohne zu hinterfragen übernmehmen, ihn nicht mal verstehen wollen und wieder gehen. Aber ich komm einfach nicht mehr weiter. Wieso kann mir denn _ B I T T E _ keiner hier einfach den Code hinschreiben, um aus [...] einen Mailversand zu machen????

Wenn ich dir den Code poste, was andere meiner Meinung nach bereits getan haben, wirst du trotzdem nicht verstehen, um was es geht und damit zwangsweise Code ohne ihn zu hinterfragen kopieren.

mfg
Woodfighter

[Markus**]

Das liegt an dem Mime-Type der Textarea.
Siehe http://de.selfhtml.org/html/formulare/eingabe.htm@title=hier und hier und http://de.selfhtml.org/html/referenz/attribute.htm#textarea@title=hier

[Brombeermilchtrinker]

Hallo Forum,

nachdem ich trotz wirklich unzähliger Versuche noch immer nicht weitergekommen bin und einfach nicht schaffe, was ich erreichen möchte, bitte ich erneut um Eure Hilfe und bitte darum, das mir hier jemand sagt, wie der php-Code lautet, der mir aus

$absender="Björn Testmann <[e-mail]>";  
$empfaenger="Jürgen Mustermann-Weiß <[e-mail]>";  
$betreff="Gästebuchaktivierung für Dich";  
$inhalt="Hänsel und Gretel wünschen sich Hörnchen über alles.";

einen Mailversand macht, bei dem in der ankommenden Mail sowohl im Betreff, als auch im Mailinhalt sowie bei den Namen von Empfänger und Absender alle Umlaute/SOnderzeichen richtig dargestellt werden.

Ich habe jetzt mehrere Tage lang nichts anderes gemacht, als alle mir bisher geposteten Links zu lesen und die genannten Funktionen durchzuprobieren.

Wenn ich den richtigen PHP-Zeilen vor mir hätte, dann wüßte ich auch, was ich Schritt für Schritt lernen und verstehen muß, damit es funktioniert. Aber ich weiß schon nicht mehr, was ich noch tun soll, wonach ich noch suchen soll, was ich noch anders versuchen soll. Sollte es hier also auch noch leute geben, die gerne helfen und nicht, so wie ein anderer User, die göttliche Entscheidung treffen, dass sie die Lösung zwar wissen, sie aber absichtlich nicht verraten, weil ich mich dann angeblich nicht mehr damit beschäftige bzw. mir empfehlen, ich solle doch wen bezahlen, der mein Problem löst, dann appelliere ich an diese, mich hier ein Stück zu begleiten (und mir jetzt nicht wieder einen LInk zu einer Seite des php-Manuals zu setzen).

Damit ich also endlich lernen kann und verstehen kann, wie man aus oben genannten 4 Informationen _richtig_ eine Mail versenden kann, bitte ich nochmals um den dafür zuständigen PHP-Code, den ich im Anschluß dann gerne Zeile für Zeile bzw. Funktion für Funktion durchbesprechen möchte.

Vielen Dank.

Der Brombeermilchtrinker

[dedlfix]

echo $begrüßung;

nachdem ich trotz wirklich unzähliger Versuche noch immer nicht weitergekommen bin

Wir™ wissen nicht, was du bisher erreicht hast und was deine derzeitigen (Rest-)Probleme sind. Vielleicht machst du schon alles richtig, nur die Empfänger sind zu doof, um standardisierte Mails ordnungsgemäß zu interpretieren.

und einfach nicht schaffe, was ich erreichen möchte, bitte ich erneut um Eure Hilfe und bitte darum, das mir hier jemand sagt, wie der php-Code lautet, der mir aus

Der wurde dir schon gesagt. Hier nochmal in Zusammenfassung:

Fangen wir mit dem einfachen Teil an.

$inhalt="Hänsel und Gretel wünschen sich Hörnchen über alles.";

Das ist der Mailinhalt. Dieser kann kodiert sein wie er will, solange diese verwendete Kodierung in der Header-Zeile namens Content-Type angegeben ist. Das dürftest du schon hinbekommen haben.

$absender="Björn Testmann [e-mail]";
$empfaenger="Jürgen Mustermann-Weiß [e-mail]";
$betreff="Gästebuchaktivierung für Dich";

Absender, Empfänger und Betreff sind Header-Zeilen. Header-Zeilen müssen auch dann richtig interpretiert werden können, wenn die Content-Type-Zeile noch nicht ausgewertet wurde oder fehlt. Außerdem heißt "Content" Inhalt und nicht Verpackung, also ist die dortige charset-Angabe auch gar nicht für die Headerzeilen zuständig. Der Standard sieht vor, dass bei Bedarf jede Headerzeile einzeln nach dem dir bekannten Muster zu kodieren ist.

Die Betreffzeile kannst du komplett mit der bereits genannten mb_...-Funktion behandeln. Bei Absender und Empfänger musst du zunächst den Namen und die Mailadresse trennen oder am besten gleich getrennt vorliegen haben. Die Mailadresse bleibt wie sie ist, der Name wird mit der mb_...-Funktion behandelt. Anschließend setzt du den behandelten Namen und die Mail-Adresse mit Leerzeichen dazwischen zusammen.

Hast du weitere Headerzeilen (außer To und Subject) setzt du diese wie im Handbuch zu mail() - Parameter additional_headers beschreiben mit einem Zeilenumbruch (\n oder \r\n [1]) zusammen.

Den mail()-Aufruf bekommst du nun sicher auch ohne weitere Hilfe hin.

einen Mailversand macht, bei dem in der ankommenden Mail sowohl im Betreff, als auch im Mailinhalt sowie bei den Namen von Empfänger und Absender alle Umlaute/SOnderzeichen richtig dargestellt werden.

Wie gesagt, auf den Empfänger hast du keinen Einfluss. Du kannst nur alles richtig machen oder für bestimmte bekannte Fehler einiger Empfänger einen Workaround finden. Das bedeutet aber oftmals eine Beschränkung auf ISO-8859-1.

Damit ich also endlich lernen kann und verstehen kann, wie man aus oben genannten 4 Informationen _richtig_ eine Mail versenden kann, bitte ich nochmals um den dafür zuständigen PHP-Code, den ich im Anschluß dann gerne Zeile für Zeile bzw. Funktion für Funktion durchbesprechen möchte.

Dann setze nun bitte aus den gegebenen Informationen einen Quelltext zusammen, den wir™ dir dann gern auseinandernehmen. Außerdem wäre es hilfreich, die von dir verwendeten (Beispiel-)Werte im Originalzustand nebst der Nennung der von dir verwendeten Kodierung sowie ihren Zustand beim Übergeben an mail() anzuführen. Und wenn du dann noch die Headerzeilen anführst, wie sie beim Client ankommen (gekürzt auf das Wesentliche - Received- und X-Zeilen sind beispielsweise uninteressant) wäre das auch nicht schlecht.

Die folgende Fußnote ist nur der Vollständigkeit halber enthalten. Du kannst sie gern ignorieren, sie trägt zu deinem Problem und dessen Lösung nichts weiter bei.

[1] Die RFC verlangt \r\n, doch eigentlich ist es Aufgabe des Mail-Sendeprogramms, die auf dem Betriebssystem üblichen Zeilenumbrüche standardkonform zu kodieren. Man kann getrost die additional_header-Zeilen nur mit einem \n verbinden, denn mail() selbst verwendet intern auch nur \n beim Zusammenfügen der Header mit Subject und dem Body. Wenn also ein \n Probleme bereiten sollte, so sind mail()-seidank garantiert welche drin. Es lohnt sich demzufolge nicht, unbedingt standardkonforme \r\n zu verwenden.

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Hi Dedlfix,

Dann setze nun bitte aus den gegebenen Informationen einen Quelltext zusammen, den wir™ dir dann gern auseinandernehmen. Außerdem wäre es hilfreich, die von dir verwendeten (Beispiel-)Werte im Originalzustand nebst der Nennung der von dir verwendeten Kodierung sowie ihren Zustand beim Übergeben an mail() anzuführen. Und wenn du dann noch die Headerzeilen anführst, wie sie beim Client ankommen (gekürzt auf das Wesentliche - Received- und X-Zeilen sind beispielsweise uninteressant) wäre das auch nicht schlecht.

Dieses Angebot nehme ich _gerne_ an. Leider bin ich _frühestens_ am Montag wieder in der Lage, ins Internet "zu kommen" und dieser Thread ist bis dahin wahrscheinlich im Archiv.

Ich werde jetzt _nochmals_ alle Antworten durchgehen, alle Links besuchen und dann, wie von Dir vorgeschlagen, mein derzeitiges Ergebnis posten. Also sowohl meinen Quellcode für die php-Ressource, als auch die Mailergebnisse, die selbiger liefert.

Sobald ich dann durch Dich/Forum weiß, dass es so, wie ich es gemacht habe richtig ist und eventuelle Darstellungsfehler nicht an "meiner Schuld" liegen, würde ich dann _trotzdem_ noch sehr sehr gerne Dein Angebot annehmen und Zeile für Zeile den PHP-Code durchgehen, weil ich das wirklich gerne verstehn würde. [1]

Halte also bitte Ausschau nach dem Thread "Zerlegung und Analyse einer mail() Funktion" und meinem Namen dabei. ;-)

Schönes Wochenende!

Der Brombeermilchtrinker

[1] Vielleicht könenn wir diese Gelegenheit ja dann auch gleich dazu nutzen, mein Basisverständnis über Codierung und utf-8 zu überprüfen bzw. zu korrigieren, fall Du die Zeit und Geduld dafür aufbringst.

[dedlfix]

echo $begrüßung;

Dieses Angebot nehme ich _gerne_ an. Leider bin ich _frühestens_ am Montag wieder in der Lage, ins Internet "zu kommen" und dieser Thread ist bis dahin wahrscheinlich im Archiv.

Nein, so schnell geht das nicht. Soweit ich weiß, lungert ein Thread üblicherweise noch mindestens drei Tage nach der letzten Aktivität hier rum, bevor ihn ein Automatismus wegen Inaktivität ins Archiv verschiebt.

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Hi dedlfix,

Nein, so schnell geht das nicht. Soweit ich weiß, lungert ein Thread üblicherweise noch mindestens drei Tage nach der letzten Aktivität hier rum, bevor ihn ein Automatismus wegen Inaktivität ins Archiv verschiebt.

Stimmt, er ist noch da. Na dann mal los:

Auf Grund unzähliger Beiträge aus dem Archiv, unter anderem auch _viele_ von Dir, habe ich folgende Grundvoraussetzungen:

1.) _Alle_ meine html-Ressourcen besitzen eine "<meta http-equiv="content-type" content="text/html; charset=utf-8" />" Angabe.
2.) In _all_ meinen Formularen steht bei der Formulardefinition eine "accept-charset="utf-8""Angabe.
3.) _Alle_ meine php-Ressourcen besitzen eine "header("Content-type:text/html;charset=utf-8");" Angabe.
4.) _Alle_ meine css-Ressourcen beginnen mit einer "@charset "utf-8";" Angabe.
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.
6.) _Alle_ von mir geschriebenen Ressourcen, egal, ob php, css oder html werden mit dem Notepad++ Editor geschrieben und unter/mit dem Format "UTF-8 ohne BOM" gespeichert.
7.) Und letztendlich stehen in meiner .htaccess-Datei auch noch die Angaben "AddType text/html;charset=UTF-8 .htm" und "AddType text/css;charset=UTF-8 .css"

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?

Nun zu den gegebenen Tips und Links bezüglich meines Problems. Ich habe mich jetzt nochmals damit beschäftigt, hier ist mein derzeitiger Ergebnisstand:

Das Ziel ist der Versand einer Mail an Jürgen Mustermann-Weiß mit der Mailadresse "[e-mail]" vom Absender Jörg Mustermann-Spär mit der Mailadresse "[e-mail]". Der Betreff soll "Bestellbestätigung Ihrer 3 Wunschkühe" lauten und der Inhalt der Mail soll folgendermaßen aussehen:

Sehr geehrter Herr Mustermann-Weiß,

bitte bestätigen Sie uns noch Ihre Bestellung der 3 Kühe Björn, Gülle und Agnätha.

MfG

Jörg Mustarmann-Spär

Dazu habe ich nun folgenden PHP-Code:

<?php  
 header("Content-type:text/html;charset=utf-8");  
 error_reporting(E_ALL | E_STRICT);  
?>  
  
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">  
  
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">  
  
 <head>  
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />  
  <title>Mailtest</title>  
 </head>  
  
 <body>  
  <?php  
   // Folgende Angabe wurde mir empfohlen (Ohne diese Angabe der hatte ich _mehr_ Probleme):  
   mb_internal_encoding('UTF-8');  
   // Ich definiere die Ausgangsinformationen:  
   $empfaenger_name="Jürgen Mustermann-Weiß";  
   $empfaenger_adresse="[e-mail]";  
   $sender_name="Jörg Mustermann-Spär";  
   $sender_adresse="[e-mail]";  
   $betreff="Bestellbestätigung Ihrer 3 Wunschkühe";  
   $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";  
   // Ich verwende, wie von dedlfix empfohlen, die Funktion  
"mb_encode_mimeheader" für die Namen von Emfänger und Absender:  
   $empfaenger_name=mb_encode_mimeheader($empfaenger_name, "UTF-8", "Q");  
   $sender_name=mb_encode_mimeheader($sender_name, "UTF-8", "Q");  
   // Für Absender und Empfänger werden jetzt Namen und Mailadresse für die Form "Vorname Familienname < name@url >" zusammengesetzt:  
   $empfaenger=$empfaenger_name." <".$empfaenger_adresse.">";  
   $sender=$sender_name." <".$sender_adresse.">";  
   // Auch für den Betreff verwende ich die mb_encode_mimeheader-Funktion:  
   $betreff=mb_encode_mimeheader($betreff, "UTF-8", "Q");  
   // Der Rest bleibt, wie von Anfang an gehabt:  
   $header="";  
   $header.="MIME-Version: 1.0\n";  
   $header.="Content-type: text/plain; charset=utf-8\n";  
   $header.="Content-Transfer-Encoding: 8bit\n";  
   $header.="From: ".$sender."\n";  
   mail ($empfaenger,$betreff,$mailinhalt,$header, "[e-mail]");  
  ?>  
 </body>  
  
</html>

Das führ zu Folgenden Ergebnissen:

Bei gmx.de steht als Absender: Jörg Mustermann-Spär [e-mail], als Empfänger: Jürgen Mustermann-Weiß [e-mail], als Betreff "Bestellbestätigung Ihrer 3 Wunschkühe" und auch der Mailinhalt ist genau so, wie er oben als Ziel steht. Bei gmx werden also sowohl im Namen des Empfängers, des Senders als auch im Mailbetreff, als in _allen_ Headerangaben _und_ im Mailinhalt nun alle Umlaute/Sonderzeichen _richtig_ dargestellt.

Bei der Webmailapplikation meines Webspace-Providers domainfactory.de das selbe Ergebnis. Alle Zeichen, sowohl bei Absender, als auch bei Empfänger sowie in der Mail selbst werden richtig dargestellt. Hier ist mir allerdings etwas anderes Suspektes aufgefallen. Bei meinen Versuchen habe ich jede Veränderung des Codes extra abgespeichert und auch die Mailversuche nummeriert, um den Überblick zu behalten. Bei meinen Tests gab es also zB den Betreff "Bestellbestätigung Ihrer 3 Wunschkühe - Mailtest 003". Dieser Betreff wurde bei gmx wirklich genau so dargestellt, bei meinem Webmailverwaltung sieht man _1_ Abstandzeichen nach dem großen M des Wortes "Mailtest 003". Da steht also als Betreff: "Bestellbestätigung Ihrer 3 Wunschkühe - M ailtest 003". Woran das liegt, ist mir unerklärlich.

Bei hotmail.com wieder _alles_ richtig, auch kein Abstand beim "Mailtest 003" im Betreff.

Bei yahoo.de ein _sehr_ seltsames Verhalten. Alle Sonderzeichen werden richtig dargestellt, allerdings gibt es in der Mail selbst _keine_ Zeilenumbrüche. Da steht in einer Wurst ein "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" geschrieben.

Bei cooltad.com, einem Freemailprovider, das _absolute_ Chaos: 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?=" 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".

Liegen die genannten Darstellungsfehler an mir? Hätte ich etwas anders/besser machen können, um _überall_ mein Wunschresultat zu bekomen? Oder ist der PHP-Code, so wie oben gepostet, in Ordnung und kann als Standardbeispiel verwendet werden? Ich nehme an, beim letzten Testbeispiel liegt es nicht an mir. Aber was mich mehr stört, ist das Weglassen der Zeilenumbrüche bei yahoo.

Sobald die Frage, ob mein Code jetzt so in Ordnung ist,  mit JA beantwortet werden kann, würde ich dann gerne den Thread fortführen und die einzelnen Zeilen, also PHP-Anweisung für Anweisung durchbesprechen.

Mit freundlichsten Grüßen

Der Brombeermilchtrinker

[dedlfix]

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";

[at]

Hallo.

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.

Für Eigenschaften stimmt das sicher, aber auch für Klassenbezeichnungen.? Die dürfen doch in HTML alle Zeichen des verwendeten Zeichensatzes verwenden, bei UTF-8 also alle damit codierbaren Unicode-Zeichen. In CSS wiederum sollten die Angaben innerhalb der Selektoren der Schreibweise im HTML entsprechen, womit die Sonderzeichen auch im CSS stünden. -- Man beachte den Konjunktiv, der die praktische Relevanz meiner Aussage einordnet.
MfG, at

[Brombeermilchtrinker]

Hi dedlfix,

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.

Na dann bleib ich vorsichtshalber lieber dabei.

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.

Na dann bleib ich vorsichtshalber auch hier lieber dabei.

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.

Dann könnte ich das eigentlich in meine ausgelagerte db_verbindung.php, in der Hostadresse, Namen und Paßwort stehen, dazugeben, nachdem die Verbindung da ist.

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.

Jetzt verwirrst Du mich. _Du selbst_ hast doch in unzähligen Postings immer wieder betont, daß nicht die Kollation der Datenbankfelder wichtig ist, sondern die Information, die der Server mittels dem $db->set_charset() bzw. mittels ~~~php mysql_set_character_set()

  

> 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.  
  
Ich habe jetzt alle \r durch \n ersetzt.  
  

> > 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.  
  
Richtig. Seit ich die \r durch \n ersetzt habe, macht auch die Ausgabe der yahoo-Webmail Seite die zeilenumbrüche so wie erwünscht.  
  

> > 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.  
  
Sehr gut, dann habe ich somit mal einen guten PHP-Code. Den würd ich jetzt gerne noch Zeile für Zeile durchgehen:  
  
`mb_internal_encoding('UTF-8');`{:.language-php}  
  
Also wofür \_das\_ gut ist, ist mir trotz PHP-Manual ein Rätsel. Die Informaton, daß alle Zeichen, die zur Datenbank gesendet werden, utf-8 codiert kommen werden, liefert mir ja schon mein `$db->set_charset("utf8")`{:.language-php}. Also wozu ich das jetzt nochmals angeben muß, verstehe ich nicht.  
  
Dann kommt die Festlegung der Variablen mit den Inhalten wie Name, Mail, etc - das ist natürlich klar.  
  
`$empfaenger_name=mb_encode_mimeheader($empfaenger_name, "UTF-8", "Q");`{:.language-php}  
  
OK, da steht im Manual: "transfer\_encoding  specifies the scheme of MIME encoding. It should be either "B" (Base64) or "Q" (Quoted-Printable). Falls back to "B" if not given." Heißt das jetzt: Wandle $empfaenger\_name von utf-8 nach Quoted-Printable um? Was heißt Quoted-Printable? Was ist der Unterscheid zu Base64? Und vor allem: Wieso muß ich jetzt \_schon wieder\_ mitteilen, daß die Ausgangssituation utf-8 ist?  
  
Dann wird der Header mittels Verkettungsoperator zusammengebaut.  
  
`$header.="MIME-Version: 1.0\n";`{:.language-php}  
  
Kann man in \_einfachen Worten\_ verständlich erklären, was diese (manchmal als optional, aber besser gegebene) Angabe heißt/bewirkt?  
  
`$header.="Content-type: text/plain; charset=utf-8\n";`{:.language-php}  
  
Hier wird dem empgangenden Swerver mitgeteilt, daß alle zeichen innerhalb der Mail, also der Mailinhalt, utf-8 codiert sind und es sich um eine reine Textmail handelt.  
  
`$header.="Content-Transfer-Encoding: 8bit\n";`{:.language-php}  
  
Und wozu dann noch das? Was bewirkt diese Zeile?  
  
`mail ($empfaenger,$betreff,$mailinhalt,$header, "[e-mail]");`{:.language-php}  
  
Hier habe ich festgestellt, daß keine Mail verschickt wird, wenn ich \_keine\_ -f Angabe mache. Wieso? Und was ist der Unterschied zwischen der -f Mailadresse und der Adresse hinter dem From: ? Beide sagen doch dem empfangenden Server, von wem die Mail kommt bzw. an wen zu antworten ist, oder?  
  
Mit freundlichen Grüßen  
  
Der Brombeermilchtrinker

[Harlequin]

Yerf!

mb_internal_encoding('UTF-8');

Also wofür _das_ gut ist, ist mir trotz PHP-Manual ein Rätsel. Die Informaton, daß alle Zeichen, die zur Datenbank gesendet werden, utf-8 codiert kommen werden, liefert mir ja schon mein $db->set_charset("utf8"). Also wozu ich das jetzt nochmals angeben muß, verstehe ich nicht.

Soweit ich das verstanden hab: Damit wird die Ausgangskodierung für die mb_* Funktionen eingestellt. Dies hat *nichts* mit den Datenbankeinstellungen zu tun.

$empfaenger_name=mb_encode_mimeheader($empfaenger_name, "UTF-8", "Q");

OK, da steht im Manual: "transfer_encoding  specifies the scheme of MIME encoding. It should be either "B" (Base64) or "Q" (Quoted-Printable). Falls back to "B" if not given." Heißt das jetzt: Wandle $empfaenger_name von utf-8 nach Quoted-Printable um? Was heißt Quoted-Printable?

Quoted-Printable ist eine Darstellungsart von 8 Bit Chracters als 7 Bit Chars. Das Problem von E-Mails ist, dass es ursprünglich als reine 7 Bit ASCII-Übertragung definiert wurde, womit nicht einmal LATIN-1 oder ähnliches geht. Aus deinem Beispiel: "=?UTF-8?Q?J=C3=BCrgen=20Mustermann-Wei=C3=9F?=", das ist Quoted-Printable mit UTF-8-Charset (zu erkennen am Anfang des Textes). Jedes Zeichen, das nicht 7 Bit-ASCII ist wird als =XX Hexcode dargestellt, die Hexcodes selbst ergeben sich aus UTF-8.

Was ist der Unterscheid zu Base64?

Base 64 ist eine andere Variante um 8 Bit Chars mit 7 Bit Chars zu kodieren. Da sie aber jedes zeichen in einen 6 Bit Code wandelt (bestehend aus "lesbaren" Zeichen) erzeugt diese Codierung relativ lange Ergebnisse die ohne Dekodierung auch nicht entzifferbar sind (Quoted Printable ist ja mit etwas Fantasie noch lesbar).

Und vor allem: Wieso muß ich jetzt _schon wieder_ mitteilen, daß die Ausgangssituation utf-8 ist?

Das ist hier nicht die Ausgangssituation (diese wurde mit mb_internal_encoding('UTF-8') festgelegt) sondern die Zielvorgabe. Das Ergebnis ist ein "doppelt" kodierter String. Einmal UTF-8 und dann nochmals (QP) um 7 Bit ASCII zu erhalten.

$header.="Content-Transfer-Encoding: 8bit\n";

Und wozu dann noch das? Was bewirkt diese Zeile?

Hiermit wird mitgeteilt, dass der Mail-Body entgegen der ursprünglichen Spezifikation nicht 7 Bit-ASCII sondern eine 8 Bit-Kodierung ist. Ansonsten müsste man den Body ebenfalls als Quoted-Printable oder Base 64 verschicken.

Bei E-Mail trifft man leider nicht nur auf die ISO / UTF-Problematik sondern auch das uralte Relikt der 7 Bit-Codierung...

Hier habe ich festgestellt, daß keine Mail verschickt wird, wenn ich _keine_ -f Angabe mache. Wieso? Und was ist der Unterschied zwischen der -f Mailadresse und der Adresse hinter dem From: ? Beide sagen doch dem empfangenden Server, von wem die Mail kommt bzw. an wen zu antworten ist, oder?

Möglicherweise blockiert der sendende Server, wenn er keinen gültigen Absender mitgeteilt bekommt.

Gruß,

Harlequin

[Brombeermilchtrinker]

Hi Harlequin,

danke für die Antworten. Werd mich jetzt damit auseinandersetzen. Denke, so Einiges davon dürft ich dann besser verstehen!

MfG

Der Brombeermilchtrinker

[dedlfix]

echo $begrüßung;

4.) _Alle_ meine css-Ressourcen beginnen mit einer "@charset "utf-8";" Angabe.
Na dann bleib ich vorsichtshalber auch hier lieber dabei.

Beachte auch noch den Einwand von at. Da Klassennamen ebenfalls Nicht-ASCII-Zeichen enthalten dürfen (ich hab jedenfalls nichts gegenteiliges gefunden), ist in dem Fall auch die charset-Angabe angebracht.

Ja. Vergessen in der Aufzählung hast du die Kodierung der Datenfelder in deinen Datenbanktabellen.
Jetzt verwirrst Du mich. _Du selbst_ hast doch in unzähligen Postings immer wieder betont, daß nicht die Kollation der Datenbankfelder wichtig ist, sondern die Information, die der Server mittels dem $db->set_charset() bzw. mittels mysql_set_character_set() bekommt, da, um Dich zu zitieren, die angegebene Kollation in den Feldern nur für Vergleiche wichtig ist.

Bitte nicht Kollation mit Kodierung gleichsetzen (auch wenn gelegentlich (im phpMyAdmin) nur mit "Kollation" beschriftet ist, was eigentlich "Kodierung und Kollation" heißen müsste). Kollation ist der für Sortierung und Vergleiche relevante Teil. Der interessiert uns hier nicht. Die Kodierung ist zum einen auf dem Transportweg (sprich: Verbindungskodierung) wichtig und zum anderen bei der Datenablage (sprich: Feldkodierung). Denn die Daten müssen nicht nur verlustfrei transportiert sondern auch so abgelegt werden können.

(Aber nichts desto trotz habe ich bei phpmadmin sowohl für die gesamte DB bei "Zeichensatz / Kollation der mysql-Verbindung" ein "utf-8_unicode_ci" eingestellt.

Das ist phpMyAdmins eigene Einstellung, die er beim Gespräch mit MySQL verwendet, also seine Verbindungskodierung. Für andere/deine Scripte ist diese Angabe irrelevant. Wenn du den Server konfigurieren willst, musst du das in seiner Konfigurationsdatei machen. Als Anwender kannst du nur für deine eigenen Datenbanken, Tabellen und Feldern eine Kodierungsangabe festlegen. Die Angabe bei Datenbanken und Tabellen werden aber nur als Defaultwert verwendet, wenn beim Anlegen untergeordneter Elemente keine explizite Angabe gemacht wurde. Am Ende zählt nur das was beim Feld eingetragen ist.

Der Rest ist ja schon beantwortet.

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Hi dedlfix,

das heißt aber nicht, daß ich was falsch mache oder auf etwas vergesse (wenn Du an meine Aufzählung denkst, wo ich überall auf utf-8 achte), oder?

Oder mit anderen Worten: Wenn ich einen neuen Datensatz anlege bzw. nur etwas auslese, dann arbeite ich ja mit der mysqli-Extension, verwende also das "$db->set_charset("utf8");" nach der Verbindung zur DB. Wenn ich einen Datensatz ändere, dann muß ich ja wie bisher mit den herkömmlichen Funktionen arbeiten, verwende also ein "mysql_set_character_set()" nach dem Verbindungsaufbau. Ist das richtig so und ist das ausreichend?

MfG

Der Brombeermilchtrinker

[dedlfix]

echo $begrüßung;

das heißt aber nicht, daß ich was falsch mache oder auf etwas vergesse (wenn Du an meine Aufzählung denkst, wo ich überall auf utf-8 achte), oder?

Der Aufbewahrungsort gehört selbstverständlich mit in die Liste der zu beachtenden Dinge. Es nützt dir ja nichts, wenn du zwar einen Kubikmeter problemlos transportieren kannst, aber nur eine Streichholzschachtel zum Aufbewahren breithältst.

Wenn ich einen neuen Datensatz anlege bzw. nur etwas auslese, dann arbeite ich ja mit der mysqli-Extension, verwende also das "$db->set_charset("utf8");" nach der Verbindung zur DB. Wenn ich einen Datensatz ändere, dann muß ich ja wie bisher mit den herkömmlichen Funktionen arbeiten,

Nein, warum denn das? Du kannst mit mysqli alles machen, was auch mit mysql geht (und darüber hinaus noch mehr).

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Hi dedlfix,

Der Aufbewahrungsort gehört selbstverständlich mit in die Liste der zu beachtenden Dinge. Es nützt dir ja nichts, wenn du zwar einen Kubikmeter problemlos transportieren kannst, aber nur eine Streichholzschachtel zum Aufbewahren breithältst.

Das heißt? Also muß ich _was_ noch zusätzlich tun, was bisher nicht aufgezählt worden ist?

Nein, warum denn das? Du kannst mit mysqli alles machen, was auch mit mysql geht (und darüber hinaus noch mehr).

Also ich kenne mysqli erst seit wenigen Tagen, habe aber schon intensive Suche nach Tutorials und Beispielseiten gesucht. Bisher habe ich _ausschließlich_ die Verwendung beim Einfügen eines neuen Datensatzes und beim Auslesen gefunden. Die 2 bisher besten Seiten, die ich gefunden habe, sind die Einführung in die MySQLi-Erweiterung von PHP 5 auf phpbuddy.eu und das Tutorial Einführung in die MySQLi-Erweiterung von PHP 5 auf traum-projekt.com.

Vor kurzem hat mir hier ChrisB erklärt:

Wenn du mit mysqli_query eine Query an die Datenbank absetzt, dann machst du das nach wie vor so:
mysql_query("SELECT ... FROM WHERE xyz = '".$variable."'");

Ich dachte, die Betonung lag da auf "nach wie vor" und habe, da ich eben für das Löschen bzw. Ändern von schon bestehenden Datensätzen mittels mysqli _nichts_ gefunden habe, angenommen, dies bedeutet, ich kann nicht _ganz_ auf die bisherigen Befehle und Schreibweisen verzichten.

Es tut mir leid, aber das muß ich jetzt hinterfragen. Nicht, daß ich da von Anfang an was falsch lerne oder verstehe. Also nehmen wir folgende, ganz einfache Situation an:

Ich habe eine Datenbank mit der Hostadresse "mysql4.example.com", die Datenbank hat den Namen "db123456", mein Username ist ebenfalls "db123456" und mein Passwort lautet "beispielpass".

In dieser DB habe ich jetzt eine Tabelle mit dem Namen "tabelle1" angelegt. Diese Tabelle hat die Felder "id"[Typ:int(5), Null:NEIN, Extra:auto_increment sowie Primärschlüssel], "name"[Typ:varchar(50), Null:JA, Standard:NULL], "ort"[Typ:varchar(50), Null:JA, Standard:NULL], und "geburtsjahr"[Typ:int(4), Null:JA, Standard:NULL].

Ich nehme weiter an, daß ich Namen, Ort und Geburtsjahr aus einem Formular übernehme und weiterverarbeite. (Stichwort:kontextbezogene Behandlung)

Als letztens im Forum jemand nach einer Kurzzusammenfassung von SQL-Befehlen gefragt hat, hast Du (logischerweise) geantwortet:

Die wichtigsten SQL-Anweisungen sind SELECT, INSERT, UPDATE und DELETE. Alles andere ist praktisch systemabhängig.

OK, also die 4 wichtigsten Aktionen sind: 1) Einen neuen Datensatz hinzufügen, 2) Datensätze ausgeben. 3) Einen bestehenden Datensatz ändern und 4) einen bestehenden Datensatz löschen.

Ich bleibe jetzt bei oben stehenden fiktiven Angaben und zeige Dir mal, wie ich 1) und 2) mit mysqli löse:

1. Einen neuen Datensatz hinzufügen mit mysqli:

<?php  
 $db = new MySQLi('mysql4.example.com', 'db123456', 'beispielpass', 'db123456');  
 if(mysqli_connect_errno())  
  {  
   die("Es konnte keine Verbindung zur Datenbank aufgebaut werden: ".mysqli_connect_error()."(".mysqli_connect_errno().")");  
  }  
 $db->set_charset("utf8");  
 $sql = 'INSERT INTO `tabelle1` (`name`, `ort`, `geburtsjahr`) VALUES (?, ?, ?)';  
 $kommando = $db->prepare($sql);  
 $kommando->bind_param('ssi', $_POST['name'], $_POST['ort'], $_POST['geburtsjahr']);  
 $kommando->execute();  
 $db->close();  
?>

2. Alle Datensätze der Tabelle ausgeben mit mysqli:

<?php  
 $db = new MySQLi('mysql4.example.com', 'db123456', 'beispielpass', 'db123456');  
 if(mysqli_connect_errno())  
  {  
   die("Es konnte keine Verbindung zur Datenbank aufgebaut werden: ".mysqli_connect_error()."(".mysqli_connect_errno().")");  
  }  
 $sql = 'SELECT `id`, `name`, `ort`, `geburtsjahr` FROM `tabelle1` ORDER BY `id`';  
 $ergebnis = $db->prepare( $sql );  
 $ergebnis->execute();  
 $ergebnis->bind_result( $id, $name, $stadt, $geburtsjahr );  
 while ($ergebnis->fetch())  
  {  
   echo "<p>".htmlspecialchars(stripslashes($id))." ==> ".htmlspecialchars(stripslashes($name))." aus ".htmlspecialchars(stripslashes($ort))." ist ".htmlspecialchars(stripslashes($geburtsjahr))."geboren.</p>\n";  
  }  
 $db->close();  
?>

Anmerkung: Hier habe ich das "$db->set_charset("utf8");" _absichtlich_ weggelassen, weil es ja nur der Ausgabebefehl ist, ohne Daten in einer WHERE Klausel. Ist das eh OK so?

2B) Ausgabe von Datensätzen unter einer Bedingung mit mysqli:

<?php  
 $db = new MySQLi('mysql4.example.com', 'db123456', 'beispielpass', 'db123456');  
 if(mysqli_connect_errno())  
  {  
   die("Es konnte keine Verbindung zur Datenbank aufgebaut werden: ".mysqli_connect_error()."(".mysqli_connect_errno().")");  
  }  
 $db->set_charset("utf8");  
 $sql = 'SELECT `id`, `name`, `ort`, `geburtsjahr` FROM `tabelle1` WHERE `ort`=`'.$_POST['ortsuche'].'` ORDER BY `id`';  
 $ergebnis = $db->prepare( $sql );  
 $ergebnis->execute();  
 $ergebnis->bind_result( $id, $name, $stadt, $geburtsjahr );  
 while ($ergebnis->fetch())  
  {  
   echo "<p>".htmlspecialchars(stripslashes($id))." ==> ".htmlspecialchars(stripslashes($name))." aus ".htmlspecialchars(stripslashes($ort))." ist ".htmlspecialchars(stripslashes($geburtsjahr))."geboren.</p>\n";  
  }  
 $db->close();  
?>

Zwischenfrage: Ist der WHERE-Teil mit den Anführungszeichen und dem Verkettungsoperatoren richtig so?

So, aber das war das Ende meiner Weisheit. Wie man 3) einen bestehenden Datensatz ändern und 4) einen bestehenden Datensatz löschen kann (_mit mysqli_), weiß ich nichts und finde dazu auch nichts im Netz. Für diese 2 Aufgaben finde ich nur die althergebrachte, herkömmliche Methode.

Ich bitte um Nachhilfeunterricht. :-)

MfG

Der Brombeermilchtrinker

[flowh]

Hallo Brombeermilchtrinker.

Vor kurzem hat mir hier ChrisB erklärt:

Wenn du mit mysqli_query eine Query an die Datenbank absetzt, dann machst du das nach wie vor so:
mysql_query("SELECT ... FROM WHERE xyz = '".$variable."'");

Ich denke, der Chris hat eigentlich das Pendant zu mysql_query() für mysqli, nämlich [link:http://de.php.net/manual/de/mysqli.query.php@title=mysqli_query()], gemeint. Dies ist "procedural style", objektorientiert würde man mysqli::query() verwenden.

Servus,
Flo

[dedlfix]

echo $begrüßung;

Der Aufbewahrungsort gehört selbstverständlich mit in die Liste der zu beachtenden Dinge. Es nützt dir ja nichts, wenn du zwar einen Kubikmeter problemlos transportieren kannst, aber nur eine Streichholzschachtel zum Aufbewahren breithältst.
Das heißt? Also muß ich _was_ noch zusätzlich tun, was bisher nicht aufgezählt worden ist?

Eigentlich nichts mehr, denn du erwähntest bereits, dass du bei jedem TEXT- und VARCHAR-Feld eine Kollationsangabe (die beinhaltet ja die Kodierung) gesetzt hättest. Es fehlte nur in deiner ursprünglichen Auflistung der zu beachtenden Dinge.

Ich nehme weiter an, daß ich Namen, Ort und Geburtsjahr aus einem Formular übernehme und weiterverarbeite. (Stichwort:kontextbezogene Behandlung)

Wenn du in ein SQL-Statement selbst Daten einfügst, dann musst du dabei beachten, dass du diese Daten gemäß den Regeln des DBMS behandelst. Wenn du Prepared Statements (P.S.) und Platzhalter für die Daten verwendest, machst du das nicht, weil sich die Client-API des DBMS darum kümmert.

Die wichtigsten SQL-Anweisungen sind SELECT, INSERT, UPDATE und DELETE. Alles andere ist praktisch systemabhängig.
OK, also die 4 wichtigsten Aktionen sind: 1) Einen neuen Datensatz hinzufügen, 2) Datensätze ausgeben. 3) Einen bestehenden Datensatz ändern und 4) einen bestehenden Datensatz löschen.

Alle SQL-Statements, nicht nur diese vier, werden gleich behandelt, was den Weg zum DMBS hin betrifft.

Ich bleibe jetzt bei oben stehenden fiktiven Angaben und zeige Dir mal, wie ich 1) und 2) mit mysqli löse:

1. Einen neuen Datensatz hinzufügen mit mysqli:

Passt, kein direkter Einwand meinerseits.

2. Alle Datensätze der Tabelle ausgeben mit mysqli:
      echo "<p>".htmlspecialchars(stripslashes($id))." ==> ".htmlspecialchars(stripslashes($name))." aus ".htmlspecialchars(stripslashes($ort))." ist ".htmlspecialchars(stripslashes($geburtsjahr))."geboren.</p>\n";

Wenn du hier stripslashes() verwendest, weil du sonst ungewollte \ in der Ausgabe hast, dann hast du ein Problem mit den Magic Quotes, das du aber an ganz anderer Stelle lösen musst. Magic Quotes waren gedacht, um SQL-Injection-Probleme zu lösen. Doch dieses Feature wirkt auf alle Eingabedaten, nicht nur auf die, die in ein SQL-Statement eingebaut werden und auch auf die, die aufgrund von P.S. aus Prinzip kein SQL-Injection-Problem haben.

Wenn bei dir die Magic Quotes eingeschaltet sind, bekommst du nun fehlerhafte Daten in dein DBMS, weil der \ als ganz normales Zeichen angesehen wird. Sorge dafür, dass die Magic Quotes generell deaktiviert oder einmalig am Script-Anfang deren Auswirkungen rückgängig gemacht werden.

htmlspecialchars() bleibt, weil das für das Einfügen in den HTML-Kontext benötigt wird.

Anmerkung: Hier habe ich das "$db->set_charset("utf8");" _absichtlich_ weggelassen, weil es ja nur der Ausgabebefehl ist, ohne Daten in einer WHERE Klausel. Ist das eh OK so?

Bei jeglicher Kommunikation mit dem DBMS sollte die Verbindungskodierung ausgehandelt werden, ansonsten wird ein System-Default-Wert verwendet. MySQL kodiert die Felddaten in die Verbindungskodierung um, wenn diese eine andere als die Feldkodierung ist. Das willst du nicht, wenn dein Default-Wert Latin1 ist, denn du willst ja mit UTF-8 weiterarbeiten. Außerdem gehen die Zeichen verloren, die nicht in Latin1 enthalten sind.

2B) Ausgabe von Datensätzen unter einer Bedingung mit mysqli:
$sql = 'SELECT id, name, ort, geburtsjahr FROM tabelle1 WHERE ort='.$\_POST['ortsuche'].' ORDER BY id';
$ergebnis = $db->prepare( $sql );

Integriere den Parameter so in dein Statement, wie du das bereits bei 1) getan hast. Du verwendest P.S., also brauchst du keine Daten händisch in das Statement einzubauen.

Zwischenfrage: Ist der WHERE-Teil mit den Anführungszeichen und dem Verkettungsoperatoren richtig so?

Nein, du hast dabei gleich zwei Fehler gemacht. Das Quotieren von Strings geht mit ' oder ", Backticks sind für Bezeichner vorgesehen. Und wenn du händisch Daten in ein Statement einfügst, ist dabei immer der Kontextwechsel zu beachten und zu behandeln. Diese beiden Fehler lösen sich aber in Luft auf, wenn du P.S. richtig verwendest.

So, aber das war das Ende meiner Weisheit. Wie man 3) einen bestehenden Datensatz ändern und 4) einen bestehenden Datensatz löschen kann (_mit mysqli_), weiß ich nichts und finde dazu auch nichts im Netz.

Das Prinzip ist auch bei diesen beiden Statements kein anderes als bei Nummer 1.

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Hi dedlfix,

Also muß ich _was_ noch zusätzlich tun, was bisher nicht aufgezählt worden ist?
Eigentlich nichts mehr, denn du erwähntest bereits, dass du bei jedem TEXT- und VARCHAR-Feld eine Kollationsangabe (die beinhaltet ja die Kodierung) gesetzt hättest.

Ja, das mache ich.

Ich nehme weiter an, daß ich Namen, Ort und Geburtsjahr aus einem Formular übernehme und weiterverarbeite. (Stichwort:kontextbezogene Behandlung)

Wenn du in ein SQL-Statement selbst Daten einfügst, dann musst du dabei beachten, dass du diese Daten gemäß den Regeln des DBMS behandelst. Wenn du Prepared Statements (P.S.) und Platzhalter für die Daten verwendest, machst du das nicht, weil sich die Client-API des DBMS darum kümmert.

Ich nehme an, was Du mir damit sagen willst ist, daß bei der Prozedur mit den prepared Statements keine SQL Injection passieren kann, weil sich das System automatisch um das Escapen kümmert? Das habe ich schon verstanden. Ich hab das mit der kontextbezogenen Behandlung schon auf die Ausgaben bezogen. Oder war Deine Antwort anders gemeint?

Alle SQL-Statements, nicht nur diese vier, werden gleich behandelt, was den Weg zum DMBS hin betrifft.

Was willst Du mir _damit_ sagen?

2. Alle Datensätze der Tabelle ausgeben mit mysqli:
      echo "<p>".htmlspecialchars(stripslashes($id))." ==> ".htmlspecialchars(stripslashes($name))." aus ".htmlspecialchars(stripslashes($ort))." ist ".htmlspecialchars(stripslashes($geburtsjahr))."geboren.</p>\n";

Wenn du hier stripslashes() verwendest, weil du sonst ungewollte \ in der Ausgabe hast, dann hast du ein Problem mit den Magic Quotes, das du aber an ganz anderer Stelle lösen musst.

Ich verstehe Dich einfach nicht!!! Wenn man über das Formular zB beim Namen Hans eingibt und davor und danach ein Anführungszeichen schreibt, dann landet das als "Hans" in der DB. Aber nicht, weil ich mich darum gekümmert habe, sondern weil das durch das mysqli und den prepared Statements automatisch passiert, oder??

Hier geht es jetzt rein um die _Ausgabe_. Natürlich will ich die Stripslashes loswerden davor! Aber deswegen hab ich doch mit nichts Probleme??!

Magic Quotes waren gedacht, um SQL-Injection-Probleme zu lösen. Doch dieses Feature wirkt auf alle Eingabedaten, nicht nur auf die, die in ein SQL-Statement eingebaut werden und auch auf die, die aufgrund von P.S. aus Prinzip kein SQL-Injection-Problem haben.

Hier geht es doch um keine Eingabedaten, hier gebe ich was _aus_!

Wenn bei dir die Magic Quotes eingeschaltet sind, bekommst du nun fehlerhafte Daten in dein DBMS, weil der \ als ganz normales Zeichen angesehen wird. Sorge dafür, dass die Magic Quotes generell deaktiviert oder einmalig am Script-Anfang deren Auswirkungen rückgängig gemacht werden.

Dedlfix, Du verwirrst mich immer mehr und mehr. :-(
Mir wurde doch letztens extra erklärt, wenn ich diese moderne Form (also das mysqli) nehme, dann brauche ich keine Angst vor SQL Injections haben und mich auch nicht davor schützen, weil das das System automatisch macht. Und jetzt muß ich mich _doch_ plötzlich wieder um Dinge wie Magic Quotes kümmern? Dachte, das betrifft mich nur, wenn ich die althergebrachten Methoden verwende?

Anmerkung: Hier habe ich das "$db->set_charset("utf8");" _absichtlich_ weggelassen, weil es ja nur der Ausgabebefehl ist, ohne Daten in einer WHERE Klausel. Ist das eh OK so?

Bei jeglicher Kommunikation mit dem DBMS sollte die Verbindungskodierung ausgehandelt werden, ansonsten wird ein System-Default-Wert verwendet. MySQL kodiert die Felddaten in die Verbindungskodierung um, wenn diese eine andere als die Feldkodierung ist. Das willst du nicht, wenn dein Default-Wert Latin1 ist, denn du willst ja mit UTF-8 weiterarbeiten. Außerdem gehen die Zeichen verloren, die nicht in Latin1 enthalten sind.

Aha. Bin zwar jetzt schon so verwirrt, daß ich gar nichts mehr verstehe, aber ich gebe es wieder dazu, lasse das also IMMER dabei.

2B) Ausgabe von Datensätzen unter einer Bedingung mit mysqli:
$sql = 'SELECT id, name, ort, geburtsjahr FROM tabelle1 WHERE ort='.$\_POST['ortsuche'].' ORDER BY id';
$ergebnis = $db->prepare( $sql );

Integriere den Parameter so in dein Statement, wie du das bereits bei 1) getan hast. Du verwendest P.S., also brauchst du keine Daten händisch in das Statement einzubauen.

Wie meinst Du das? BITTE schreib mir doch die Zeile so hin, wie es richtig wäre.

Zwischenfrage: Ist der WHERE-Teil mit den Anführungszeichen und dem Verkettungsoperatoren richtig so?

Nein, du hast dabei gleich zwei Fehler gemacht. Das Quotieren von Strings geht mit ' oder ", Backticks sind für Bezeichner vorgesehen. Und wenn du händisch Daten in ein Statement einfügst, ist dabei immer der Kontextwechsel zu beachten und zu behandeln. Diese beiden Fehler lösen sich aber in Luft auf, wenn du P.S. richtig verwendest.

Tja, wenn ich nur wüßte, wie?

So, aber das war das Ende meiner Weisheit. Wie man 3) einen bestehenden Datensatz ändern und 4) einen bestehenden Datensatz löschen kann (_mit mysqli_), weiß ich nichts und finde dazu auch nichts im Netz.

Das Prinzip ist auch bei diesen beiden Statements kein anderes als bei Nummer 1.

Super. Weil GENAU DAS war es ja, was ich wissen wollte, weil ich es eben NICHT kann. Und ich finde auch nach 4 Stunden nicht _eine_ Seite im Netz, wo das hergezeigt wird. Ich finde weiterhin nur Seiten, wo man Beispielcodes für das Erstellen von Datensätzen oder für das Anzeigen aller Datensätze einer Tabelle sieht.

Kannst Du mir bitte konkreter helfen, das irgendwie verständlicher erklären und mir ETWAS mehr php-Code zeigen? BITTE! Oder gibts wo eine Seite, wo das anschaulich erklärt wird?

Mir vergeht langsam die Lust an der Sache. :-(

Der Brombeermilchtrinker

[Harlequin]

Yerf!

Ich kann zwar eigentlich kaum PHP, nur aus ein paar kleineren CMS-Anpassungen und dem was ich hier so mitlese, aber vielleicht kann ich trotzdem (oder gerade deswegen) ein paar Anhaltspunkte geben.

(evtl. kann Jens ja noch ein paar Kommentare dazu geben)

Alle SQL-Statements, nicht nur diese vier, werden gleich behandelt, was den Weg zum DMBS hin betrifft.

Was willst Du mir _damit_ sagen?

Das soll heisen, das an der Stelle, wo du *ein bestimmtes* SQL-Statement verwenden kannst, eigentlich *jedes* Statement möglich ist. Änder doch in deinem Beispiel die Variable $sql die du dem prepare() übergibst einfach entsprechend. Mysqli ist es völlig egal, ob du da einen select, update oder drop table drinnen hast. Einfach etwas damit rumexperimentieren.

Ich verstehe Dich einfach nicht!!! Wenn man über das Formular zB beim Namen Hans eingibt und davor und danach ein Anführungszeichen schreibt, dann landet das als "Hans" in der DB. Aber nicht, weil ich mich darum gekümmert habe, sondern weil das durch das mysqli und den prepared Statements automatisch passiert, oder??

Nein, das kommt nicht von mysqli oder den prepared statements, die arbeiten völlig transparent. Die Slashes kommen von den Magic-Quotes die scheinbar angeschalten sind. Dies passiert am Anfang des Scripts völlig unabhängig von irgendwelchen Datenbanksachen (und genau das ist auch deren Problem).

Hier geht es doch um keine Eingabedaten, hier gebe ich was _aus_!

Zu diesem Zeitpunkt sind die Daten schon "versaut", da musst du schon vorher eingreifen, das komt gleich:

Mir wurde doch letztens extra erklärt, wenn ich diese moderne Form (also das mysqli) nehme, dann brauche ich keine Angst vor SQL Injections haben und mich auch nicht davor schützen, weil das das System automatisch macht. Und jetzt muß ich mich _doch_ plötzlich wieder um Dinge wie Magic Quotes kümmern? Dachte, das betrifft mich nur, wenn ich die althergebrachten Methoden verwende?

Du musst kein extra Escaping mehr vornehmen, ja das ist richtig. Allerdings musst du sicherstellen, dass die Magic Quotes ausgeschalten sind oder diese am Anfang des Scriptes händisch rückgängig machen, da sie dir ansonsten die Daten versauen. Ein Problem das erst mit PHP 6 endgültig gelöst sein wird (da fliegen die Dinger raus)

Aha. Bin zwar jetzt schon so verwirrt, daß ich gar nichts mehr verstehe, aber ich gebe es wieder dazu, lasse das also IMMER dabei.

Die Kodierungsangabe ist nicht nur für die Daten, die du der DB übergibst zuständig, sie sagt auch aus, in welcher Kodierung du gerne die Antwort hättest. Die Datenbank ist da flexibel und nimmt notfalls ein umkodieren vor, wenn du die Daten anders haben möchtest, als sie in der Tabelle abgelegt sind.

2B) Ausgabe von Datensätzen unter einer Bedingung mit mysqli:
$sql = 'SELECT id, name, ort, geburtsjahr FROM tabelle1 WHERE ort='.$\_POST['ortsuche'].' ORDER BY id';
$ergebnis = $db->prepare( $sql );

Integriere den Parameter so in dein Statement, wie du das bereits bei 1) getan hast. Du verwendest P.S., also brauchst du keine Daten händisch in das Statement einzubauen.

Wie meinst Du das? BITTE schreib mir doch die Zeile so hin, wie es richtig wäre.

Er meint anstelle von ort='.$\_POST['ortsuche'].' ein ort=? und danach mit bind_param('ssi',$_POST['ortsuche']) arbeiten.

Nur über bind_param wird das Escapen überflüssig, was du händisch in den SQL-String einbaust müsstest du entsprechend bearbeiten.

Super. Weil GENAU DAS war es ja, was ich wissen wollte, weil ich es eben NICHT kann. Und ich finde auch nach 4 Stunden nicht _eine_ Seite im Netz, wo das hergezeigt wird. Ich finde weiterhin nur Seiten, wo man Beispielcodes für das Erstellen von Datensätzen oder für das Anzeigen aller Datensätze einer Tabelle sieht.

$sql = 'UPDATE tabelle1 SET geburtsjahr = ? WHERE name = ?';
 $kommando = $db->prepare($sql);
 $kommando->bind_param('ssi', $_POST['name'], $_POST['geburtsjahr']);
 $kommando->execute();

Ungetestet, sollte aber das Geburtsdatum aller Personen mit dem entsprechenden Namen setzen...

Gruß,

Harlequin

[Brombeermilchtrinker]

Hi Harlequin,

auch Dir danke für die Antwort! Bin jetzt grad am Testen und Herumprobieren!

Danke einstweilen!

MfG

Der Brombeermilchtrinker

[dedlfix]

echo $begrüßung;

$sql = 'UPDATE tabelle1 SET geburtsjahr = ? WHERE name = ?';
$kommando = $db->prepare($sql);
$kommando->bind_param('ssi', $_POST['name'], $_POST['geburtsjahr']);
$kommando->execute();

Ungetestet, sollte aber das Geburtsdatum aller Personen mit dem entsprechenden Namen setzen...

Zwei kleine Korrekturen: Name und Geburtsjahr hast du in der falschen Reihenfolge notiert. Der erste Parameter von bind_param() gibt an, welchen Typ die Daten haben. Bei zwei String-Parametern also nur 'ss'.

echo "$verabschiedung $name";

[Harlequin]

Yerf!

Ungetestet, sollte aber das Geburtsdatum aller Personen mit dem entsprechenden Namen setzen...

Zwei kleine Korrekturen: Name und Geburtsjahr hast du in der falschen Reihenfolge notiert.

Argh, das kommt davon wenn man nachträglich nochmal dran rumbastelt...

Der erste Parameter von bind_param() gibt an, welchen Typ die Daten haben. Bei zwei String-Parametern also nur 'ss'.

Da ich's noch nie benutzt hab wusste ich nicht genau, was der Parameter bedeutet und hab ihn nur per C&P übernommen... danke für die Korrektur.

Gruß,

Harlequin

[Brombeermilchtrinker]

Hi Harlequin,

Da ich's noch nie benutzt hab wusste ich nicht genau, was der Parameter bedeutet und hab ihn nur per C&P übernommen... danke für die Korrektur.

schau,  _das_ hätte ich gewußt nach all dem Googeln, Lesen, Fragen und Herumprobieren. Na zumindest ein kleines Erfolgserlebnis für mich! ;-)

Danke nochmals auch Dir für die Hilfe!

MfG

Der Brombeermilchtrinker

[flowh]

Hallo.

Ich verstehe Dich einfach nicht!!! Wenn man über das Formular zB beim Namen Hans eingibt und davor und danach ein Anführungszeichen schreibt, dann landet das als "Hans" in der DB. Aber nicht, weil ich mich darum gekümmert habe, sondern weil das durch das mysqli und den prepared Statements automatisch passiert, oder??

Wenn du "Hans" (mit den Anführungszeichen) in dein Formular eingibst, dann sollte in der Datenbank auch "Hans" (mit den Anführunszeichen) gespeichert werden, und nicht "Hans" oder irgendetwas anderes. Du willst ja genau das, was eingegeben wird, auch in der Datenbank haben.

Dass die " um Hans herum escaped werden (d.h. ein \ davor gesetzt wird), liegt an dem PHP-"Feature" Magic Quotes. Die Prepared Statements sorgen nur u.a. dafür, dass die Daten, die du an die Datenbank schickst, auch genauso in der Datenbank ankommen.

Hier geht es jetzt rein um die _Ausgabe_. Natürlich will ich die Stripslashes loswerden davor! Aber deswegen hab ich doch mit nichts Probleme??!

Es ist nur unnötig kompliziert, erst PHP alle " escapen zu lassen und dann ständig aufzupassen und dran zu denken, dass das so ist, und dann auch evtl wieder rückgängig zu machen.
Einfacher ist es, die Magic Quotes gleich ganz auszuschalten, oder ihre Wirkung zu Scriptbeginn global rückgängig zu machen (siehe dazu dedlfix' Link).

Magic Quotes waren gedacht, um SQL-Injection-Probleme zu lösen. Doch dieses Feature wirkt auf alle Eingabedaten, nicht nur auf die, die in ein SQL-Statement eingebaut werden und auch auf die, die aufgrund von P.S. aus Prinzip kein SQL-Injection-Problem haben.

Hier geht es doch um keine Eingabedaten, hier gebe ich was _aus_!

Mit Eingabedaten ist gemeint: $_GET, $_POST, etc...

Mir wurde doch letztens extra erklärt, wenn ich diese moderne Form (also das mysqli) nehme, dann brauche ich keine Angst vor SQL Injections haben und mich auch nicht davor schützen, weil das das System automatisch macht. Und jetzt muß ich mich _doch_ plötzlich wieder um Dinge wie Magic Quotes kümmern? Dachte, das betrifft mich nur, wenn ich die althergebrachten Methoden verwende?

Sofern du Prepared Statements verwendest, brauchst du dich nicht mehr um SQL-Injection kümmern, unabhängig davon, ob Magic Quotes aktiviert sind oder nicht.

Bei jeglicher Kommunikation mit dem DBMS sollte die Verbindungskodierung ausgehandelt werden, ansonsten wird ein System-Default-Wert verwendet. MySQL kodiert die Felddaten in die Verbindungskodierung um, wenn diese eine andere als die Feldkodierung ist. Das willst du nicht, wenn dein Default-Wert Latin1 ist, denn du willst ja mit UTF-8 weiterarbeiten. Außerdem gehen die Zeichen verloren, die nicht in Latin1 enthalten sind.

Aha. Bin zwar jetzt schon so verwirrt, daß ich gar nichts mehr verstehe, aber ich gebe es wieder dazu, lasse das also IMMER dabei.

Immer, wenn du mit dem DBMS kommunizierst, werden dabei irgendwelche Daten übertragen. Und damit alle Beteiligten wissen, wie diese Daten kodiert (utf-8, etc..) sind,  musst du das halt angeben, ist doch logisch :-)

Tja, wenn ich nur wüßte, wie?

So wie dus weiter oben auch gemacht hast. SQL String mit $stmt = $db->prepare($sql) vorbereiten, dann die Parameter mit $stmt->bind_param() einfügen. Das funktioniert auch bei WHERE. ("... WHERE foo=?")

Das Prinzip ist auch bei diesen beiden Statements kein anderes als bei Nummer 1.

Super. Weil GENAU DAS war es ja, was ich wissen wollte, weil ich es eben NICHT kann.

Du kannst es doch: SQL String vorbereiten, Parameter dranbinden, ausführen, wie oben auch schon.

Ob das SQL jetzt aus "UPDATE bla SET foo=? WHERE baz=?" oder "DELETE FROM bla WHERE baz=?" oder "SELECT foo FROM bla WHERE baz=?" oder "INSERT INTO bla (foo) VALUES (?)" besteht, ist egal. Du musst halt nur immer die passenden Parameter dranbinden.

Servus,
Flo

[Brombeermilchtrinker]

Hi Flo,

Wenn du "Hans" (mit den Anführungszeichen) in dein Formular eingibst, dann sollte in der Datenbank auch "Hans" (mit den Anführunszeichen) gespeichert werden, und nicht "Hans" oder irgendetwas anderes. Du willst ja genau das, was eingegeben wird, auch in der Datenbank haben.

Dass die " um Hans herum escaped werden (d.h. ein \ davor gesetzt wird), liegt an dem PHP-"Feature" Magic Quotes. Die Prepared Statements sorgen nur u.a. dafür, dass die Daten, die du an die Datenbank schickst, auch genauso in der Datenbank ankommen.

OK, ich habe jetzt "magic_quotes_gpc" deaktiviert, also auf OFF und nun wird "Hans" auch als "Hans" gespeichert.

Außerdem habe ich:

magic_quotes_runtime = Off
magic_quotes_sybase = Off

Ist das OK so?

Einfacher ist es, die Magic Quotes gleich ganz auszuschalten, oder ihre Wirkung zu Scriptbeginn global rückgängig zu machen (siehe dazu dedlfix' Link).

Habe Euch beide verstanden jetzt, das problem hab ich nun ja nicht mehr.

Magic Quotes waren gedacht, um SQL-Injection-Probleme zu lösen. Doch dieses Feature wirkt auf alle Eingabedaten, nicht nur auf die, die in ein SQL-Statement eingebaut werden und auch auf die, die aufgrund von P.S. aus Prinzip kein SQL-Injection-Problem haben.

Verstehe. (Glaub ich zumindest)

Sofern du Prepared Statements verwendest, brauchst du dich nicht mehr um SQL-Injection kümmern, unabhängig davon, ob Magic Quotes aktiviert sind oder nicht.

Danke! Verstehe.

Immer, wenn du mit dem DBMS kommunizierst, werden dabei irgendwelche Daten übertragen. Und damit alle Beteiligten wissen, wie diese Daten kodiert (utf-8, etc..) sind,  musst du das halt angeben, ist doch logisch :-)

Ich dachte, ich muß nur Acht drauf geben, wenn ich was zur DB sende, nicht umgekehrt. Ist aber schon klarer jetzt!

Tja, wenn ich nur wüßte, wie?

So wie dus weiter oben auch gemacht hast. SQL String mit $stmt = $db->prepare($sql) vorbereiten, dann die Parameter mit $stmt->bind_param() einfügen. Das funktioniert auch bei WHERE. ("... WHERE foo=?")

Das Prinzip ist auch bei diesen beiden Statements kein anderes als bei Nummer 1.

Ich bin gerade am Versuchen und Testen!

Danke einstweilen!

MfG

Der Brombeermilchtrinker

[dedlfix]

echo $begrüßung;

Ich nehme an, was Du mir damit sagen willst ist, daß bei der Prozedur mit den prepared Statements keine SQL Injection passieren kann, weil sich das System automatisch um das Escapen kümmert? Das habe ich schon verstanden.

Nicht ganz. Wenn du ein Statement zu Fuß zusammenbaust, bringst du dabei einzufügende Daten in den SQL-Satement-Kontext. Dafür ist eine kontextgerechte Behandlung erforderlich. Bei P.S. gehen Statement und Daten getrennte Wege. Die Daten werden also nicht in das SQL-Statement eingebettet werden, und müssen demzufolge auch nicht dafür behandelt werden.

Auf welche Art und Weise die Übertragung wirklich erfolgt, kann uns egal sein. Die Daten müssen in Rohform an die dafür vorgesehene Funktion übergeben werden und der Rest ist Blackbox.

Ich hab das mit der kontextbezogenen Behandlung schon auf die Ausgaben bezogen. Oder war Deine Antwort anders gemeint?

Du hast aber auch einen Kontextwechsel, wenn du Daten direkt in ein SQL-Statement einfügst.

Alle SQL-Statements, nicht nur diese vier, werden gleich behandelt, was den Weg zum DMBS hin betrifft.
Was willst Du mir _damit_ sagen?

Es gibt keinen Unterschied ob du einen Wert in ein SELECT- oder INSERT- oder Sonstwas-Statement einfügst. Ebenso müssen für alle Arten von Statements die Übertragungsbedingungen auf gleiche Weise berücksichtigt werden, was hier heißen soll, dass die Kodierung immer eine Rolle spielt und explizit ausgehandelt werden sollte.

2. Alle Datensätze der Tabelle ausgeben mit mysqli:
      echo "<p>".htmlspecialchars(stripslashes($id))." ==> ".htmlspecialchars(stripslashes($name))." aus ".htmlspecialchars(stripslashes($ort))." ist ".htmlspecialchars(stripslashes($geburtsjahr))."geboren.</p>\n";
   Wenn du hier stripslashes() verwendest, weil du sonst ungewollte \ in der Ausgabe hast, dann hast du ein Problem mit den Magic Quotes, das du aber an ganz anderer Stelle lösen musst.
   Ich verstehe Dich einfach nicht!!! Wenn man über das Formular zB beim Namen Hans eingibt und davor und danach ein Anführungszeichen schreibt, dann landet das als "Hans" in der DB. Aber nicht, weil ich mich darum gekümmert habe, sondern weil das durch das mysqli und den prepared Statements automatisch passiert, oder??

Du hast hier einen Nebenkriegsschauplatz, der durch das PHP-Feature Magic Quotes entsteht.

Hier geht es jetzt rein um die _Ausgabe_. Natürlich will ich die Stripslashes loswerden davor! Aber deswegen hab ich doch mit nichts Probleme??!

Na doch, dass es ein Problem ist, zeigt sich daran, dass du es behandeln musst, weil du sonst ungewollte Backslashes bekommst. Das Problem hätte nicht sein müssen, wenn das Feature Magic Quotes dir es nicht stillschweigend aufgetischt hätte.

Magic Quotes waren gedacht, um SQL-Injection-Probleme zu lösen. Doch dieses Feature wirkt auf alle Eingabedaten, nicht nur auf die, die in ein SQL-Statement eingebaut werden und auch auf die, die aufgrund von P.S. aus Prinzip kein SQL-Injection-Problem haben.
Hier geht es doch um keine Eingabedaten, hier gebe ich was _aus_!

Ja, das Problem entstand aber schon, offensichtlich ohne von dir bemerkt zu werden, beim Einfügen der Daten in das DBMS. Magic Quotes wollte für Sicherheit sorgen, hat aber stattdessen deine Daten ungewollt und unnötig verändert.

Wenn bei dir die Magic Quotes eingeschaltet sind, bekommst du nun fehlerhafte Daten in dein DBMS, weil der \ als ganz normales Zeichen angesehen wird. Sorge dafür, dass die Magic Quotes generell deaktiviert oder einmalig am Script-Anfang deren Auswirkungen rückgängig gemacht werden.
Mir wurde doch letztens extra erklärt, wenn ich diese moderne Form (also das mysqli) nehme, dann brauche ich keine Angst vor SQL Injections haben und mich auch nicht davor schützen, weil das das System automatisch macht. Und jetzt muß ich mich _doch_ plötzlich wieder um Dinge wie Magic Quotes kümmern?

Ein eingeschaltetes Magic Quotes behandelt vorsorglich vor dem Scriptstart sämtliche GPC-Daten (GET, POST, Cookie) mit addslashes(). Das ist (nicht nur) in deinem Fall kontraproduktiv, weil du dich selbst darum kümmerst, beziehungsweise es nicht brauchst, weil das Injection-Problem mit P.S. nicht relevant ist.

Dachte, das betrifft mich nur, wenn ich die althergebrachten Methoden verwende?

M.Q. interessiert sich nicht dafür, ob du P.S. verwendest, oder die Daten gar nicht in einen SQL-Kontext gelangen. Du brauchst M.Q.s nicht, also deaktiviere sie generell oder entferne nach dem Scriptstart die überflüssigen Zeichen.

Bei jeglicher Kommunikation mit dem DBMS sollte die Verbindungskodierung ausgehandelt werden, ansonsten wird ein System-Default-Wert verwendet. MySQL kodiert die Felddaten in die Verbindungskodierung um, wenn diese eine andere als die Feldkodierung ist. Das willst du nicht, wenn dein Default-Wert Latin1 ist, denn du willst ja mit UTF-8 weiterarbeiten. Außerdem gehen die Zeichen verloren, die nicht in Latin1 enthalten sind.
Aha. Bin zwar jetzt schon so verwirrt, daß ich gar nichts mehr verstehe, aber ich gebe es wieder dazu, lasse das also IMMER dabei.

Die Verbindungskodierungskonfiguration sorgt einerseits dafür, dass MySQL deine Statements und (P.S.-)Daten mit der angegebenen Kodierung interpretiert, andererseits, dass es seine Rückgabewerte in dieser Kodierung ausliefert.

2B) Ausgabe von Datensätzen unter einer Bedingung mit mysqli:
$sql = 'SELECT id, name, ort, geburtsjahr FROM tabelle1 WHERE ort='.$\_POST['ortsuche'].' ORDER BY id';
$ergebnis = $db->prepare( $sql );
Integriere den Parameter so in dein Statement, wie du das bereits bei 1) getan hast. Du verwendest P.S., also brauchst du keine Daten händisch in das Statement einzubauen.
Wie meinst Du das? BITTE schreib mir doch die Zeile so hin, wie es richtig wäre.

$sql = 'SELECT id, name, ort, geburtsjahr FROM tabelle1 WHERE ort=? ORDER BY id';
  $kommando = $db->prepare($sql);
  $kommando->bind_param('s', $_POST['ortsuche']);
  // execute() usw.

Du möchtest wechselnde Daten in ein SQL-Statement einfügen. Es gibt keinen Unterschied zwischen Daten, die in die DB eingetragen werden sollen und solchen, die ein Suchkriterium darstellen. Für alle veränderlichen Daten kannst du einen Platzhalter notieren und anschließend eine Variablen-Bindung vornehmen.

echo "$verabschiedung $name";

[Brombeermilchtrinker]

Lieber dedlfix,

ich habe gerade die ersten Versuche zum Laufen gebracht ohne Fehlermeldungen oder Warnhinweise.

Danke für die Hilfe und die vielen Erklärungen. Ich werde jetzt die nächsten Tage viel üben, testen und herumprobieren und hoffentlich bald mal ein ordentliches Ergebnis vorweisen können.

Vielen Dank!

MfG

Der Brombeermilchtrinker

PS: Und somit ist dieser Thread (zuumindest von mir aus) _endlich_ abgeschlossen. :-)