MIME::Lite and... just another Schei? encoding...

[Patrick Andrieu (noreg)]

Re!

Mittlerweile bin ich fast überzeugt, dass der Murks seitens der Webmail-Anbieter passiert.

Nach weiteren Versuchen heute nachmittag:

$obigeAusage =~ s/fast/fest davon/;

Ein PHP-Mailer, den ich auf Kundenseiten einsetze, bei deren Hoster Perl nicht zur Verfügung steht, habe ich heute getestet. Gebe ich als Betreff vor: »Kontakt über Kundenseite-Formular«, kommt beim »ü« bei den vorhin genannten Webmailern (nicht bei den Mail-Clients, zumindest nicht bei denen, die ich unter Windows einsetze), Zeichenmüll an.

Nun habe ich die Wahl zwischen:

• alles lassen, wie es in meinem Vorposting aussieht
  • oder: jeder Parameter wie der Webseiten-Titel und
    die User-Eingaben: Name, Empfänger-Name, Message durch
    decode('UTF-8', $param) zu behandeln, um danach jeweils:
    Data => encode('iso-8859-1', $html)  / $plain bei
    der selben charset-Angabe bei »Type« einzugeben.

Dann kommt es sowohl bei den fraglichen Webmailern als auch bei den Windows-Mail-Clients korrekt an - bis auf evtl. Sonderzeichen im »document.title«, Namen und/oder Nachricht, die es in iso-8859-1 nicht gibt - diese erscheinen dann als Fragezeichen.

Ich will mit meinem Service nicht international sein, schön wär's gewesen, aber anscheinend geht es aufgrund dieser allen Anschein nach miserabel programmierter Webmailer nicht anders. Seitzeichen (das ist übrigens der Anbieter, von dem ich den Anstoß hatte, was Eigenes zu machen), macht es nicht anders: iso-8859-x anstatt utf-8.

Die Frage lautet nur: Was ist besser? Die perfektionistische Variante (UTF-8), die in Kauf nimmt, dass Nutzern von Webmailern Zeichenmurks erhalten, oder die rationellere, die einkalkuliert, dass die meisten User hierzulanden sitzen werden, und daher eher auf iso-8859-x setzt?

P.