Umlaute in E-Mails (header funktioniert schon)

[Alexander (HH)]

Moin Moin!

der Header funktioniert so wenigstens ordentlich.
  $subject = 'Text zum Ändern';
  $subject = utf8_encode($subject);
  $subject = '=?utf-8?b?'.base64_encode($subject).'?=';

Naja, etwas brutal, denn das Theater nach RFC2047 ist nur nötig, wenn der Header-Wert nicht ausschließlich aus ASCII-Zeichen besteht (/^[\x20-\x7E]*$/ trifft für den Wert nicht zu). Außerdem ist es nicht notwendig, den gesamten Header-Wert zu escapen, man *darf* auch nur Teile escapen.

Es ist aber die simpelste Methode, die man anwenden kann, ohne komplexe Stringoperationen auspacken zu müssen. Ansonsten müßte man jedes Zeichen darauf prüfen, ob es in 7-Bit-ASCII enthalten ist, und andernfalls das Escaping drumherumstricken. Und gerade bei UTF-8 ist das doch etwas fummeliger, zumal man am Ende ja vermutlich nicht jedes Zeichen einzeln escapen will, sondern vermutlich zusammenhängende Zeichen in einer Verpackung hätte.

Ich hab nie gesagt, dass man einzelne Zeichen escapen soll, die RFC2047 spricht auch ausdrücklich von "encoded words". Ich würde das Escaping des gesamten Header-Wertes aber nur dann durchführen, wenn der Header-Wert nicht in ASCII abgebildet werden kann, nämlich immer dann, wenn die o.g. RegExp nicht matcht. Auf die Art gibt es weniger Probleme mit alten Mail-Clients. Quoted printable encoding (=?utf-8?q?) statt base64-encoding (=?utf-8?b?) macht den Header-Wert in alten Mail-Clients für das ungeübte Auge lesbarer, weil damit zumindest die meisten ASCII-Zeichen unverändert bleiben.

Der aktuelle Thunderbird macht es so, sogar wortweise:

Subject: Freitagsmail, heute mal etwas =?ISO-8859-1?Q?versp=E4tet_=2E=2E?=
 =?ISO-8859-1?Q?=2E?=

Die gnadenlose Base64-Darstellung des selben Betreffs ("RnJlaXRhZ3NtYWlsLCBoZXV0ZSBtYWwgZXR3YXMgdmVyc3DkdGV0IC4uLg==") ist dagegen in alten Mail-Clients unbrauchbar.

Alexander