Zum Artikel
< >

Aktives GUI-Element

Statisches GUI-Element

Quelltext

WPS-Objekt

Datei/Pfad

Befehlszeile

Inhalt Eingabefeld

[Tastenkombination]

mehr

OS/2 und mehrsprachige Zeichensätze
Teil 3

von Alex Taylor, © Juli 2008

Dieser Artikel ist der dritte aus meiner Serie, in der ich einige Probleme mit OS/2 und der Behandlung von internationalen Texten bearbeite. Diese Ausgabe befaßt sich mit den Texten aus dem Internet und zeigt, wie bestimmte Anwendungen damit umgehen.

Also, Sie sehen sich eine e-Mail-Nachricht oder Webseite an, die lustige Zeichen enthält, von denen Sie wissen, daß sie nicht richtig sind, und sie würden nun diese gerne so sehen, wie der Autor sie eingegeben hat. Oder vielleicht beschweren sich Ihre e-Mail-Gegenüber, daß Ihre Nachrichten jede Menge unlesbarer Zeichen beinhalten. Oder vielleicht fragen Sie sich einfach nur, was ein ‘Zeichensatz’ ist und wie der funktioniert.

Dieser Artikel behandelt diese und andere Fragen.

Zeichensätze

Die meisten Internetdokumente, wie e-Mail-Nachrichten, Newsgruppenmeldungen und Webseiten, verwenden etwas, daß sich Zeichensatz-Kennung nennt. Das ist letztlich ein Parameter, der Ihrem Mailclienten, Newsreader oder Webbrowser mitteilt, welche Zeichenkodierung (oder welchen Zeichensatz) die Datei verwendet.

In einem HTML-Dokument ist die Zeichensatzkennung irgendwo in der Nähe des Dateianfangs (in dem <head> Abschnitt), üblicherweise als Bestandteil einer Zeile wie diese:

    <meta http-equiv="Content-Type" content="text/html; "charset=iso-8859-1">

In einer e-Mail-Nachricht oder einer Newsgruppemmeldung ist die Zeichensatzkennung Bestandteil des Nachrichtenkopfs; ein typisches Beispiel sieht etwas so aus:

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

In beiden Fällen ist die Zeichensatzkennung Bestandteil des Content-Type-Kopfes, der — wie man sehen kann — weitere wichtige Informationen zur Eigenschaft der Datei enthält.

Es ist wichtig sich einzuprägen, daß Internetnachrichten und Webseiten mit Zeichensätzen arbeiten und nicht mit Zeichenumsetztabellen. Obwohl sich beide Begriffe recht ähnlich sind, ist ein Zeichensatz eine standardisierte Zeichenkodierung, wogegen eine Zeichenumsetztabelle eine spezifische Umsetzung eines solche Zeichensatzes ist. Also, während OS/2 den Zeichensatz ISO-8859-1 mit der Zeichenumsetztabelle 819 implementiert, können andere Betriebssysteme oder andere Softwareumgebungen andere Mechanismen verwenden. (Tatsächlich, wie ich im ersten Teil erwähnte, implementiert Windows 95 diesen als Untermenge der wesentlich erweiterten Zeichenumsetztabelle 1252; die Windows NT-Familie verwendet Unicode für alle Textumsetzungen, weshalb viele verschiedene Zeichensätze nebeneinander unterstützt werden können).

Jedoch — zumindest unter OS/2 — nutzt Ihre Software tatsächlich die Zeichensatzkennung um herauszufinden, welcher Zeichensatz zur Anzeige der Datei verwendet werden soll.

Kodierungsübersetzungen

Ich habe in meinen beiden letzten Artikeln die Zeichenumsetztabellen recht ausführlich beschrieben — insbesondere wie man anders kodierte Dokumente durch Umschalten auf eine geeignete Zeichenumsetztabelle anzeigen lassen kann. Aber, wie ich auch erwähnte, sind mit dem hin- und herspringen zwischen den Zeichenumsetztabellen auch einige Probleme verbunden.

Was ich jedoch bislang noch nicht angesprochen hatte, ist die andere wichtige Verwendung von Zeichenumsetztabellen: als Übersetzungstabellen, um tatsächlich eine Textkodierung in eine andere umzuwandeln.

Mit Umwandeln meine ich die Änderung des Datenstroms selber: Übersetzen eines Zeichens aus einer Zeichenumsetztabelle in das entsprechende Zeichen in einer anderen Tabelle.

Als Beispiel nehmen wir die Zeichenfolge, die ich schon im ersten Teil verwendet habe:
We stopped for lunch at a caf in Reykjavk.

Nehmen wir mal an, wir hätten diesen Text (vielleicht in einer e-Mail) kodiert mit Zeichenumsetztabelle 1252 erhalten, aber unser System ist auf Zeichenumsetztabelle 850 eingerichtet. Ohne jeden Eingriff würde die Zeichenfolge auf unserem Bildschirm in etwa so angezeigt:

We stopped for lunch at a caf in Reykjavk.

Anstatt nun eine richtige Darstellung durch Umschalten der Zeichenumsetztabelle auf 1252 oder 1004 zu erhalten (wie wir es im ersten Teil gemacht haben), haben wir Techniken zur Verfügung, die es uns gestatten, diesen Text tatsächlich umzuwandeln, so daß er für die Zeichenumsetztabelle 850 richtig geschlüsselt ist.

Wenn der originale Text für die Zeichenumsetztabelle 1252 geschlüsselt wurde, sehen die nackten Byte-Werte so aus:

57 65 20 73 74 6F 70 70 65 64 20 66 6F 72 20 6C 75 6E 63 68 20 61
74 20 61 20 63 61 66 E9 20 69 6E 20 52 65 79 6B 6A 61 76 ED 6B 2E

Die Umwandlung des Textes auf Zeichenumsetztabelle 850 resultiert in den folgenden geänderten Byte-Werten:

57 65 20 73 74 6F 70 70 65 64 20 66 6F 72 20 6C 75 6E 63 68 20 61
74 20 61 20 63 61 66 82 20 69 6E 20 52 65 79 6B 6A 61 76 A1 6B 2E

Die hervorgehobenen Byte-Werte sind die, die geändert werden müssen (sie stehen für die nicht Standard-ASCII-Zeichen é und í).

Lassen wir uns die Zeichenfolge nun anzeigen, wird sie richtig angezeigt, obwohl wir — und das ist der ausschlaggebende Punkt — immer noch Zeichenumsetztabelle 850 zur Anzeige verwenden.

Was wir gemacht haben, ist hier den Text so zu ändern, daß er der Zeichenumsetztabelle entspricht; eigentlich ist das ziemlich genau das Gegenteil dessen, was wir in den beiden ersten Artikeln gemacht haben, wo wir die Zeichenumsetztabelle so geändert haben, daß sie dem Text entspricht. Wenn man allerdings diesen Weg einschlägt, erhält man folgende Vor- und Nachteile:

Vorteile

Nachteile

Wie aber führen wir eine solche Umsetzung aus? Nun, das ist etwas, was normalerweise auf Anwendungsebene passiert: mit anderen Worten, Ihr Webbrowser, e-Mailclient oder Newsreader wird das mutmaßlich für Sie zu tun. Soweit die Theorie, wie auch immer; natürlich, einige Anwendungen sind mehr (oder weniger) intelligenter als andere.

Zeichensatzunterstützung in Anwendungen

Dieser Abschnitt befaßt sich damit, wie einige wenige Programme der Unterstützung von verschiedenen Zeichensätzen gerecht werden.

Mozilla

Die verschiedenen Mozilla-Produkte haben unbestritten die beste Zeichensatzunterstützung aller Internet-Applikationen, die für OS/2-Anwender verfügbar sind. Mozilla behandelt, und rendert, anscheinend alle Texte als Unicode. Da Unicode, theoretisch, alle Zeichensätze unterstützt, sollten Zeichen durch Konvertierung nicht verlorengehen. Und aufgrund der deutlichen Entwicklungsanstrengungen, die Mozilla erhalten hat, ist sichergestellt, daß seine verschiedenen Produkte eine weite Auswahl von verschiedenen Zeichenkodierungen unterstützt, wie Sie es möglicherweise gehofft haben.

Mit Mozilla ist die Unterstützung der verschiedenen Zeichensätze ziemlich lückenlos. Hin und wieder mögen Sie eine Webseite finden, die ihren Zeichensatz nicht richtig mitteilt, weshalb Sie in solchen Fällen Mozilla mitteilen müssen, welche Zeichenkodierung anzuwenden ist (über Ansicht > Zeichenkodierung-Menü, wie letztes Mal beschrieben), aber das kommt ziemlich selten vor.

Unter Mozilla ist die Zeichensatzunterstützung im Grunde nur durch die von Ihnen eingesetzten Schriftarten begrenzt. Unicodefähige Schriftarten sind generell zu empfehlen (besonders für die “Weitere Sprachen”-Kategorie). Die Konfiguration der Schriftarten in Mozilla wurde im zweiten Teil dieser Serie beschrieben.

Es gibt da einen möglichen Stolperstein in Mozilla, an den Sie denken müssen. Damit Sie in den Genuß der vollständigen Zeichenunterstützung gelangen, müssen alle nachfolgend genannten Voraussetzungen erfüllt sein:

Es ist leicht möglich, daß eine oder mehrere dieser Voraussetzung(en) nicht erfüllt werden; eine unvollständige Konfiguration offenbart sich dadurch, daß Fremdsprachenzeichen (insbesondere ostasiatische) als Rechtecke gerendert werden.

Pronews/2

Die neuesten Versionen von Pronews/2 können eine beachtliche Anzahl an verschiedenen Zeichensätzen handhaben. Leider wird es etwas unübersichtlich, wenn man verstehen will, wie die einzelnen Stücke zusammenpassen.

Im Gegensatz zu Mozilla ändert Pronews/2 die Anzeigezeichenumsetztabelle nicht, wenn Texte wiedergegeben wird; statt dessen (in Ermangelung an Hilfskonstruktionen wie CPPal) muß der Text in eine einzelne, vorgegebene Zeichenumsetztabelle umgewandelt werden - üblicherweise die Zeichenumsetztabelle, in der Pronews selber gerade läuft. (Dies liegt zum Teil daran, daß Pronews sehr viel mehr auf nativen PM controls aufbaut, die wiederum an einigen Beschränkungen in Sachen Zeichenumsetztabellenunterstützung leiden.)

Was Pronews macht, ist konzeptionell einfach und geradeaus: Er überprüft für jeden Artikel, den Sie gerade lesen, den Zeichensatz und wandelt dann den Artikeltext in die aktuelle Zeichenumsetztabelle. Im umgekehrten Falle, beim Nachrichtenschreiben, interpretiert er den Artikeltext gemäß der gültigen Zeichenumsetztabelle und wandelt diesen dann in den Zeichensatz, den Sie aktiviert haben.

Pronews Zeichensatzkonfiguration
Bild 1: Konfiguration der Zeichensatzunterstützung in Pronews/2

Das Verhalten wird dadurch bestimmt, wie Sie bestimmte Konfigurationsoptionen gesetzt haben. Diese Optionen finden Sie auf Seite 8 der Gruppeneinstellungen (siehe Bild 1), und diese können entweder allgemein oder auf einer Per-Newsgruppen-Basis eingestellt werden.

Verschlüsselungsmethode
Diese Einstellung betrifft den Zeichensatz eigentlich nicht; es gibt nur an, ob 8-Bit-Zeichen wortgetreu gesendet oder ob sie einfach verschlüsselt werden, um sie sicher an 7-Bit Relais zu übergeben (diese sind heutzutage sehr selten geworden). Im allgemeinen kann man diese Einstellung auf dem Standard belassen.
Anzeigestandard
Diese Einstellung legt fest, wie einkommende Nachrichten behandelt werden, die ihren Zeichensatz nicht angeben. Für solche Nachrichten wird derjenige Zeichensatz angenommen, den Sie hier angeben; entweder “US-ASCII” oder “Windows-1252” sind gewöhnlich eine gute Wahl.
Zeichenumsetztabelle
Diese Einstellung teilt Pronews mit, in welche Zeichenumsetztabelle der Text zur Anzeige gewandelt werden soll (so daß Sie ihn richtig lesen können). Im Regelfall sollten Sie dies auf “Current” belassen, was bedeutet, daß jeder Text in die Anzeigezeichenumsetztabelle gewandelt wird (oder aus ihr heraus beim Senden).

Wenn sie eine andere Zeichenumsetztabelle wählen, kann es sein, daß Sie den Text nicht mehr richtig lesen können; jedoch kann dies sinnvoll sein, wenn Sie den Text von oder in einer anderen Software kopieren oder einfügen, wenn diese eine andere Zeichenumsetztabelle zur Anzeige verwendet.

Senden
Diese Einstellung teilt Pronews mit, welchem Zeichensatz Sie alle Ihre Nachrichten versenden wollen. Im allgemeinen sollten Sie einen Zeichensatz wählen, der alle Zeichen unterstützt, die sie jemals in Ihren Nachrichten zu verwenden gedenken. ISO-8859-1 oder ISO-8859-15 sind eine gute Wahl, wenn Sie ausschließlich Nachrichten in Latein basierten Sprachen versenden wollen; UTF-8 wäre zu bevorzugen, wenn Sie eine größere Auswahl an Sprachen annehmen können.

Wichtig ist dabei nicht zu vergessen, daß Sie Texte nur lesen — oder schreiben — können, soweit diese von der eingestellten Zeichenumsetztabelle unterstützt werden. Jedes nicht unterstützte Zeichen wird dabei in ein allgemeines Ersatzsymbol umgewandelt. Zudem gilt, wenn die eingestellte Zeichenumsetztabelle nicht mit der aktuellen Anzeigezeichenumsetztabelle übereinstimmt (oder zumindest damit kompatibel ist), werden nicht ASCII-Zeichen kaum in lesbarer Form auf Ihrem Bildschirm erscheinen, obwohl Sie bei Ihrem Korrespondenz-Gegenüber richtig angezeigt werden sollten.

Die neueste Ausgabe von Pronews erlaubt Ihnen sogar die Liste der verfügbaren Zeichensätze und Zeichenumsetztabellen zu modifizieren, indem Sie einige ASCII-Konfigurationsdateien im Programmverzeichnis bearbeiten.

  • Ihre aktuelle Zeichenumsetztabelle (mit der Pronews läuft) muß in der Datei CODEPAGE.PN gelistet sein — die meisten gebräuchlichen Zeichenumsetztabellen sind bereits verzeichnet. (Diese Datei legt auch fest, welche Zeichenumsetztabellen unter Zeichenumsetztabelle in den Pronews-Einstellungen, siehe oben, angezeigt werden.)
  • Damit ein Zeichensatz unterstützt wird, muß er direkt mit einer OS/2-Zeichenumsetztabelle übereinstimmen. Der Zeichensatzname muß in der Datei CHARSET.PN verzeichnet sein und die Zeichensatz-zu-Zeichenumsetztabelle-Zuordnung muß in der Datei CPALIAS.PN angelegt sein.

Weitere Informationen entnehmen Sie der README.TXT-Datei von Pronews.

PMMail/2

Die Version 2.x von PMMail/2 hat nur eine ziemlich rudimentäre Zeichensatzunterstützung. Es weiß, wie es ein paar wenige übliche Ein-Byte-Zeichenumsetztabellen (unter anderem 437, 850, 862 und 864) erkennt und etwa ein Dutzend übliche Zeichensätze (US-ASCII, KOI8-R und ISO-8859-1 bis -10). Es verwendet die aktuelle aktive Zeichenumsetztabelle um Text in den gewählten Zeichensatz zu übersetzen, wenn Nachrichten versendet werden, und es übersetzt vom erkannten Zeichensatz in die aktuelle Zeichenumsetztabelle, wenn Nachrichten betrachtet werden.

Das funktioniert auch recht gut, wenn Ein-Byte-Zeichenumsetztabellen in eine Ein-Byte kodierte Nachricht umgewandelt werden (und umgekehrt). Es unterstützt jedoch keine modernen Zeichensätze (wie etwa Windows-1252 oder ISO-8859-15) und ist nicht geeignet für Multi-Byte-Kodierungen (wie etwa UTF-8, EUC oder Shift-JIS).

Zum Glück wird demnächst eine neue Version von PMMail/2 (nun von VOICE gewartet) erscheinen, und dessen Zeichensatzunterstützung wurde wesentlich verbessert und erweitert.

Egal welche PMMail-Version, die grundlegende Logik ist nahezu gleich. Das globale Einstellungsnotizbuch hat eine Seite, die mit Locale betitelt ist (siehe Bild 2), auf welcher man den standardmäßigen Zeichensatz zum Versenden von Nachrichten angibt.

PMMail Locale Konfiguration
Bild 2: Konfiguration der Zeichensatzunterstützung in PMMail/2
(Bild von Version 2.20)
Standard-Zeichensatz
Wie gesagt, PMMail verwendet diese Auswahl, um den Zeichensatz der abgehenden Nachrichten festzulegen.

(In PMMail Version 3 wird dies auch zur Standardanzeige von eingehenden Nachrichten verwendet, wenn diese ihren Zeichensatz nicht ordnungsgemäß mitteilen; Version 2.x schaltet einfach auf US-ASCII, wenn ein Zeichensatz unbekannt ist.)

Verschlüsselungsformat
Das ist gleichwertig zur Pronews “Verschlüsselungsmethode”-Einstellung. Es gibt an, ob nicht ASCII-Zeichen für die 7-Bit-Relais verschlüsselt werden sollen oder nicht.

Die Auswahl "Quoted Printable" ist meistens die beste Option.

KEINE Zeichensatzübersetzung durchführen
Diese Einstellung schaltet die Übersetzung zwischen den Zeichenumsetztabellen und Zeichensätzen ab, was bedeutet, daß PMMail annimmt, daß der zu versendende oder anzuzeigende Text bereits richtig kodiert ist.

Diese Option kann recht nützlich sein, wenn Sie Text in eine abgehende Nachricht einfügen wollen, der bereits in dem gewählten Zeichensatz vorliegt (aber nicht in der eingestellten Zeichenumsetztabelle).

Nichtunterstützter Japanischer Text in PMMail/2
Bild 3: Nicht unterstützter japanischer Text (Zeichensatz ISO-2022-JP) in PMMail/2

Wie schon Pronews ist auch PMMail darauf beschränkt, nur Texte in denjenigen Zeichenumsetztabellen anzuzeigen, in denen es selber läuft. Auch hier liegt es daran, daß PMMail native PM controls verwendet, die im Umgang mit mehreren Zeichenumsetztabellen sehr eingeschränkt sind. Unter bestimmten Umständen kann man jedoch das CPPal-Werkzeug einsetzen (wie im ersten Teil dieser Serie beschrieben) um die Zeichenumsetztabelle für PMMail zu ändern, bevor es die anzuzeigende Nachricht öffnet, damit man Nachrichten in einer nicht aktiven Zeichenumsetztabelle lesen kann.

Bild 3 zeigt ein typisches Beispiel eines japanisch kodierten Textes (unter Verwendung des üblichen Zeichensatzes ISO-2022-JP), so wie er in PMMail 2.20 erscheint - das diese Kodierung nicht unterstützt. (Ich habe ein paar Sachen ausradiert, zum Schutz der Privatsphäre.) Wie man erkennen kann, wird es als unverständliches Kauderwelsch abgebildet. In diesem bestimmten Fall würde auch ein Umschalten der Zeichenumsetztabelle mit CPPal oder etwas Vergleichbarem nicht helfen, da keine Zeichenumsetztabelle vorhanden ist, die den Zeichensatz ISO-2022-JP implementiert (das ist eine modale Kodierung basierend auf Escape-Sequenzen, die gezielt durch die jeweilige Applikation unterstützt werden muß. Anmerkung des Übersetzers: Nach Rücksprache mit dem Autor hier ein kurzer Klärungsversuch zum Begriff der modalen Kodierung: Modale Kodierung bedeutet, daß in ISO-2022-JP einige Kodierungen wie in einem lateinischen Zeichensatz belegt sind, andere jedoch nicht. Dies wird durch entsprechende Escape-Sequenzen gesteuert. Es wird also in dem Zeichensatz ein lateinischer und ein japanischer Modus unterstützt, ggf. auch noch weitere Modi. Dieses ist eine eher ungewöhnliche Implementierung eines Zeichensatzes, da hier eine feste Zuordnung zwischen Kode und Zeichen, wie für Zeichenumsetztabellen üblich, nicht funktioniert. Die jeweilige Applikation muß in Abhängigkeit des Modus zwischen verschiedenen Darstellungen eines Zeichens "intelligent" unterscheiden).

In PMMail 3.x wird die Unterstützung für ISO-2022-JP (neben anderen Zeichensätzen) mitgeliefert, so daß die Kodierung solcher Nachrichten nun unterstützt werden sollte. Jedoch wird PMMail nur dann japanische Zeichen anzeigen können, wenn die aktuelle Zeichenumsetztabelle dies unterstützt. Bild 4 zeigt, wie die Nachricht im neuen PMMail erscheint, wenn man eine nicht japanische Zeichenumsetztabelle, wie etwa 850, verwendet.

Nicht-Darstellbarer Japanischer Text in PMMail 3.x
Bild 4: Unterstützter aber nicht darstellbarer japanischer Text in PMMail 3.

Zu bemerken ist, daß alle nicht unterstützten Zeichen in der Nachrichtenanzeige durch das “Haus”-Symbol (⌂) ersetzt wurden. Dies ist das standardmäßige Ersatzzeichen in der Zeichenumsetztabelle 850, die ich verwendete, als ich das Bildschirmfoto gemacht habe.

Das Ersatzzeichen welches in der Zeichenumsetztabellenkonvertierung verwendet wird, und oben beschrieben ist, darf nicht mit dem Ersatz-Glyphen den speziele Schriftarten mitbringen, wie im ersten Teil dieser Serie beschrieben, verwechselt werden.

Das Zeichenumsetztabellen-Ersatzzeichen ist, wie der Name schon sagt, eine Funktion der Zeichenumsetztabelle. Der Zweck ist, ein Zeichen, das einen bekannten Wert hat, aber von der aktuellen Zeichenumsetztabelle nicht unterstützt wird, darzustellen. Das Haus-Symbol (⌂) wird weithin dafür eingesetzt, obwohl es auch das Kästchen (☐), ein Fragezeichen (?) oder auch das Unicode-Ersatzzeichen (�) sein kann (Dies ändert sich mit der Zeichenumsetztabelle und kann auch durch die Applikation überschrieben werden).

Der Schriftarten-Ersatzglyph auf der anderen Seite ist spezifisch für die jeweilige Schriftart und kann nicht übersteuert werden. Er wird dann eingesetzt, wenn Zeichen dargestellt werden müssen, die durch die Schriftart aus verschiedenen Gründen nicht darstellbar sind. (Dies kann daran liegen, daß die Schriftart keinen Glyphen für dieses Zeichen enthält oder weil das Zeichen an sich nicht darstellbar ist, oder weil der Zeichenwert selbst irgendwie ungültig ist.) ☐ und � werden beide recht häufig eingesetzt, wie auch andere unsinnige Schnörkeleien.

Darstellbarer Japanischer Text
Bild 5: Unterstützter und darstellbarer japanischer Text in PMMail 3.

Will ich die Zeichen so sehen, wie der Absender es gewollt hat, muß ich die aktuelle Zeichenumsetztabelle auf ein solche abändern, die das unterstützt. Da ich weiß, daß der Text in Japanisch geschrieben wurde (was sich leicht herausfinden läßt, wenn man im Nachrichtenkopf nachschaut, welcher Zeichensatz angegeben ist), beende ich PMMail zunächst und lasse es dann mit der Zeichenumsetztabelle 932 laufen, weil dies die OS/2-japanische Zeichenumsetztabelle ist. (Hätte ich auf eine andere Ein-Byte-Zeichenumsetztabelle wechseln wollen, hätte ich einfach CPPal einsetzen könne, ohne PMMail beenden zu müssen; aber, wie ich letztes Mal erwähnte, das Umschalten von einer Ein-Byte-Zeichenumsetztabelle zu einer Doppel-Byte-Zeichenumsetzabelle funktioniert über diesen Weg nicht sonderlich gut.)

Nun, wenn ich die Nachricht unter der Zeichenumsetztabelle 932 öffne und sichergestellt ist, daß eine japanisch fähige Schriftart verfügbar ist, sehe ich die Nachricht so, wie in Bild 5 gezeigt.

Bedenken Sie, daß das gleiche Problem besteht (nur umgekehrt), wenn Sie eine Nachricht schreiben wollen: Sie können nur solche Zeichen eingeben, die auch von der aktuellen Zeichenumsetztabelle unterstützt werden. Wenn dann auf “Senden” klicken, wird der Nachrichtentext in den Zeichensatz umgewandelt, den Sie dafür vorgesehen haben. Selbstverständlich sollten sie daher einen Zeichensatz auswählen, der die Zeichen unterstützt, die Sie gerade eingegeben haben (das Thema behandle ich gleich).

Dies fördert einen ziemlich fiesen Fallstrick zutage, nämlich, wenn man auf eine Nachricht antwortet oder diese weiterleitet, zitiert man den Text mit den enthaltenen, durch die Zeichenumsetztabelle nicht unterstützten Zeichen, und diese Zeichen werden in die Ersatzzeichen umgewandelt und sind verloren. Zum Beispiel, wenn ich (aus welchem Grund auch immer) meine Zeichenumsetztabelle auf 850 zurücksetze und dann auf die Nachrichten aus den Bildern 3 bis 5 antworte, wird jeder japanische Text, den ich zitiert habe, im Nachrichteneditor umgewandelt und durch die Ersatzzeichen ausgetauscht. Und im Unterschied zur empfangenen Nachricht (wo dies nur die Nachrichtenanzeige betrifft) bleiben Ersetzungen in abgehende Nachrichten permanent.

Die einfache Merkregel dazu lautet: Kann man zitierte Zeichen richtig lesen, bleiben sie erhalten wenn man antwortet oder weiterleitet (unter der Voraussetzung, daß der Zeichensatz diese unterstützt). Kann man die Zeichen im Nachrichteneditor nicht richtig lesen — also dann, wenn sie als Ersatzzeichen erscheinen — gehen sie verloren.

In aller Kürze: Stellen Sie sicher, daß Sie auf eine Nachricht mit der Zeichenumsetztabelle antworten, in der Sie den originalen Text richtig lesen können.

Wie schon gesagt, die neue PMMail-Version sollte bald veröffentlicht werden (mag sein, daß sie zu dem Zeitpunkt, an dem Sie den Artikel lesen, schon herausgegeben wurde). PMMail Version 3 unterstützt ein große Vielfalt an Zeichensätzen, einschließlich derer, die schon vorher unterstützt wurden:

Auswahl eines Zeichensatzes

Alle oben beschriebenen Programme ermöglichen Ihnen einen Zeichensatz für alle abgehenden Nachrichten auszuwählen. Alle bieten zu diesem Zweck eine globale Einstellung an. In Mozilla und PMMail 3 kann man sogar den Zeichensatz individuell für jede einzelne Nachricht auswählen. Alle unterstützen eine große Auswahl an Zeichensätzen, womit sich die Frage stellt: Welchen Zeichensatz soll man verwenden?

Diese Frage kann man am besten beantworten, wenn man folgende 2 Faktoren bedenkt:

  1. Welche Art(en) von Zeichen müssen Sie in Ihren Nachrichten darstellen können? Zum Beispiel, wenn Sie Nachrichten in Russisch versenden müssen, müssen Sie einen Zeichensatz auswählen, der russischen Text unterstützt.
  2. Welche Zeichensätze können Ihre Korrespondenten (Briefpartner, oder besser, deren e-Mail-Software) verarbeiten? Natürlich hängt das von deren eigener Computereinrichtung ab. Die meisten der modernen e-Mail-Software können fast jeden Zeichensatz verarbeiten, den Sie benennen können, aber setzen sie eine Software ein, die schon ein paar Jahre alt ist, kann es zu Kompatibilitätsproblemen kommen. Sie müssen dann eine fundierte Einschätzung aufgrund Ihrer Kenntnis der in Frage kommenden Personen machen — oder es eben mit diesen diskutieren, wenn Sie Probleme vorhersagen können.

Nimmt man nur Punkt 1, dann ist logischerweise UTF-8 (Unicode) die erste Wahl, da sie nahezu alle denkbaren Zeichen aus nahezu allen Sprachen dieser Welt unterstützt. Allerdings kann nicht jede e-Mail-Software tatsächlich UTF-8 garantiert unterstützen, PMMail 2.x (und älter) ist ein gängiges Beispiel.

In der Konsequenz bedeutet dies, wenn man annimmt, daß die Korrespondenten ein Problem damit haben, daß dann ein älterer, weitgehend unterstützter Zeichensatz die womöglich bessere Wahl ist. Der prinzipielle Nachteil ist dann, daß die älteren Zeichensätze nicht so viele verschiedene Sprachen abdecken.

Einer der ältesten und am häufigsten benutzte Zeichensatz ist der ehrwürdige ISO-8859-1 (im ersten Teil dieser Serie beschrieben), der die meisten westeuropäischen Sprachen abdeckt und durch nahezu jedes existierende, bekannte e-Mail-Programm unterstützt wird. Für Nachrichten in Englisch, Deutsch, Französisch, Flämisch, Spanisch, Italienisch und anderen Sprachen sollte dies ein gute, vernünftige Wahl sein.

Aktualisierungen und Berichtigungen

Bevor ich nun zusamenfasse, möchte ich die Gelegenheit ergreifen und Aktualisierungen zu einigen Punkten aus den vorherigen Teilen vornehmen:

Schlußbemerkungen

Bis hierher habe ich so ziemlich alle Grundlagen beschrieben, die man zum Einsatz der Zeichenumsetztabellen im Umgang mit unterschiedlich kodierten Texten unter OS/2 braucht. Wie man erkennen kann, ist das nicht immer ein so elegantes Verfahren wie man es sich wünscht, aber man kann damit nahezu alles machen, was erforderlich ist.

Wie ich schon im ersten Teil erwähnte, hat das gesamte Zeichenumsetztabellensystem eine große Schwäche, nämlich daß man nur jeweils einen (oder letztlich nur einen nicht englischen) Zeichensatz einsetzen kann. Schon vor einigen Jahren hat die Computerindustrie das Problem erkannt und kam mit einer intelligenten Lösung: dem Unicode-Standard.

Wie Sie mittlerweile festgestellt haben, hat eine sachgerechte Diskussion über Unicode in diesen Artikeln soweit nicht wirklich stattgefunden. Der Grund liegt darin, daß die Unicode-Unterstützung in OS/2, obwohl vorhanden, ziemlich obskur ist und von den jeweiligen Anwendungen abhängt. Infolgedessen ist dieses eher eine Angelegenheit für Programmierer als für den Anwender.

Nichtsdestotrotz gibt es da einige Aspekte aus Unicode zu wissen, die für jedermann brauchbar sind. Ich werde mich daran versuchen und in der Zukunft noch einen weiteren Artikel schreiben, um einige davon zu aufzugreifen.

Übersetzung: Jürgen Gaida
Korrektur: Karl-Heinz Markus
Daten und Quellen

Mozilla für OS/2: http://www.mozilla.org/ports/os2
PMMail/2: http://pmmail.os2voice.org
ProNews/2: http://hobbes.nmsu.edu/cgi-bin/h-search?key=pronews&pushbutton=Search
KShell: http://hobbes.nmsu.edu/cgi-bin/h-search?key=kshell&pushbutton=Search