Besondere Zeichen wie Umlaute in Mailheadern und Mailinhalten

E-Mail und Zeichensätze

E-Mails sind eine Errungenschaft aus dem Beginn der Internetzeit, so dass es nicht verwunderlich ist, dass deren Aufbau schon 1982 in einem Standard namens RFC822 standardisiert wurde. Über viele RFCs erfolge eine Weiterentwicklung im Laufe der Jahre, so dass nun RFC5322 der aktuelle Stelle für E-Mails ist. Durch nötige Abwärtskompatibilität besteht aber ein Problem noch immer bzw. kommt im jetztigen Zeitalter, wo sich das Internet über alle Kontinente und Sprachen verteilt hat, erst richtig zum tragen. Alle E-Mails müssen im Zeichensatz US-ASCII verfasst werden und zwar ohne länderspezifische Erweiterungen durch Codepages, wo dann auch die Umlaute wie ä,ö,ü etc. beinhaltet wären. Somit müssen alle Umlaute und besondere Sprachzeichen in eine Hexadezimaldarstellung umgewandelt werden (also alles, was mehr als die 7bit des ASCII benötigen würde um richtig dargestellt zu werden). Dabei muss der Hexadezimaldarstellung ein Gleichheitszeichen (=) vorangestellt werden. Somit wird bspw. ö zu =F6. Doch aufgepasst! Es muss die allgemeine Zeichenkodierung der E-Mail beachtet werden. In deutsch finden dabei zumeist die Zeichenkodierungen ISO 8859 – speziell ISO 8859-1 (mit Umlauten und ß) sowie ISO 8859-15 (auch € vorhanden) – sowie UTF-8, eine gebräuchliche, internationale Zeichenkodierung. In UTF-8 wäre ö das Zeichen U+00F6, welches hexadezimal dann =C3=B6 dargestellt würde.

Grundaufbau von E-Mails

E-Mails bestehen aus einem Kopfteil, dem so genannten Header, und mindestens einem Inhaltsteil. Im Headerbereich werden globale Eigenschaften der E-Mail wie Absender (From), Empfänger (To) oder Betreff (Subject) angegeben. Obwohl ich jetzt leider kein Beispiel finde, müsste hier logischerweise auch das Format und die Zeichencodierung (Content-Type bspw. text/plain; charset=”iso-8859-1) der globalen E-Mail angegeben werden können, also hier eine Textmail verfasst in ISO 8859-1. Nach der ersten Leerzeile beginnt der Inhalt. In so genannten Multipartmails können auch mehrere Inhaltsbereiche definiert werden, welche dann auch andere Zeichensätze und Inhalte enthalten. Dies wird bspw. genutzt um eine E-Mail in HTML aber auch als Text mitzusenden, falls das E-Mail-Programm kein HTML datstellen kann, oder auch um beliebige Anhänge anzufügen. Die genaue Beschreibung dessen würde jedoch noch weiter vom Thema wegführen.

Zeichensätze in Mailinhalten

Die Arbeit mit Zeichensätzen in den Inhalten einer Mail ist recht einfach. Dazu einfach im Header der Mail bzw. bei Multipartmails im Headerbereich der Inhaltssektion den Zeichensatz definieren und im eigentlichen Inhalt alle besonderen Zeichen, die nicht im Zeichensatz US-ASCII enthalten sind, in die hexadezimale Schreibweise überführen. Weiterhin muss der Header “Content-Transfer-Encoding: quoted-printable” hinzugefügt werden. Ein Beispiel:


Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Eine E-Mail mit =C4 =D6 und =DC in ISO 8859-1


Der Inhalt der E-Mail wäre dann also “Eine E-Mail mit Ä Ö und Ü in ISO 8859-1”.

Zeichensätze in Mailheadern

Die Arbeit mit Zeichencodierungen in Headerdefinitionen wie bspw. dem Von-, An-, und Betrefffeld ist etwas komplizierter, da diesen nicht künstlich wie bei Mailinhalten andere Zeichensätze zugeordnet werden können. Headerdefinitionen müssen immer ausnahmslos in US-ASCII notiert sein. Um hier trotzdem bspw. Sonderzeichen im Betreff zu ermöglichen, wurde RFC2047 kreiert. Hierin wird ein kleiner Trick standardisiert um in einer alternativen Schreibweise die Zeichenkodierung mit einzupflegen. Dabei wird der Wert des Headerfeldes mit “=?” und “?=” eingeschlossen. Nach dem ersten Fragezeichen, wobei das Fragezeichen bei dieser Variante immer als Trennzeichen genutzt wird, wird der Zeichensatz notiert, also bspw. iso-8859-1. Danach kommt eine Kurzschreibweise für die Art, in der der eigentliche Text weiter notiert wird. Dafür gibt es zwei Varianten:

1. Q für Quoted-Printable aus RFC2045
2. B für Base64 aus RFC 4648, eine weitere in US-ASCII darstellbare Zeichendarstellung.

Danach kommt als letzter Teil des Headereintrages mit dem eigentlichen Inhalt, kodiert in Quoted-Printable oder Base64, wie halt angegeben.  Die andersartige Darstellung des Headerfeldes nach RFC2047 muss dabei nicht komplett sein, sondern kann auch nur für Teilbereiche  definiert sein. Da das alles sehr kompliziert ist, hier ein paar Beispiele:

Eine Betreffzeile mit dem Betreff “Hallöchen” in ISO 8859-1 Quoted Printable und UTF-8 Base64
Subject: =?iso-8859-1?Q?Hall=F6chen?=
Subject: =?utf-8?B?SGFsbMO2Y2hlbg==?=

Eine Empfängerzeile mit Empängernamen (Jörg) in ISO 8859-1 Quoted Printable kodiert und die eigentliche Adresse wieder normal im standardmäßigen US-ASCII
To: =?iso-8859-1?Q?J=F6rg?=


Heute würden wir alles besser machen

Heutzutage hat sich UTF-8 durch seine universelle Einsetzbarkeit immer weiter verbreitet. Somit wird es auch vermehrt als Ausgangsbasis für neue Softwaresysteme oder gar Standards genommen. Würde die E-Mail also heute standardisiert werden, so ist es ziemlich sicher, dass man sofort auf UTF-8 setzen würde und alle die komplizierten Zeichenkodierungsumwandlungen in diesem Artikel wären nicht nötig. Da ein System wie E-Mail aber immer abwärtskompatibel sein muss, bleibt nur das Warten auf einen völlig neuartigen Nachrichtenstandard, der dieses Problem mit behebt und sich dann genauso weltweit durchsetzt, wie dies bei E-Mail der Fall ist. Damals war man oft schon froh, wenn es überhaupt gut in Amerika funktioniert.   

Anmerkung: Zu vielen RFC und Zeichenkodierungen, die ich hier direkt verlinkt habe, damit ich sie nicht immer neu raussuchen muss, gibt es auch schöne und verständlichere Artikel in der Wikipedia.

[twoclick_buttons]