Zur Verwendung von Umlauten in E-Mail

oder
Gibt es noch Leben hinter ASCII 127 ?

Die Verwendung von Umlauten im E-Mailverkehr ist grundsätzlich problematisch. Da die Amerikaner in der Verwendung von E-Mail ja schon etwas weiter als der Rest der Welt sind, hat man dort leider schon früh Konventionen "zementiert", die dem Rest der Welt gelegentlich Probleme bereiten.
Eines dieser kleinen Probleme ist die Verwendung von Umlauten und sonstigen Sonderzeichen, die über den ursprünglichen ASCII-Zeichensatz mit seinen 128 Zeichen (0 - 127) hinausgehen.
Diese ersten Zeichen lassen sich jeweils mit 7 Bit darstellen. Um weitere Zeichen verwenden zu können, müssen 8 Bit zur Kodierung der Zeichen verwendet werden. Leider sind die meisten UNIX-Mailserver, Gateways, Router etc. jedoch auf die Verwendung des Zeichensatzes 7-Bit US-ASCII voreingestellt, sind also nicht in der Lage, anders kodierte Zeichen (z.B. Umlaute) korrekt zu übertragen.

Welche Konsequenzen hat das?

E-Mail wird unter Umständen über sehr viele Stationen gereicht, bis es seinen Adressaten erreicht hat. Wenn nur eine der Zwischenstationen nicht auf 8-Bit eingestellt ist, wird die Mail fehlerhaft dargestellt.

Mögliche Abhilfe: Einfach keine Umlaute/Sonderzeichen benutzen!
Mein kleiner Sohn macht das übrigens genauso:
Er hält sich die Augen zu. Was er nicht sieht, ist auch nicht da...

Nun könnte man ja die Hoffnung haben, daß irgendwann einmal auch der letzte Server 8-Bit versteht. Irgendwann in ferner Zukunft. Und es ist so, daß es Normen gibt, in denen man festgelegt hat, welches Zeichen zu welcher Zeichensatznummer gehört. Eine dieser Normen hört auf den schönen Namen ISO-8859-1 und sollte eigentlich irgendwie auf jedem vernünftig eingestellten Rechner verwendbar sein, egal welches Fabrikat und Betriebssystem verwendet wird.

Schöner Traum.

In bestimmten Bereichen (dazu gehört TR, aber noch lange nicht alle Teile der FHH...) funktioniert ISO-8859-1, wenn man sein Mail-System anweist, diese Norm zu verwenden.
Der Mail-Server am Studiengang TR (läuft auf einem Apple Macintosh) versteht diese Norm und gibt sie über das TR-Gateway hinaus in die weite Welt, wo dann andere Leute weiter dafür verantwortlich sind. Die bei uns verwendeten Mail-Agenten Netscape und Eudora für den Macintosh schicken ihre Daten (weitgehend automatisch) richtig an den Mail-Server.
Netscape geht sogar soweit, den Mail-Inhalt zu interpretieren. Das bedeutet: Wenn man keine Umlaute verwendet, wird die Mail nach US-ASCII 7-Bit-Standard kodiert, wenn mindestens ein Umlaut im Mailtext vorkommt, nach dem Standard ISO-8859-1 mit 8-Bit.

Soweit, so gut, so bequem.

Wenn man den Gedanken zu Ende führt, wird man feststellen, daß das eigentliche Problem, nämlich die Unmenge von Servern, Gateways und Routern etc. mit 7-Bit-Einstellung weltweit noch länger ein Problem darstellen werden. Diese Geräte laufen nämlich z.T. seit Jahren weitgehend ohne Änderung, sodaß die zuständigen Administratoren verständlicherweise nur ungern Veränderungen vornehmen, getreu dem Motto: Never touch a running system.
An dieser Stelle greift dann der Standard MIME. Eine seiner Festlegungen beschreibt u.a. auch den Umgang mit Umlauten und Sonderzeichen in einer real existierenden 7-Bit Welt. Einzelne Umlaute z.B. werden hier nach einem bestimmten Verfahren (wie bei den SGML-Entities) in Zeichenketten umgewandelt, die ausschließlich aus dem 7-Bit Zeichenvorrat stammen. Nachher werden sie vom Mail-Reader wieder zum korrekten Einzelzeichen zusammengesetzt.
Konsequenz: Man kann seine Server, Gateways etc. laufen lassen wie sie gerade sind und muß intelligente Mail-Agenten verwenden. Netscape und Eudora für den Macintosh genügen diesen Anforderungen.
Im Falle von Netscape muß man sich nur einmal entscheiden, ob man eine 8-Bit-Übertragung zulassen will oder die 7-Bit-konforme MIME-Kodierung verwenden will. Zu finden unter "Options/Mail and News/Composition". Ich empfehle die universell verwendbare MIME-Kodierung, die manchmal auch als "quoted printable" bezeichnet wird.
Mit den Kollegen abstimmen, anklicken und gut ists.

Unterm Strich könnte man jetzt denken, daß es eine Kleinigkeit ist, zumindest den überschaubaren Bereich der Fachhochschule Hannover auf die Verwendung eines Standards einzuschwören.

Weit gefehlt.

Ein großer Teil der Anwender bemerkt nämlich gar nicht, daß seine Übertragung fehlerhaft ist. Motto: Wenn ich es auf meinem Bildschirm richtig schreibe (mit Umlauten etc.), dann kann ich davon ausgehen, daß das auf der anderen Seite auch so ankommt.

Leider zu einfach.

Die weltweit gültigen ISO-Normen stammen leider nicht aus dem Hause Microsoft und deshalb gibt es da einige Probleme...
In vielen Fällen ist es nämlich so, daß der auf den meisten DOS-kompatiblen PCs voreingestellte Zeichensatz der Codepage 437 (oder 850) ungefiltert und ohne weitere Interpretation auf die Menschheit losgelassen wird. Wenn auf der anderen Seite ein ähnlicher PC und das gleiche E-Mail-Programm mit den gleichen (Nicht-) Einstellungen verwendet wird, hat man eine reelle Chance, daß die Mail genauso dargestellt wird wie vom Absender gewünscht. Im Bereich der FHH trifft das in vielen Fällen zu.

Immer? Leider nicht immer...

Achtung: Jetzt kommt der satirische Teil!
Es gibt doch tatsächlich noch Leute, die verwenden etwas anderes als Pegasus Mail auf einer DOSe. Es gibt sie noch, die kleine Zahl der Mac-Anhänger und Unix-Anwender. Weltweit einige hunderttausend. Und da klappt das nämlich nicht mehr so einfach. Wenn man mit diesen Querulanten und Abweichlern kommunizieren will, muß man sich an internationale Standards halten. Man kanns nicht einfach so laufen lassen. Das ist lästig und macht Arbeit. Man sollte sie eigentlich abschaffen. Wie leicht wäre das Leben ohne diese Nörgler, die behaupten, daß es Systeme gibt, bei denen alles leichter geht, ohne das Fummeln an irgendwelchen INI-Dateien und Registration Databases.

Aber sie bleiben einsame Rufer in Billy-Boys großer WINTEL-Winzigweich-DOSen-Wüste.

Mit einem ganz kleinen Funken Hoffnung...


Fachhochschule Hannover/Homepage | Fachbereich IK | Studiengang Technische Redaktion

Zuletzt geändert: 03. 02. 1999 (JHP)
Verantwortlich: Jan-Henrik Preine