Ein via Content-Management-System erstelltes Mailing hat einen Link auf eine PHP-Seite, die wiederum ein Formular enthält, deren Auswertung als Mail verschickt wird. Ich kriege es nun nicht hin, mit den Umlauten so umzugehen, daß sie in der Mail korrekt angezeigt werden, egal ob dieser Ablauf aus der CMS-Vorschau oder aus der via CMS generierten, aber dann bereits per Mail-Client empfangenem Mailing heraus gestartet wird. Das CMS benutzt iso-8859-15. Die php-Seite und alles weitere habe ich mit utf-8 eingestellt. Ich nehme an, der Mail-Client verschickt automatisch mit utf-8, das CMS aber eben mit iso-8859-15. Ich dachte, ich könnte das Problem mit utf8-encode($value) lösen, das würde die eine Version (sowieso schon utf8-codiert) nicht stören und bei der anderen (iso-codiert) helfen, aber leider hilft es zwar bei der isocodierten Variante, zerstört aber die utf8-codierte.
Hallo lava,
die PHP-Seite versendet die Email mittels der Funktion mail(), nehme ich an? Im Falle von UTF-8 muss das Charset im Content-Type-Header mitgeteilt werden.
mail("empfaenger@exampl.com", "Betreff der Email", "Inhalt der Email", "From: absender@example.org" . "\r\n" . "Content-Type: text/plain; charset=utf-8");
Hallo, ich glaube, das Problem würde auch ohne Mail auftauchen (das von dir genannte Header habe ich eingestellt, daran liegt es nicht), wenn man direkt auf der PHP-Seite einfach nur echo $param schreiben würde.
Also man kriegt einen Seitenaufruf seite.php?param=.....
und seite.php soll etwas mit dem param machen (eine Mail draus generieren, die diesen param ausgibt; oder den param direkt ausgeben). Dummerweise bekommt die Seite den param aber, je nachdem ob sie aus der CMS-Vorschau heraus aufgerufen wird oder aus einem vom CMS generierten und vom Empfänger geöffneten Mailing heraus aufgerufen wird, entweder iso-codiert (aus der CMS-Vorschau) oder anders (da die Darstellung richtig ist, würde ich mutmaßen, daß der Mail-Client automatisch die utf8-Codierung nutzt). Man weiß also nicht, in welcher Form der Param kommt. Ich bräuchte jetzt einen Befehl, der im richtigen Format nicht schadet und im falschen Format hilft. Hätte gehofft, daß es mit utf8_encode(urldecode($param)) geht, aber leider benimmt sich das genauso wie ein reines utf8_encode($param) und codiert offensichtlich einen bereits "richtigen" Input dann auch nochmals mit, so daß dann für diese Variante Müllzeichen entstehen.
Achso, die Werte werden über Parameter im Query String übergeben.
Das Problem könnte sein, dass utf8_encode() als Eingabe einen ISO-8859-1 kodierten String erwartet. Wenn der String iso-8859-15 kodiert ist, gibt's dann wohl Zeichensalat.
Probier's mal mit dieser Funtkion:
http://www.php.net/manual/de/function.iconv.phpHilft leider nicht :(
iconv("iso-8859-15","utf-8",$param) benimmt sich ganz genauso wie utf8_encode($param), d.h. es erwartet offenbar die iso-Codierung (und wenn stattdessen doch ein utf8 kommt, behandelt es diesen trotzdem als iso und codiert ihn nochmal weiter zu anderem Mist)
Wie benehmen sich denn normalerweise PHP-Seiten, die Parameter mit Sonderzeichen bekommen können, aber nicht wissen, in welcher Codierung sie die kriegen (weil sie eben von verschiedenen Leuten/Systemen aufgerufen werden, die unterschiedliche Voreinstellungen haben)?
Google lässt sich den Charset in einem (bzw. zwei) Parametern übermitteln:
http://www.google.com/search?client=opera&rls=de&q=test&sourceid=opera&ie=utf-8&oe=utf-8
Wenn man ein Google-Suchfeld auf seine Seite einbaut, muss dieser Parameter entspechend dem Charset der Seite gesetzt sein
Leider hilft auch das nicht weiter: denn der Aufruf erfolgt entweder direkt aus der Vorschau des Mailings oder aus dem versandten Mailing, und beides bezieht sichs aufs selbe CMS, da stehen dieselben Parameter drin (d.h. wenn ich im CMS ein ie=.... definieren würde, stünde das auch unverändert in der Mail, .... obwohl offenbar der Mail-Client - anders kann ich es mir nicht erklären - dann den charset nochmal ändert....)
Sind die Parameter urlcodiert? dann sollte die erste Email den Charset nicht ändern können.
im CMS: urlencode()
auf der PHP-Seite: urldecode() und anchließend iconv("iso-8859-15","utf-8",$param)
Auch iconv("iso...","utf-8",urldecode($param)) hatte ich schon probiert - aber ich hab im CMS nichts urlencoded, weil das wiederum den Param als seite.php?param=<xsl:value-of select="..."> aufruft und dabei Xpath 1.0 verwendet wird, was wohl kein urlencode kennt (gibt es wohl erst ab Xpath 2.0)
Es freut mich aber immerhin, daß ich mit meinen Gedanken nicht so ganz falsch liege.