Der Bericht erläutert, daß 7-Bit-Zeichen rechnerunabhängig verwendet werden, die 8-Bit-Erweiterung um Sonderzeichen aber zu firmenabhängigen, nicht konformen Darstellungen geführt hat, die eine Textübertragung von Rechner zu Rechner erschweren oder unmöglich machen. E-Mail ist aber durch MIME normgerecht erweitert worden, so daß die Verwendung neuere Software zur Aufbereitung der Rechnerpost eine unproblematische Übertragung auf beliebige Empfängerrechner mit korrekter Umlautdarstellung ermöglicht, sofern sich der Absender die Mühe einer entsprechenden Anpassung macht. Verzichtet er darauf, darf er keine Umlaute verwenden und kann empfangene Texte weder korrekt lesen noch drucken.

Zwei Anhänge zeigen in Beispielen die wichtigsten Unterschiede der Textdarstellungen in heutigen Rechnern sowie häufige Fehlersituationen und notwendige Gegenmaßnahmen.

The report describes the reason for the frequently observed e-mail incompatability with respect to special characters, namely a company oriented character extension from 7 to 8 bit character sets resulting today in incompatible product dependent text representations. Since every message is being produced in native character mode standards have to be observed by the e-mail software, namely a translation to ISO-Latin-1, in order to achieve a correct interpretation on an arbitrary receiving computer. MIME is the respective protocol extension to be used, it is already implemented by more recent versions of e-mail software.

Two appendices demonstrate the most important differences of text representations in current computer systems as well as frequent error situations and counter measures necessary.

1. Einführung

Warum herrscht Zufriedenheit darüber? Sind Sie nicht Informatiker und daher dafür verantwortlich, daß Ihre Systeme auch im Primitivbereich, zu dem e-Mail ja wohl im Zeitalter von WWW-Browsern mit Applet-Funktionen und Multimedia-Integration zählt, mindestens Grundfunktionen erfüllen?

Wo bleibt Europa im Zeitalter des Internet? Ist es nicht ein Ausdruck von Bildungsarmut, wenn Deutsche und Franzosen, Spanier und Dänen immer nur Englisch zur Kommunikation verwenden und dabei verlernen, ihre eigenen Sprachnuancen auch korrekt in Rechnerpost auszudrücken? Warum funktionieren bei Ihnen alle Akzente und Sonderzeichen einwandfrei in Textsystemen, nicht aber, wenn Texte von anderen Rechnern kommen, mit Sicherheit nicht zuverlässig? Die Antwort sei schon hier verraten: Sie müssen Ihre Software ändern, denn die ist vermutlich veraltet und nicht weltoffen, im Gegensatz zu Ihrer Hardware!

2. Braucht man Umlaute?

Die älteren Kollegen werden sich an die Zeit erinnern, als Lochstreifen und Fernschreiber von Bildschirmgeräten abgelöst wurden. Plötzlich standen große und kleine Buchstaben zur Verfügung, wenn man sie nur benutzen wollte. Bald waren sie allgemein in Rechnern darstellbar, doch die Programmiertechnik griff nur langsam auf die neuen Möglichkeiten zu, so daß noch heute in vielen Bereichen auf Mischung und Variation verzichtet wird, z.B. bei Unix-Kommandos, den Konstrukten wie if, for, while in Programmiersprachen und leider vielfach auch bei Zugangskennwörtern, worüber sich jeder Hacker freut. Ist hier der einfache Benutzer schon überfordert, wie Fehler der Verwechslung von gleichlautenden, aber verschieden geschriebenen Namen nahelegen (path, PATH)? Hier geht es nur um die unkomplizierte Erweiterung: viele haben gar nicht gemerkt, daß neue, fehlerfreie Möglichkeiten für Variablennamen bestanden, eine Folge erfolgreicher Standardisierung, hier der USASCII-Norm, die einen 7-Bit-Datenaustausch von Rechner zu Rechner ermöglicht, indem sich alle Rechnerhersteller dieser Norm anschlossen und alle Benutzer mit dem gleichen Zeichensatz zufrieden waren, sogar über die westliche Welt hinaus.

Da auch der Nachrichtenaustausch von Rechner zu Rechner vor 25 Jahren entstand, hat gerade diese frühe Norm z.T. dafür gesorgt, daß die heutigen Probleme der Deutschen mit ihren Umlauten bestehen. Man brauchte ein Adressiersystem für Absender und Empfänger, und was lag näher, als dies den Rechnern selbst zu überlassen? Vielleicht war es gerade diese Bequemlichkeit, die schließlich auch der Internet-Idee entgegenkam, die zur raschen Verbreitung dieses neuen Nachrichtenmediums beitrug? War nicht jeder Rechnerbenutzer potentiell auch Absender oder Empfänger? Hatte er nicht bereits ein eindeutiges Zugangskennzeichen in Form des login-Namens zumindest für seinen Rechner? Mußte nicht das Internet seinerseits für die eindeutige Kennung aller vernetzten Rechner sorgen, für die allein Nachrichtenaustausch wichtig war? Tatsächlich ist das mit dem Internet-Adreßsystem mittels 32-Bit-Adressen überaus erfolgreich gelungen, wobei eine weitere de-facto-Norm Verwendung findet, doch soll das hier nicht weiter interessieren.

Wichtig ist nur, daß die Internetknoten stets den ISO-7-Bit-Code verstehen, darüber hinaus aber bezüglich der Transportmechanismen im Internet nichts genormt werden kann. Das ist sehr leicht einzusehen, denn schließlich muß Genormtes auch eingebbar sein. Tastaturen aber entziehen sich einer allzu großen Flexibilität, weil die Tasten beschriftet werden müssen. Hier geht schnell jede Übersicht verloren, denn mehr als 48 Tasten oder so mit je 2 oder 3 Belegungen lassen sich nicht gut verwenden. In manchen Fällen läßt sich schon heute ein gesuchtes Sonderzeichen nur schwer oder gar nur mit Rückgriff auf eine Hilfstabelle neben dem Rechner eingeben. Da ist es viel einfacher, für die Kopfzeilen jeder Nachricht vorzuschreiben, daß ausschließlich 7-Bit-Zeichen verwendet werden dürfen, nicht nur bisher, sondern auch in absehbarer Zukunft! Pech für alle Zeitgenossen, die gern Namen als implizite Adressen verwenden, aber ihren eigenen nicht im englischen Alphabet ausdrücken können.

Übrigens ist das auch ein Grund für eine erste Folgerung: Selbst wenn das Betriebssystem des eigenen Rechners auch 8-Bit-Zeichen erlaubt, ist man schlecht beraten, wenn man Namen mit Umlauten für Postkästen, also Adressen, zuläßt. Man beschränkt dann die Rechnerkommunikation auf den lokalen Bereich und wird sich schnell wundern, daß nie von außen Nachrichten eingehen. Apple-Rechner mit Quickmail sind hierfür ein deutliches Beispiel: nur Mac-Rechner mit gleicher Zeichenanordnung sind mit dieser Adreßerweiterung kompatibel.

Eine zweite, naheliegende Folgerung schüttet das Kind mit dem Bade aus und ist der eigentliche Anlaß für diesen Beitrag: Wenn schon bei den Kopfzeilen nur 7-Bit-Zeichen verständlich sind, kann man doch auch den Textteil der Nachricht so behandeln, also Umlaute ersetzen, z.B. ä = ae, oder gleich die englische Sprache benutzen! Das ist bis vor 4 Jahren notwendig gewesen, heute aber nicht mehr zeitgemäß und sollte auch mit Blick auf Europa nicht mehr gelten. Informatiker müssen aber diesen Wandel einsehen und selbst dafür sorgen, daß auch die Alltagssprache uneingeschränkt bei Rechnerpost verwendbar wird, wer soll es sonst tun? Gerade bei Namen ist anders eine korrekte Informationsübertragung nicht möglich, wie ein Blick ins Telefonbuch bestätigt: es ist ein Unterschied, ob jemand Mues, Müssig oder Müßig heißt und in Coesfeld oder Cöthen wohnt, folglich ist die obige Substitution durch 2 Buchstaben unzulässig! Niemand verzichtet ja auch im Bereich konventioneller Briefe auf die Benutzung der Umlaute.

3. Kompatible und inkompatible Zeichenmengen

Andererseits haben sich die internationalen Normgremien mit der Frage befaßt und sich vor etwa 10 Jahren auf verbindliche Standards geeinigt: ISO-8859-1 bis ISO-8859-9 sind alternative 7-Bit-kompatible Erweiterungen auf 8 Bits, von denen ISO-8859-1 oder ISO-Latin-1 hier allein betrachtet werden soll, weil sie die Textdarstellung im westeuropäischen Sprachbereich ermöglicht, soweit früher Schreibmaschinentexte üblich waren /3/.

Selbstverständlich erfüllt folglich ISO-Latin-1 auch die Anforderungen an den Textteil von Rechnernachrichten. Der Laie könnte also schließen, daß es ausreichend sein müßte, Latin-1 zu verwenden, also dem eigenen Rechner diesen Zeichensatz über entsprechende Tabellen beizubringen, dann müßte doch die Kommunikation funktionieren. In der Tat gelingt es hin und wieder, daß Rechnernachrichten Umlaute darstellen, aber das mag Zufall sein, denn noch fehlen mehrere Randbedingungen, nämlich die Vereinbarungsweise, wie unterschiedliche Rechner den richtigen Zeichensatz zur Darstellung auswählen sollen, kurzum das nunmehr erweiterte e-Mail-Protokoll. Auch ohne dieses kann man dem Zufall nachhelfen, etwa wenn man bei Absender und Empfänger gleiche Rechner verwendet, zu einander kompatible Software benutzt und der betroffene Internet-Abschnitt 8-Bit-Transport vorsieht...

4. Rechnerunabhängigkeit als Grundforderung

a)	die rechnerorientierte Codierung (z.B. Apple-Latin-1) muß in ISO-Latin-1 gewandelt werden, damit Benutzer anderer Rechner die Nachricht lesen können,
b)	falls das Internet nicht überall 8-Bit-Übertragung zuläßt, sollte die Nachricht trotzdem einschließlich aller Umlaute übertragbar sein.

Beides kann nur durch Software gelöst werden, was voraussetzt, daß normfähige Anforderungen vorgegeben sind, die einen erweiterten Transport im Internet erlauben. Sie liegen seit 1993 als Requests For Comment 1521 vor /4/ und bilden Protokollvereinbarungen, die unter der Bezeichnung MIME (multipurpose internet mail extensions) Teil jeder zeitgemäßen Anwendungssoftware für Rechnernachrichten und deren Implementierung sein sollten.

Was verlangt diese Erweiterung? Natürlich vielerlei, was in Anbetracht des Umfangs dieser Anforderungen hier nicht behandelt werden kann, da neben einer besseren Textübertragung mehrere weitere Ziele angestrebt werden (z.B. Anhänge in der gleichen Nachricht in graphischer, in Audio- oder Videoform). Erläutert sei nur die Auswirkung auf die Umlautübertragung. Ein erstes Kennzeichen ist eine weitere Kopfzeile in Ihrer Rechnernachricht, die

MIME-Version: 1.0

lautet und erkennbar macht, daß die Anwendungssoftware erweiterte Nachrichten erzeugt und es sich um eine MIME-konforme Nachricht handelt. Weitere Angaben betreffen eventuell Codierungen der 8-Bit-Zeichen für den Transfer sowie den Inhaltstyp der Rechnernachricht. Hier ist "text/plain" zu erwarten, außerdem der ISO-Zeichensatz, also gibt es eine weitere Kopfzeile:

Content-Type: text/plain ; charset = "ISO-8859-1"

Alle weiteren Minimalanforderungen können hier außer Betracht bleiben, solange von mehrteiligen Nachrichten (z.B. Text + Audio-Daten) abgesehen wird und auch Fehlerreaktionen beim Transport zurückgestellt werden. Erwähnt sei nur, daß "US-ASCII" auf jeden Fall erkannt werden soll, was aber wohl nichts darüber aussagt, wenn mehr als 7 Bits angeboten werden: solche Widersprüche muß der Empfänger als Zufall erleben.

Andererseits sind weitere Parameter einstellbar, z.B. QP (quoted printable), das z.B. Eudora Light 1.5.4 einfach ein- oder auszuschalten erlaubt, wodurch zwei Varianten jeder abgesandten Nachricht entstehen: eine MIME-konforme Umsetzung der erweiterten 8-Bit-Zeichen in drei 7-Bit-Zeichen (= xy, wobei xy den Bereich 80 bis FF angegeben, durch den das 8-Bit-Zeichen sedezimal in der Codetabelle beschrieben wird) oder direkte Versendung. Entsprechend lautet die (dritte zusätzliche) Kopfzeile in diesen Fällen

	Content-Transfer-Encoding: quoted-printable
oder	Content-Transfer-Encoding: 8bit.

Beide Varianten werden natürlich nach dem Empfang identisch dargestellt, so daß die beschriebenen Eigenschaften nicht unterscheidbar sind, wenn, wie meist üblich, erledigte Kopfzeilen in der Nachricht nach Empfang gelöscht werden.

5. Technische Randbedingungen der Universalität

Als erstes ist die Anwendungssoftware einer gewissen Kritik zu unterziehen. Jeder installiert sie und will sie anschließend benutzen, wobei das Feld der Dokumentation sträflich vernachlässigt wird. Da der hier berührte Bereich klein ist, fällt dieser Mangel desto deutlicher auf: von MIME bleibt der Eudora-Benutzer bis auf die Entscheidung verschont, ob er QP ein- oder ausschalten soll. Was aber soll er tun? Die Hilfe ist dürftig: "Eudora is allowed to use MIME Quoted-Printable encoding if necessary (Good idea)". Schaltet man QP aus, erhält man den Hinweis: "MIME Quoted-Printable encoding will NOT be used, no matter what (Bad idea)". Die Dokumentation sagt zusätzlich: "If checked, QP-encoding may be used when sending messages that contain long lines of text or special characters... It is recommended that it always be checked". Der Leser mag selbst entscheiden, wie aussagekräftig diese Hinweise sind. Immerhin sind alle seine Nachrichten MIME-kompatibel, egal, was er bezüglich der Übertragung auswählt. Keinerlei Hinweis erfolgt jedenfalls über den verwendeten Zeichensatz. Nur wenn man die Kopfzeilen der eigenen Nachricht analysiert, erkennt man, daß mit Eudora korrekt ISO-8859-1 verwendet wird, obwohl jeder Mac intern einen anderen Code benutzt (Apple-Latin-1).

Das deutet die zweite Randbedingung an, die zu überraschenden Konsequenzen führt: der Benutzer hat keinen Hinweis darauf, in welcher Form der Text gerade ist, den er auf dem Bildschirm vor sich sieht. Das wäre unerheblich, wenn es wie bei den ASCII-kompatiblen Zeichen 0 bis 127 (genauer 32 bis 126) auf jedem Rechner in gleicher Weise geschieht. Doch ist das ja gerade der Unterschied zwischen ISO-Latin-1 und Apple-Latin1, einmal (im letzteren Fall) ist ä = 8A (138), im anderen Fall ä = E4 (228)! Wie üblich, bleibt die Wandlung dem Benutzer verborgen, d.h. auf dem Mac-Bildschirm ist jedes ä wirklich 138 als Oktettwert, aber sowie der Text den Rechner verläßt, wird er nach ISO-Latin-1 gewandelt. Umgekehrt erfolgt das beim Empfang, so daß aus diesem Mechanismus folgt, daß der gleiche Text innerhalb und außerhalb der Mac-Welt verschieden ist und keineswegs aus einer eindeutigen Bytesequenz besteht. Das ist die unschöne Folge der unter 3. oben geschilderten Firmenorientierung der Zeichendarstellung, an die man längst nicht mehr denkt. Aber deren Auswirkung ist im Prinzip lange gelöst, denn bei jeder Textübertragung mit fetch oder ftp ist die gleiche Umsetzung erforderlich, die automatisch im Textmodus zwischengeschaltet ist, während der Binärmodus darauf verzichtet. Wie schön waren die alten Zeiten, als es nur stets gleiche 7-Bit-Zeichen gab!

Damit wird die dritte Randbedingung angesprochen, die aber technisch Interessierten vorbehalten bleiben mag: wie läßt sich denn dieser gerade behauptete Schritt der Zeichensatzwandlung überhaupt sichtbar machen, wenn man schon bereit ist, an ihn zu glauben? Zwar ist das nicht selbstverständlich, aber leicht machbar, wenn man seine Post auf einem anderen Rechner bearbeiten kann, z.B. Sun, die entsprechend über einen Zeichensatz Sun-Latin-1 verfügt, der auch nicht gleich ISO-8859-1 ist, aber im Gegensatz zu Apple-Latin-1 zu großen Teilen deckungsgleich. Da Editoren (wie BBEdit 3.0.1) eine Option zur Bytedarstellung aufweisen, kann man gleiche Textinhalte von verschiedenen Rechnern im Hinblick auf die Umlaute vergleichen, übrigens eine lustige Übung für jeden Informatiker, der dabei erst lernt, wie fest die Darstellung intern auch an die Ausgabe auf dem Bildschirm gekoppelt ist und was ein Drucker aus dem beschriebenen Problem macht. Längst haben wir uns überall daran gewöhnt, daß alles rechnerorientiert im gleichen Betriebssystem funktionsfähig aufeinander abgestimmt ist. Die geschilderte Abweichung der Zeichensätze führt deshalb zu den bekannten Überraschungen, hat also nichts mit Zufällen zu tun, sondern nur mit Inkompatibilität.

Die vierte Randbedingung betrifft die Übertragung: was wird bei Verzicht auf QP aus der Nachricht, wenn unterwegs eine 7-Bit-Verbindung zwischengeschaltet war? Hier ist der Effekt unschwer einzusehen: das 8. Bit wird einfach Null, so daß jedes Zeichen aus dem oberen Bereich in den unteren abgebildet wird: aus ä = E4 (228) wird d = 64 (100), aus ö wird v usw. Auch hier wundert man sich, warum das passiert, denn das Internet läßt ohne weiteres 8-Bit-Zeichen zu. Ob es an der oben unter 2. geschilderten Beschränkung der Kopfzeilen auf 7 Bits liegt? Natürlich geht dabei das ursprüngliche Zeichen verloren, was sich leicht erkennbar im Antwortmodus zeigt, falls der ursprüngliche Nachrichteninhalt zurückgesandt wird.

Als fünfte Randbedingung sei ausdrücklich darauf hingewiesen, daß zwar beim Transfer von Rechner zu Rechner die Textzeichen ihre Bedeutung behalten, aber u.U. dabei ihren Oktettwert ändern, sofern alles korrekt eingestellt ist. Letzteres wirkt wie ein Zauber, wenn der Benutzer sich lange mit falschen Einstellungen herumschlagen mußte. Besonders im Unix-Bereich sind die meist verdeckten, in Punktdateien verborgenen Laufanweisungen entsprechend zu modifizieren, z.B. in Elm (Version 2.4 PL25) die Datei ~/.elm/elmrc mit den Zeilen

 charset="ISO-8859-1"
 displaycharset=iso-8859-1
 textencoding=8bit ,

Damit dürfte deutlich werden, daß es der Kopf der Nachricht ist, der dem kompatiblen Rechnerpostprogramm mitteilt, wie der Inhalt zu behandeln und darzustellen ist: passen beide zusammen, werden die erweiterten Zeichen problemlos auf dem Bildschirm dargestellt, aber nur dann. Da weder Absender noch Empfänger einen Einfluß auf die Bitbreite der Übertragung haben, wird die im vorigen Abschnitt zitierte Empfehlung verständlich: der Modus QP erlaubt auch dann die automatisch korrekte Übertragung aller Umlaute, wenn ein Übertragungsabschnitt das 8. Bit zu Null setzt, also das ASCII-Alphabet erzwingt. Kann man sich dagegen auf alle 8 Bits verlassen, erlaubt der Verzicht auf QP eine Umlautdarstellung auch durch nicht MIME-konforme e-Mail-Programme, sogar zu verschiedenen Rechnertypen, wenn auf ihnen ISO-Latin-1 einstellbar ist. Offenbar sind es die unterschiedlichen Kombinationen dieser Möglichkeiten, die bisher die Umlautbenutzung behindern, doch läßt sich meist die Inkompatibilität leicht beheben, wenn man sich nur darum bemüht.

6. Die Absendersoftware muß normkonform sein

An einer Stelle sind auch die Übertragungsknoten angesprochen, die die Weiterleitung der Rechnerpost bewirken. Hier könnte man vermuten, daß es keine Rolle spielt, ob sie nur die alten Eigenschaften unterstützen oder selbst Meldungen erzeugen, die sich an die Erweiterung halten. Eine 8-Bit-Übertragung des Textteils der Nachrichten sollte ausreichen. Das ist aber nicht richtig, denn im Fehlerfall werden häufig MIME-konforme Nachrichten ergänzt oder zurückgeschickt. Das ist offensichtlich sinnlos, wenn dabei MIME-Vereinbarungen verletzt werden, z.B. indem eine MIME-Nachricht um weitere Teile mit Rückweisungsinformationen des Übertragungsknotens erweitert wird. Hier geht die MIME-Lesbarkeit verloren, solange sie nicht mit MIME-Kopf versehen wird. Der ahnungslose Absender sieht dann sein eigenes Produkt in sehr unleserlicher Form wieder, z.B.:

Der Bo=DF l=E4=DFt gr=FC=DFen und w=FCnscht Gl=FCck!

Man sieht aus diesem Satz, daß eines der Ziele von MIME eine Substitutionsart war, die den Text nur wenig oder höchstens zumutbar stört, wenn nichtkonforme Software die Weiterleitung besorgt. Leider kehren Systemverwalter in Deutschland heute die Argumente um: anstatt für die konforme Behandlung der Nachrichten im Fehlerfall Sorge zu tragen und MIME-Nachrichten im Rahmen einer MIME multipart message zusammen mit den Fehlerhinweisen an den Absender zurückzuschicken, halten sie das Problem für eine Angelegenheit des Absenders. Offenbar haben sie selbst bisher keine Umlaute benutzt oder verfügen nur über einen recht verkümmerten Kommunikationsbedarf. Auf jeden Fall sorgen sie für ein bißchen zusätzlichen Zufall im oben angesprochenen Sinn.

7. Zukunftsaussichten und Zukunftswünsche

Was bleibt offen, ist zukünftig erforderlich, wäre zu wünschen? Der Einbau von Graphik, ja Audio- und Video-Ergänzungen werden ermöglicht, indem mehrteilige Nachrichten entstehen und Postprogramm bzw. Betriebssystem dafür sorgen, daß die verschiedenen Teile korrekt weitergeleitet werden: also Text auf den Bildschirm, Audio-Daten auf den Lautsprecher und nicht umgekehrt! Das kann nur funktionieren, wenn der Charakter einer MIME-Nachricht nicht verändert wird, auch nicht im Fehlerfall, was derzeit noch verbreitet in Deutschland geschieht (leider z.B. bei der Informatik in Karlsruhe, nicht dagegen bei der Informatik der TU München oder der TU Wien, was beweist, daß eine Implementierung möglich ist, die auch auf den Fehlerfall korrekt reagiert). Dann ergibt sich eine erste deutliche Verbesserung: der Unterschied zu voice mail verschwindet mehr und mehr, beide Kommunikationsarten werden integrierbar.

Trotzdem reicht die Textkommunikation im Hinblick auf weitere Verfeinerungen nicht aus: es gelingt z.B. nicht, griechische oder russische Wörter im Text korrekt zu zitieren oder komplexe mathematische Formeln zu übertragen, sogar die französischen Buchstaben und fehlen. Immerhin geht dies holprig, indem westeuropäische, griechische (mit ISO-8859-7) oder kyrillische Textabschnitte (mit ISO-8859-5) getrennt angesprochen werden, also häßliche Kopfzeilen für die einzelnen Teile auftreten. Aber das ist auch in Rechnern heute nicht mit der linken Hand zu lösen, obwohl griechische oder sonstige Fremdsprachen z.B. in MS Word weitgehend darstellbar sind, wenn auch etwas umständlich. Das Problem liegt wieder im Zeichensatz ISO-Latin-1, der auch bei 8-Bit-Verwendung grundsätzlich im Umfang begrenzt bleibt. An dieser Stelle ist auf Unicode hinzuweisen, eine Erweiterung der Zeichenmengen auf 2 oder mehr Bytes, um beliebige Sprachen und Schriften der Welt darzustellen /5/. (Genau genommen ist das bereits passiert: die Wahl von ISO-8859-x mit x = 1 bis 9 erlaubt ja eine Auswahl unterschiedlicher Alphabete.) Allerdings wird mit dessen Einführung ein großer Schritt für die Darstellungsweise fällig: das Abgehen von einem Byte pro Zeichen und damit von der kompakten Darstellung der Information. Wegen der erwähnten Kompatibilität bleibt das vorläufig vermutlich Zukunftsmusik. Leben wir deshalb jetzt mit MIME und Hypertext im Internet und benutzen wir unsere Sprache wie gewohnt /6/.

8. Literatur und WWW-Hinweise

9. Liste der beigefügten Tabellen

10. Anhänge

Anhang 2: Häufige Fehlersituationen und mögliche Gegenmaßnahmen

Anhang 1: Einige Beobachtungen zur 8-Bit-Zeichenmenge

Erzeugt man eine zeichenorientierte Datei, deren 128 obere Zeichen genau die Bitwerte 128 bis 255 enthalten, lassen sich mehrere Experimente durchführen:

1.	Wie erscheinen diese Zeichen rechnerabhängig auf Bildschirm und Drucker?
2.	Wie erscheinen diese Zeichen nach einer e-Mail-Übertragung unter MIME auf einem anderen Rechner?
3.	Was passiert bei einer direkten Dateiübertragung von Rechner zu Rechner?

Wie leicht zu überlegen ist, wird die Beantwortung dieser Fragen rasch komplex und unübersichtlich, zumal technische Randbedingungen einzuhalten sind, z.B. 8-Bit-Übertragung, ftp oder fetch im Textmodus, textorientierte Druckausgabe usw. Im einzelnen ergeben sich die folgenden Antworten, wobei angenommen wird, daß die Rechner so eingestellt sind, daß Bildschirm- und Papierausgabe übereinstimmen:

1.1	Tabelle 5 zeigt die Ausgabe auf Sun Sparc mit Unix System V Rel. 4.0, gedruckt mit "enscript" auf Apple-Laser-Writer. Wie man durch Vergleich mit Tabelle 1 erkennt, wird ISO-Latin-1 ausgegeben. Benutzt man zum Drucken "lpr", entsteht ein Muster nach Tabelle 11, also Tabelle 4 um 3 Zeichen erweitert, im wesentlichen HP Roman 8.
1.2	Tabelle 6 zeigt den analogen Vorgang Druckausgabe der Datei für Apple unter MacOS. Auf den ersten Blick ist das eine völlig andere Darstellung, die aber mit Apple-Latin-1 aus Tabelle 2 übereinstimmt. Der gleiche Dateninhalt sieht je nach Rechner völlig anders aus, ist folglich für eine Übertragung ungeeignet, wenn andere Zielrechner verwendet werden, also keine firmenorientierte Darstellung möglich ist.
1.3	Tabelle 7 zeigt die gleichen Zeichenwerte, aber mit HP-Drucker von einem PC ausgegeben. Dies sollte mit Tabelle 3 übereinstimmen, zeigt aber einige Abweichungen in den nicht genormten Positionen 80, 81, 8D, 8E, 8F, 90, 9D und 9E. Ein anderer PC zeigt den gleichen Code mit den gleichen 8 undefinierten Zeichen unter MS-DOS.
2.1	Überträgt man diese Datei aber mit Elm (Version 2.4 PL 25) als e-Mail und liest die empfangene Nachricht auf Mac mit Eudora Light 1.5.1, ergibt sich Tabelle 8. Schaut man diese genauer an, wird deutlich, daß wesentliche Teile von Tabelle 1 oder 5 noch immer enthalten sind, aber nunmehr um 32 Zeichen der Zeilen 8 und 9 ergänzt. Das ist unerheblich, doch gibt es weiterhin 14 verstreute Abweichungen von ISO-Latin-1, nämlich die Positionen A6, B2, B3, B9, BC bis BE, D0, D7, DD, DE, F0, FD und FE. an diesen Stellen tauchen Apple-Zeichen auf, unter denen das Konzept der MIME-Kommunikation beeinflußt: der Begriff l'il-de-buf ist mit ISO-Latin-1 nicht über e-Mail zu übertragen, falls Sun vom Absender oder Empfänger benutzt wird. Hier wurde offenbar ISO-Latin-1 vernünftig, aber nicht normkonform ergänzt (Franzosen benötigen eine andere Variante von ISO 8859 für ihre Sprache, falls sie oe nicht als Ligatur, sondern als eigenen Buchstaben betrachten).
2.2	Überraschend ist die gegenüber Tabelle 6 andere Anordnung der Zeichen, die zwar ergänzt sind, aber noch weitgehend Tabelle 1 entsprechen. Warum sind sie wie in Tabelle 8 dargestellt, auch wenn dies mit Mac empfangen wird? Der Grund liegt in der Zeichenumsetzung beim Empfang: die Datei ist nun nicht mehr dieselbe, sondern auf Mac werden die Zeichen der Nachricht in Apple-Latin-1 dargestellt, also enthält die Position C4 nunmehr 80, würde man die Zeichen wie empfangen in einer Mac-Datei ablegen. In der Gegenrichtung wird Appletext nach ISO-Latin-1 transformiert, soweit Eudora Nachrichten absendet, unabhängig von der Verwendung von quoted-printable, also auch im 8-Bit-Code. Dies ist umgekehrt auch beim Empfang geschehen.
2.3	Was geschieht beim umgekehrten Senden, also der Rücksendung von Tabelle 8 von Mac nach Sun? Es ergibt sich Tabelle 9, d.h. die zusätzlichen Zeichen erscheinen zwar auf dem Bildschirm, nicht aber auf dem Drucker (und stimmen weitgehend mit Tabelle 5 überein). Das Kommando "enscript" unterdrückt folglich alle Nicht-ISO-Zeichen und druckt ISO-Zuordnungen. Allerdings erscheinen die Zeichen 80, 8B und 8C zusätzlich, dafür fehlt FF.
2.4	Auch im PC läßt sich Tabelle 8 darstellen, wenn man die Datei mit e-Mail überträgt, allerdings erscheint das erste Zeichen als * statt . Dies ist als Tabelle 10 angegeben, allerdings nach Rückempfang auf Mac mit HP-DeskWriter gedruckt.
3.	Eine benutzertransparente Umsetzung der Zeichenbitwerte ist offensichtlich auch dann nötig, wenn gar keine e-Mail-Übertragung zwischengeschaltet ist, also ein direkter Transfer einer Textdatei z.B. von Sun auf Mac durchgeführt wird. Ebenso geschieht diese Umsetzung von Text automatisch bei telnet, ftp oder fetch, da es auf die Zeichenbedeutung, nicht auf die Rechnerdarstellung der Zeichen beim Transfer ankommt. Folglich funktioniert die bequeme Funktion "Ausschneiden/Einsetzen" über eine Zwischenablage nicht nur zwischen unterschiedlichen Textprogrammen auf dem gleichen Rechner mit Fenstersystem korrekt, sondern auch bei telnet-Zugriff auf einen anderen Rechner. Dies allerdings mit einer Einschränkung: nicht kompatible Zeichen werden unsichtbar oder anders dargestellt. Natürlich ist dazu die Auswahl des Textmodus notwendig bzw. ISO im Fall von telnet. Die binäre Übertragung verzichtet auf die Umsetzung, erzeugt aber Zeichen, die durch weitere Software (Textsystem, Editor usw.) sichtbar gemacht werden müssen.

Abschließend sei darauf hingewiesen, daß diese Angaben auf bestimmten Rechnereinstellungen beruhen (z.B. Schriften, Druckertreiber usw.) und nicht notwendigerweise auf anderen Systemen in gleicher Weise reproduzierbar sind. Allerdings sind sie als erster Anhaltspunkt zum Verständnis der Textübertragung von Rechner zu Rechner durchaus geeignet und sollten eine Hilfe bilden, wenn die Umlaute nicht korrekt auf dem Bildschirm erscheinen. Tabelle 11 ist z.B. die Ausgabe von Tabelle 10 auf Sun mit dem Kommando "lpr" anstelle von "enscript". Man sieht, daß sie mit Tabelle 4 übereinstimmt. Genau genommen löst "enscript" lediglich eine Codeumsetzung vor der Benutzung von "lpr" aus, was sich durch Erzeugen der entsprechenden Postscriptdatei sogar sichtbar machen läßt. Offen bleibt dabei, was der Rechner intern wirklich verwendet, denn es könnte durchaus sein, daß schon die Ausgabe auf den Bildschirm eine ISO-Umsetzung des Textes bewirkt, lpr also die internen Zeichen ausgibt.

Anhang 2: Häufige Fehlersituationen und mögliche Gegenmaßnahmen

1.	Statt Umlauten erscheinen Erweiterungscodes des Typs =xy. Die Empfangssoftware ist entweder nicht MIME-konform oder die Nachricht hat falsche Kopfzeilen, so daß sie nicht der Norm entspricht. Dies ist der Normalfall, wenn eine MIME-Nachricht durch veraltete Programme weitergeleitet oder zitiert (automatisch als Kopie eingefügt) beantwortet wird. Nur eine korrekte Ergänzung der Kopfzeilen und erneutes Lesen der Nachricht erlaubt eine Rücksubstitution der erweiterten Zeichen.
2.	Statt der Umlaute erscheinen falsche Zeichen außerhalb der ASCII-Menge. Auch hier sind die Kopfzeilen falsch, z.B. bezüglich des Zeichensatzes, so daß die Angabe charset = ISO-8859-1 fehlt, oder es ist keine gültige MIME-Nachricht. Dies ist der Normalfall bei einer 8-Bit-Übertragung zwischen verschiedenen Rechnertypen, die auf MIME verzichtet. Andere Zeichensätze sind derzeit nur bei einer Beschränkung auf die ASCII-Menge verwendbar, nur ISO-Latin-1 ist in MIME "genormt". Eine Warnanzeige "shownonascii" weist darauf hin, daß der angezeigte Zeichensatz auf 8 Bits erweitert ist.
3.	Statt der Umlaute erscheinen falsche ASCII-Zeichen, z.B. d, v, | oder ähnliche Zeichen. Es liegt hierbei eine beabsichtigte 8-Bit-Übertragung des Senders vor, die Übertragung erlaubt aber nur 7 Bits. Infolgedessen werden alle 8-Bit-Zeichen ³ 80 (128) durch Nullsetzen des höchstwertigen Bits verfälscht. Als Gegenmittel ist der Übertragungsmodus quoted-printable in MIME erforderlich.
4.	Die Nachricht ist nicht MIME-konform, da z.B. die entsprechenden Kopfzeilen fehlen, trotzdem werden alle Umlaute korrekt dargestellt. Hier vermutet der Empfänger den eigenen Zeichensatz, also ist die Nachricht auch so erzeugt und funktioniert die 8-Bit-Übertragung. Das passiert insbesondere, wenn Sender und Empfänger den gleichen Rechnertyp verwenden.
5.	Die gleiche Nachricht wird mit verschiedener Software teils korrekt, teils verstümmelt empfangen. Hier ist entweder die Sende- oder die Empfangssoftware nicht MIME-konform, so daß nur Passendes eine korrekte Interpretation liefert. Natürlich sollte auch die Sendesoftware stets MIME-konform sein. Nur dann kann der Absender sicher sein, daß seine Nachricht auf einem beliebigen Rechner korrekt empfangen werden kann.
6.	Die Nachricht überträgt die deutschen Umlaute korrekt, nicht aber den Buchstaben oder , obwohl sie der Absender auf seinem Bildschirm erzeugen kann. Diese Situation ist kein Fehler, sondern eine Einschränkung der ISO-Norm 8859-1, die derzeit nicht rechnerunabhängig umgangen werden kann, sondern vom verwendeten Rechnertyp abhängt. Folglich sollten MIME-konforme Nachrichten auf die Verwendung dieser Zeichen verzichten.
7.	Einzelne Zeichen werden beim Empfang durch andere Platzhalter angedeutet oder fehlen ganz. In diesem Fall ist die gewählte Schriftart auf dem Empfangsrechner beschränkt, so daß Courier oder Times oder andere vollständige Schriften ausgewählt werden sollten. Allerdings wird hierbei u.U. die Beschränkung der Zeichenmenge von ISO-8859-1 verletzt (s. vorigen Absatz).
8.	In Postprogrammen wie Elm erscheinen die empfangenen Umlaute falsch, die eigenen Eingaben aber korrekt. Hier ist entweder die Nachricht nicht korrekt oder das eigene System hat falsche Codeseiten eingestellt, so daß versucht wird, falsche Nachrichten zu erzeugen. Gegenmittel ist im letzteren Fall nur die korrekte Systemeinstellung mit Hilfe der Sprach- oder Tastaturvariablen, auch wenn dadurch auf "lpr" zugunsten von "enscript" verzichtet werden muß. Ein derartiger Effekt ist auf HP 720 mit HP UX 9.3 und Elm (Revision 70.85) beobachtbar. Experimente wie in Anhang 1 zeigen, daß offenbar HP Roman 8 direkt mit "lp" zu korrekter Druckausgabe führt. Die Dokumentation zu Elm läßt keinen Hinweis auf MIME erkennen. Vermutlich ist das gesamte Unixsystem veraltet und erfordert eine Erneuerung, ehe e-Mail mit MIME gelesen oder versendet werden kann.
9.	Es ist zu erwarten, daß MIME-konforme Nachrichten auch ohne erneuerte e-Mailprogramme korrekt empfangen und einschließlich der Umlaute gelesen werden können, wenn der Rechner ISO-Latin-1 verwendet und der Absender die 8-Bit-Darstellung ausgewählt hat. Ein Senden gelingt in diesem Fall nur an Empfänger gleicher Art, ist also nicht rechnerunabhängig.
10.	Bei telnet-Zugriff von Mac auf Unix-Postrechner ist "Session/Translations" auf ISO einzustellen, sonst erscheinen Umlaute bereits auf dem Bildschirm des Absenders falsch (Apple-Mac als Terminal für Unix-Rechner).
11.	Web-Seiten in HTML verwenden eine andere Umlautdarstellung mit 7-Bit-Zeichen, die beim Textaufbereiten automatisch vorgenommen wird, wenn der Editor korrekt auf HTML eingestellt ist (z.B. BBEdit). HTML-Texte lassen sich als E-Mail umlautkorrekt übertragen, alleredings werden die Umlaute nur vom Browser wie Netscape korrewkt dargestellt, nicht von Postprogrammen wie Elm oder Eudora.

Tabelle 1: Latin-1 nach ISO-8859-1

Tabelle 2: Latin-1 nach Apple (Power-Mac)

Tabelle 3: Latin-1 nach Windows (PC)

Tabelle 4: HP Roman 8

Tabelle 5: Ausgabe einer Zeichendatei auf Sun (A0 Leerzeichen im Wort)

Tabelle 6: Ausgabe einer Zeichendatei auf Mac (CA Leerzeichen im Wort)

Tabelle 7: Ausgabe einer Zeichendatei auf PC (A0 Leerzeichen im Wort)

Tabelle 8: Übertragung der Tab. 5 von Sun zu Mac (A0 Leerzeichen im Wort)

Tabelle 9: Rückübertragung der Tab. 8 von Mac zu Sun (Druck mit enscript) (A0 Leerzeichen im Wort)

Tabelle 10: Übertragung der Tab. 8 (80 bis FF) von Sun über PC zu Mac

Tabelle 11: Übertragung der Tab. 8 von Mac zu Sun (Druck mit lpr) (A0 Leerzeichen im Wort)