04-TLG-2011 Übersetzungsprojekt „Softwarelokalisierung“ 2. Semester, Donnerstag um 17:15, H002

Kodierung

Einheiten

8 Bit=1 Byte
2 Byte=1 Wort

ASCII

Im American Standard Code for Information Interchange (ASCII) hat jedes Zeichen acht Bits, also ein Byte. Eines dieser acht Bits ist für andere Zwecke reserviert; für die Kodierung eines Zeichens verbleiben also sieben Nutzbits. Ein solches „trunkiertes“ Byte kann damit in 27 = 128 Kombinationen (entsprechend einer Zeichentabelle (code page) vorkommen. Das klingt viel, ist aber zu wenig für die Skripte (Alphabete) der Welt, denn brauchen wir auch noch Zahlen, Interpunktionszeichen, Sonderzeichen (z. B. Klammern und mathematische Operatoren) und nichtdruckbare Zeichen (Zeilenvorschub, Tabulator …). In den meisten Alphabeten muss überdies jeder Buchstabe zweimal vorgehalten werden, einmal als Minuskel und einmal als Majuskel.

ANSI

Für mehr Internationalität sorgte eine Initiative des American National Standards Institute (ANSI) mit dem Vorschlag, ASCII weiter zu verwenden, diesmal jedoch unter Nutzung des achten Bits für druckbare Zeichen. Man hatte pro Tabelle damit 28 = 256 Zeichen zur Verfügung.

Die Skripte der Welt hätten das nun bestehende Aufnahmevermögen von 256 Zeichen aber immer noch gesprengt. Man hat deswegen begonnen, für unterschiedliche Skripte unterschiedliche Zeichentabellen bereitstellen; je nach eingestellter Zeichentabelle kann in ANSI ein bestimmtes Bitmuster für das eine oder eben für das andere Zeichen stehen. Jeder Skriptwechsel (etwa beim Wechsel der Oberflächensprache in einem Programm) erforderte also einen Tabellenwechsel, nicht einfach besonders dann, wenn man innerhalb eines Textes gemischte Skripte benötigte, etwa Kyrilliza und Latiniza.

UCS-2 / UTF-16

Im Jahre 1991 lag die erste universelle Kodierung vor – das Unicode Transformation Format (UTF). Mit UTF konnte man das erste Mal zwischen Skripten wechseln, ohne gleich eine neue Zeichentabelle ziehen zu müssen. Diese Universalität wurde dadurch möglich, dass man die alte Regel „1 Zeichen = 1 Byte“ aufzuweichen begann. Die meisten Anwendungen verwenden heute UTF-16, also aus einem oder zwei Worten bestehende Zeichen.

Zweifellos war es eine Errungenschaft, dass nun alle Zeichen mit einer Kodierung dargestellt werden konnten. Musste man deswegen aber gleich so mit Ressourcen aasen? UTF-16 verbrauchte mit 16 oder 32 Bits pro Zeichen doppelt oder viermal so viel wie ein ASCII-Zeichen, während die meisten Zeichen – zumindest jene, die wir Mitteleuropäer verwenden – auch in der auf dem englischen Alphabet basierenden ASCII-Tabelle zu finden wären, sich also mit einem Byte darstellen ließen. Bei diesen Zeichen hat UTF-16 nur für das niedrigstwertige Byte Verwendung – das andere (höchstwertige) wird mit Nullen beschrieben und praktisch „leer“ mitgeschleppt. Diese Vorgehensweise ist solange kein Problem, wie die Daten auf der Festplatte liegen.

Sobald wir mit ihnen aber arbeiten wollen, müssen sie in den Arbeitsspeicher geladen werden: Es findet ein Datenstrom statt. Für diesen Datenstrom musste man sich eine sparsamere Lösung ausdenken. UTF-8 beansprucht, wie wir an der Zahl 8 im Namen erkennen sollen, ein zweites Byte nur dann, wenn es dieses Byte auch braucht.

Schwachstelle „Arbeitsspeicher“

Arbeitsspeicher sind für Mehrbytezeichen eigentlich nicht geeignet. Der Arbeitsspeicher eines Computers besteht aus durchnummerierten Speicherzellen, von denen jede genau ein Byte beherbergen kann. Ein ASCII-Zeichen passte mit seinen acht Bits also genau in eine solche Speicherzelle. Ist ein Zeichen nun länger als 1 Byte, so muss es auf mehrere benachbarte durchnummerierte Speicherzellen verteilt werden. Auch das wäre noch kein großes Problem, würden wenigstens die Prozessoren alle gleich vorgehen. Aber das tun sie nicht.

Schwachstelle „Prozessor“

Kehren wir noch einmal zu unserem Datenstrom zurück, der entsteht, wenn wir die Daten benutzen. Problematisch ist ein solcher Datentransport, wenn er wortweise stattfindet, wie wir es bei UTF-16 haben. (UTF-8 wird beginnend im höherwertigen Byte interpretiert. Die Bytereihenfolge ist bei UTF-8 damit geklärt.) Bei UTF-16 variiert die Reihenfolge, in welcher die Bytes eines Worts „angefasst“ werden – die Prozessorarithmetik, Endianness) – von Prozessor zu Prozessor. Manche schreiben zuerst das höchstwertige Byte eines Worts (legen es in die erste freie Speicherzelle, jene mit der niedrigsten Nummer), andere (besonders jüngere wie Intel) beginnen mit dem niedrigstwertigen Byte. Es existieren auch gemischte Szenarien. Wir sprechen von Big-endians, Little-endians und Mixed- / middle-endians.

Den passenden Rückschluss aus dem Gesagten haben Sie wahrscheinlich schon gezogen: Die in einer Datei vorliegende Notation muss der Nachwelt irgendwie mitgeteilt werden. Nur so kann ein verarbeitendes Programm wissen, wie herum es ein Wort dem Prozessor reichen soll. Die Rechenoperation 54 + 37 führt nur dann zu demselben Ergebnis wie die Operation 45 + 73, wenn die erstgenannte Operation von einem big endian durchgeführt wird und die letztgenannte von einem little endian.

Die oben erwähnte Mitteilung übernimmt für uns eine Präambel – eine Zeichenfolge am Dateianfang, die keine literale Bedeutung hat und Byte Order Mark heißt, kurz BOM / bɒm /.

Das Byte-Order-Mark (BOM)

Für UTF-16 gilt zunächst:

Das Byte-Order-Mark unterrichtet ein Programm über eine vorliegende (die beim Schreiben in die Datei angewandte) Byte-Reihenfolge (Notation) im Wort.

Leider hören die Probleme hier nicht auf: Woher soll ein verarbeitendes Programm wissen, ob eine bestimmte 16-Bit-Sequenz eines präambellosen Dokuments für zwei Einbytezeichen steht oder für ein Zweibytezeichen, also verkettet oder addiert werden soll, sprich, ob ASCII oder Unicode vorliegt? Für UTF-8, das das BOM in seiner eigentlichen Funktion nicht benötigt, gilt weiter:

Mit dem Byte-Order-Mark kann man ausschließen, dass UTF-8-kodierter Text versehentlich als ASCII interpretiert wird.

Illustriert sei dies an dem folgenden konstruierten Satz: Die Wörter слово und стол verlangen dem Lerner äußerst viel Übung ab. Dieser Satz enthält die deutschen Sonderzeichen und kyrillische Buchstaben und würde auch ohne BOM in einem einigermaßen gescheiten Texteditor etwa so aussehen:

GILT-Modell nach Cadieux / EsselinkUnser Testsatz in einer csv-Datei UTF-8 ohne BOM, Ausgabe im Editor Notepad++.

Die Zeichen wurden von dem Editor dank dessen eigener Heuristik (s. u.) als UTF-8-codiert erkannt und richtig dargestellt. Schauen wir uns nun den Satz im Editor von SDL Studio 2014 an:

Testsatz UTF-8 ohne BOMUnser Testsatz in Studio.

Die Zweibytezeichen werden von Trados Studio nicht als solche erkannt. Im Wort Wörter werden beispielsweise statt des Zweitbytezeichens ö die zwei Einbytezeichen à und ausgegeben. Wir setzen das BOM und laden die Datei in Studio nach:

Testsatz UTF-8 mit BOMDer Testsatz mit BOM.

Die Zweibytezeichen werden nun auch als solche erkannt.

Nicht, dass es ohne BOM gar nicht ginge in UTF-8. Wie wir oben gesehen haben, kommt Notepad++ mit der Datei auch ohne BOM zurecht. Manche Programme verfügen über eine Heuristik, die den Dateiinhalt nach UTF-8-verdächtigen Byte-Kombinationen durchsucht, und erkennen UTF-8 von selbst. Aber nicht immer ist eine solche Heuristik sinnvoll, etwa da, wo Geschwindigkeit eine Rolle spielt. Denn das Programm muss hierfür den Quellstrom erst einmal durchforsten, was die Hardware in Beschlag nimmt und Zeit kostet. Wenn ein Byte-Order-Mark gesetzt ist, fällt dieser Arbeitsschritt weg; entsprechend zügiger kann der Datenstrom bereitgestellt werden. Für UTF-8 gilt deswegen schließlich:

Mit dem Byte-Order-Mark können die Daten effizienter verarbeitet werden.

Dass das BOM auch stören kann, behindert uns Übersetzer weniger.

  • Seltener passiert mittlerweile, dass das BOM nicht erkannt und stattdessen dargestellt wird (als die Latin-1-Zeichen ).
  • Zuweilen erscheint in Oberflächen ein nicht interpretiertes BOM als Leerzeile.

  1. SL-Markt 2015 nach Größe (Weltmarkt)
  2. SL-Markt in Deutschland 2015 nach Profil
  3. Übersetzerisches Fremdkonzept in der SL
  4. Was? Übersetzerisches Selbstkonzept in der SL
  5. Wie? Vorgehensmodelle in der Softwarelokalisierung
  6. Desintegration translatorischer Teilprozesse
  7. Kooperationsdistanz in der Softwarelokalsiierung
  8. GILT
  9. Lokalisierung
  10. Internationalisierung
  11. Personalisierung
  12. Kodierung
  13. CSV
  14. Key-Value-Tabellen
  15. XML-Ressourcen
  16. Quelltextdateien
  17. Binärdateien
  18. Typen dateibasierter Ressourcen
  19. Internationalisierung (I18N): Praxis
  20. UI-Textsorten
  21. Linguistische Probleme in der Softwarelokalisierung
  22. Assimilation
  23. Numerusbehandlung (plural handling, pluralization)
  24. Translation Scripting