© bastian-dietz, photocase.com
Ein Blick hinter die Kulissen der Zeichensätze und
Kodierungen
Umlaute auf Umwegen
von Michael Schilli
Erschienen im Linux-Magazin
2007/07
Kommen Umlaute in Programmtexten oder Daten ins Spiel, ist der Perl-Programmierer gefragt. Denn ohne seine Mithilfe entstünde ein Kodierungskauderwelsch.
Am Anfang war die Ascii-Tabelle: 128 Zeichen, mit denen jedermann problemlos englische Texte schreiben konnte, zusammen mit den von der Schreibmaschine bekannten Sonderzeichen wie »%« oder »$« und natürlich auch mit den Kontrollzeichen wie Zeilenumbruch, Seitenvorschub oder Terminalklingel. Als dann später einige Europäer die in ihren Sprachen heimischen Sonderzeichen einbringen wollten, wurden die einfach in die nächsten 128 Zeichen gepresst. Alle 256 Zeichen ließen sich auf diese Weise von 0 bis 255 durchnummerieren und auf dem Computer mit 8 Bits (1 Byte) kodieren.
Der ISO-8859-Standard oder salopper: Latin-1 war damit geboren. Zuerst als ISO-8859-1, aber mit der Zeit kamen weitere Varianten hinzu. Die bislang letzte Version ist ISO-8859-15, die auch das Eurozeichen enthält. Übrigens verwenden die meisten gegenwärtig Dienst tuenden Webbrowser nicht den ISO-8859-1-Standard zur Dekodierung, selbst wenn es der Webserver verlangt. Stattdessen arbeiten sie nach dem Windows-1252-Standard, der noch einige zusätzliche Zeichen und wie ISO-8859-15 das Eurozeichen definiert.
Alle wollen mitspielen
Bald wollte die restliche Welt teilhaben und die Computer sollten auch ihre zum Teil voluminösen Zeichensätze darstellen. Dazu erfanden Normierungsgremien Kodierungsschemata für asiatische Schriften wie Shift-JIS und BIG5. Aber bald erwies sich das als eine Sackgasse und das Unicode Consortium erfand die gleichnamige Kodierung: eine riesige Tabelle, die alle gängigen Zeichen aller Weltsprachen enthält.
Ein Weg, die Unicode-Tabelle auf dem Computer effektiv darzustellen, ist der UTF-8-Standard. Denn hätten herkömmliche Ascii-Zeichen plötzlich durchgehend mit zwei oder gar vier Bytes kodiert werden müssen, wäre der Platzbedarf sprunghaft angestiegen. Um die Zeichen der alten Ascii-Tabelle weiterhin mit nur einem Byte darstellen zu können, ist die UTF-8-Tabelle so angelegt, dass die ersten 128 Zeichen genau der Ascii-Tabelle entsprechen.
Die zweite Hälfte der untersten 256 Zeichen besteht jedoch zum Teil aus speziellen Maskierungs-Codes, die anzeigen, dass nach ihnen noch eine definierte Anzahl weiterer Codes folgt, die zusammen das darzustellende Zeichen aus der Unicode-Tabelle eindeutig festlegen. Zum Beispiel ist der Umlaut ü in der ISO-8859-15-Tabelle unter der Nummer 252 (»0xFC«) abgelegt. Liegt also ein Text in ISO-8859-15 vor und ein Byte hat den Wert »0xFC«, dann ist klar: Dieses Zeichen ist ein ü.
A mit Welle
Die UTF-8-Kodierung hingegen stellt den Umlaut ü mit den beiden Bytes 195 und 188 (»0xC3« und »0xBC«) dar. Liegt ein Text in UTF-8 vor und der Computer stößt erst auf einen Bytewert von »0xC3« gefolgt von »0xBC«, ist hier ebenso klar: Dort steht der Buchstabe ü.
Ist jedoch die Kodierung eines Bytestroms nicht bekannt und der Computer findet ein Byte mit dem Wert »0xC3«, dann stellt sich die Frage: Ist dies das erste Byte eines westeuropäischen Umlauts im UTF-8-Format? Oder ist das Byte nach ISO-8859-15 zu interpretieren und stellt alleine bereits die vollständige Kodierung eines Zeichens dar?
Wird das einleitende Byte »0xC3« einer UTF-8-Sequenz fälschlicherweise nach ISO-8859-15 interpretiert, kommt ein Zeichen zum Vorschein, das leidgeplagte Programmierer, die zwischen den Kodierungswelten wandeln, bis zum Überdruss kennen: das A mit Welle.
Dieses in Abbildung 1 gezeigte Zeichen kommt zwar nach [2] in der portugiesischen, vietnamesischen und der kaschubischen Schrift vor. Wer jedoch normalerweise nicht in diesen Gefilden operiert, aber ein A mit Welle erblickt, arbeitet wahrscheinlich mit einem in UTF-8 kodierten Text, der irrtümlich nach ISO-8859-15 interpretiert wurde.

|
Abbildung 1: In einem auf ISO-8859-15 eingestellten Terminal funktioniert die Ausgabe in Latin1, die Ausgaben nach UTF-8 ergeben Kaschubisch.
|
| Whitepaper |
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)
Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
|
Usage Landscape Enterprise Open Source Data Integration
Die Nachfrage nach Datenintegrationslösungen für Unternehmen ist zunehmend gestiegen und vor allem das Interesse an Open Source Technologien wird immer größer. Doch wie und von wem werden Open Source Datenintegrationslösungen genutzt und welches Nutzungsverhalten lässt sich daraus ableiten? Das vorliegende White Paper präsentiert die Erfahrungswerte von über 1000 Open Source Nutzern und liefert fundierte Antworten auf diese Fragen.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
Powercode,
28.12.2011 10:55
http://www.utf-8.de
Ein paar hilfreiche Tips und auch eine ASCII Tabelle mit allen UTF-8 Charactern.