> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/de/ausfuhrliche-artikel/51-unicode-utf-8-and-multilingual-text-an-introduction.md).

# Unicode, UTF-8 und mehrsprachiger Text: Eine Einführung

## Unicode und OpenType: Zeichen und Glyphen

Moderne TeX-Engines, d. h. XeTeX und LuaTeX, haben sich aus Knuths ursprünglicher TeX-Engine vor allem deshalb weiterentwickelt, weil es notwendig war, mit den Entwicklungen in der Technologielandschaft Schritt zu halten, insbesondere Unicode (für Text) und OpenType (für Schriftarten). Heute können LaTeX-Anwender durch die Verwendung von Paketen wie [fontspec](https://ctan.org/pkg/fontspec?lang=en) und [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), können LaTeX-Anwender auf äußerst ausgefeilte Satzfunktionen zugreifen, die von OpenType-Schriften bereitgestellt werden – einschließlich fortgeschrittenem mehrsprachigem Satz und OpenType-basiertem mathematischen Satz ([von Microsoft vorangetrieben](https://blogs.msdn.microsoft.com/murrays)).

Allerdings kann es hilfreich sein, sich mit einer Reihe von Hintergrundthemen/-konzepten vertraut zu machen, um das Beste aus der Verwendung von OpenType-Schriften mit XeTeX/LuaTeX herauszuholen – insbesondere zur Fehlersuche oder als Grundlage für weitergehende/komplexere Arbeiten. So könnten Sie etwa lesen, dass die XeTeX- und LuaTeX-Engines „UTF-8-Eingabe“ verwenden oder „Unicode-bewusst“ sind, und weitere Lektüre zu OpenType-Schriften könnte Themen wie „Unicode-Kodierung“, OpenType-„Schriftfunktionen“, „Glyphen“, „Glyphen-IDs“, „Glyphennamen“ und dergleichen behandeln oder erwähnen. Unser Ziel ist es, eine Einführung in diese Begriffe/Themen zu geben und einen grundlegenden Rahmen zusammenzufügen, um zu zeigen, wie sie zusammenhängen und hoffentlich bei weiterem Arbeiten oder der Problemlösung zu unterstützen.

Die Themen, die wir behandeln möchten, lassen sich recht klar in zwei Hauptbereiche einteilen: *Unicode* die in der Praxis die Welt des Texts/der Zeichen und der Textkodierung bewohnt, und *OpenType* deren Welt aus Schriften und Glyphen besteht; aber natürlich sind diese beiden Welten miteinander verbunden und überschneiden sich teilweise, selbst in diesem ersten Artikel.

### Welche Themen werden wir besprechen?

Der Hauptfokus dieses Artikels liegt auf einigen Unicode-bezogenen Themen: beginnend mit einer Diskussion darüber, was mit einem „Zeichen“ gemeint ist, und weiterführend zu Schriften/Sprachen, Unicode-Kodierung und UTF-8 – zusammen mit einem Beispiel für die Arbeit mit mehrsprachigen Textdateien. Ein Folgeartikel wird auf diesem Beitrag aufbauen und Hintergrundthemen zur OpenType-Schrifttechnologie behandeln. Natürlich ist es im Rahmen eines Blogbeitrags nicht möglich, einen „Tiefgang“ in all die Bereiche zu versuchen, über die wir sprechen möchten: Unser erklärtes Ziel ist es, den Gesamtzusammenhang darzustellen und zu zeigen, wie einige Schlüsselkonzepte miteinander verbunden sind und zusammenwirken. Wir beginnen mit dem grundlegendsten Konzept: dem *Zeichen*.

## Das Zeichen: Ein grundlegender Baustein

Eine grundlegende Idee bzw. ein grundlegendes Konzept, das im Mittelpunkt unserer Diskussionen steht (und auch im Mittelpunkt von Unicode), ist die Bedeutung eines „Zeichens“: Es ist eines dieser Wörter, deren Bedeutung im Alltag und in Gesprächen oft durch ihren Gebrauch „vorausgesetzt“ wird. Aus der Perspektive von Unicode, Satz und Schrifttechnologien müssen wir jedoch etwas präziser sein und definieren, was mit „einem Zeichen“ gemeint ist. So wäre es zum Beispiel für uns ganz natürlich, **a** und *a* als unterschiedliche „Zeichen“: ‚fettes a‘ und ‚kursives a‘. Aber nein: Es sind lediglich unterschiedliche visuelle Darstellungen desselben grundlegenden Zeichens, dem Unicode den offiziellen Namen [LATIN SMALL LETTER A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [definiert ein Zeichen](http://www.unicode.org/glossary/#character) als:

> „Die kleinste Komponente geschriebener Sprache, die semantischen Wert hat; bezieht sich auf die abstrakte Bedeutung und/oder Form, statt auf eine bestimmte Form ...“

das klar zwischen der spezifischen *optische Gestaltung* und seiner *Bedeutung*.

Sie können sich ein Zeichen als die grundlegende Einheit oder den Baustein einer Sprache vorstellen oder, genauer gesagt, als eine *Schrift*—ein Thema, das wir unten besprechen. Wie ein Zeichen bei der Anzeige mit einer bestimmten Schrift tatsächlich aussieht, ist für die Unicode-Definition eines Zeichens nicht relevant: Nur die *Bedeutung* ist hier wirklich von Interesse: die *Rolle und der Zweck* jedes Zeichens als eines von mehreren Bausteinen, aus denen Schriften/Sprachen letztlich aufgebaut sind.

### Schrift und Sprache

Es lohnt sich, zwei wichtige Konzepte kurz zu erwähnen: *Schriften* und *Sprachen verwendet wird*. Die Unicode-Website bietet eine nützliche [Definition einer Schrift](https://www.unicode.org/standard/supported.html):

> „Der Unicode-Standard kodiert Schriften statt Sprachen. Wenn Schriftsysteme für mehr als eine Sprache Mengen grafischer Symbole teilen, die historisch miteinander verwandt entstanden sind, wird die Vereinigung all dieser grafischen Symbole als eine einzige Sammlung von Zeichen für die Kodierung behandelt und als eine einzige Schrift identifiziert.“

Anhand eines [Beispiels von Wikipedia](https://en.wikipedia.org/wiki/Script_\(Unicode\)), besteht die lateinische Schrift aus einer bestimmten [Zeichensammlung](http://unicode.org/charts/) die in mehreren Sprachen verwendet werden: Englisch, Französisch, Deutsch, Italienisch und so weiter. Natürlich werden nicht alle innerhalb der lateinischen Schrift definierten Zeichen von allen auf der lateinischen Schrift basierenden Sprachen verwendet – zum Beispiel enthält das englische Alphabet nicht die Akzentzeichen, die in anderen europäischen Sprachen wie Französisch oder Deutsch vorkommen.

### OpenType-Schriften: Schriften und Sprachen

An dieser Stelle wechseln wir von Unicode zu OpenType-Schriften, denn die Konzepte von Schrift und Sprache spielen auch innerhalb der OpenType-Schrifttechnologie eine äußerst wichtige Rolle.

Eine Gruppe von Sprachen, die dieselbe [Schrift](http://www.unicode.org/glossary/#script) kann jeweils unterschiedliche typografische Traditionen haben, wenn es darum geht, in einer bestimmten Sprache verfassten Text anzuzeigen bzw. zu setzen. Ein gutes Beispiel ist die türkische Sprache und das [Verhalten des punktlosen i](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (siehe die Hinweise zu Ligaturen auf jener Seite). Typografische „Regeln“, die sich auf Schriften/Sprachen beziehen, sind durch die Verwendung sogenannter Schrift- und Sprach- in die Funktionalität von OpenType-Schriften eingebaut *Tags* die verwendet werden, um Regeln zu identifizieren, die für bestimmte Schrift-/Sprachkombinationen gelten sollen. Natürlich variiert die von jeder OpenType-Schrift unterstützte Menge an Schriften/Sprachen je nach den Entscheidungen der Schriftersteller und dem Zweck ihrer Erstellung. Anspruchsvolle Satzsoftware wie XeTeX oder LuaTeX kann diese Regeln (die in OpenType-Schriften eingebaut sind) nutzen, indem sie den Benutzern erlaubt, sie beim Setzen von Text in einer bestimmten Sprache gezielt auf den Eingabetext anzuwenden – zum Beispiel mithilfe des LaTeX [Paket fontspec](https://ctan.org/pkg/fontspec?lang=en).

#### Ein Blick in eine OpenType-Schrift: Schriften/Sprachen

Um das zu verdeutlichen, hier ein Screenshot der kostenlosen [Scheherazade-OpenType-Schrift](http://software.sil.org/scheherazade/download/) geöffnet in der ebenfalls kostenlosen [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) Schriftbearbeitungssoftware. In diesem Bild sehen Sie die in Scheherazade eingebauten Schriften, Sprachen und typografischen Funktionen – mit VOLT können Sie Scheherazade zusätzliche Funktionen und Möglichkeiten hinzufügen, aber das liegt weit außerhalb des Rahmens dieses Artikels!

![Die Scheherazade-OpenType-Schrift (TrueType-Variante), geöffnet in Microsoft VOLT](/files/17350f32758b9f8d488e4b34c872d0a90c4fe8f8)

Aus diesem Screenshot können Sie sehen, dass Scheherazade die arabische und lateinische Schrift unterstützt und darüber hinaus spezielle Unterstützung für mehrere Sprachen bietet, die die arabische Schrift verwenden – mithilfe sogenannter OpenType-Funktionen, die im oben grün umrandeten Kasten aufgeführt sind. Auf die Einzelheiten dieser Funktionen gehen wir nicht ein, aber die Botschaft hier ist, dass hochwertige OpenType-Schriften viel Intelligenz in sich tragen, die von Satzsoftware genutzt werden kann, die in der Lage ist, die in Schriften eingebauten typografischen Regeln auszunutzen.

Interessierte Leser können im OpenType-Tag-Register nachsehen, um die [Schrift-Tags](https://www.microsoft.com/typography/otspec/scripttags.htm) und [Sprach-Tags](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) zu sehen, die derzeit in der OpenType-Spezifikation verwendet werden.

### Zurück zu den Zeichen: Verschiedene Zeichenrollen

Die Menge der Zeichen, die die grundlegenden Elemente einer Schrift (oder Sprache) bilden, erfüllen nicht alle dieselbe Rolle. In den meisten Sprachen gibt es beispielsweise Zeichen für *Interpunktion*, Zeichen für numerische *Ziffern* sowie Zeichen, die wir als *Buchstaben* des Alphabets, die bei manchen Schriften auch in Groß- und Kleinbuchstabenformen existieren. Der Begriff eines Zeichens ist recht weit gefasst, und der Unicode-Standard umfasst Spezialzeichen, die *nicht zur Anzeige bestimmt sind* deren Aufgabe es aber ist, „die Interpretation oder Anzeige von Text zu steuern“. Wenn Sie beispielsweise arabischen Text setzen, möchten Sie möglicherweise das Verbindungsverhalten bestimmter Zeichen erzwingen oder verhindern; der Unicode-Standard stellt dafür spezielle Steuerzeichen bereit: die sogenannten [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) und [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Diese Zeichen sind nicht zur Anzeige bestimmt und werden bei der Verarbeitung des Textes von der Software „absorbiert“, um ihre beabsichtigten visuellen Effekte zu erzeugen.

Allen im Unicode-Standard festgelegten Zeichen wird eine Reihe von Eigenschaften zugewiesen, die im Effekt die Rolle und den Zweck jedes Zeichens in der Unicode-Kodierung beschreibt – Zeichennamen wie LATIN SMALL LETTER A sind nur ein Element der Eigenschaftenliste eines Zeichens. Diese Eigenschaften sind in der [Unicode Character Database (UCD)](http://www.unicode.org/reports/tr44/) und werden weithin in computerisierten Textverarbeitungsaufgaben wie Suchen, Sortieren, Rechtschreibprüfung usw. verwendet. Datendateien, die Unicode-Zeicheneigenschaften auflisten, sind ebenfalls [zum Herunterladen verfügbar](http://www.unicode.org/Public/UCD/latest/).

Unter den jedem Zeichen zugewiesenen Eigenschaften ist für unsere Diskussion die wichtigste eine *numerische Kennung* die ihm durch seine Unicode-Kodierung zugewiesen wird; diesem Thema wenden wir uns nun zu.

### Zeichen: Zahlen und Kodierungen

Es ist eine Binsenweisheit, aber Computer und andere digitale Geräte speichern und verarbeiten numerische Daten: Wie hängt das also mit Text zusammen? Wenn Sie Text mit einer Computertastatur schreiben oder auf den Bildschirm eines mobilen Geräts tippen, werden Ihre Tastenanschläge in Zahlen umgewandelt, die die Zeichenfolge darstellen, die Sie eingeben.

Irgendwann möchten Sie diesen Text (eine Folge von Zahlen) per E-Mail, per Textnachricht oder über Online-Kommunikation wie einen Tweet oder einen Beitrag in irgendeiner Form sozialer Medien übertragen. Offensichtlich müssen sich das Gerät, auf dem Sie den Text verfasst haben, und das bzw. die Geräte des Empfängers bzw. der Empfänger irgendwie darüber einig sein, welche Zahlen welche Zeichen darstellen. Andernfalls wird Ihr Text auf dem Gerät des Empfängers möglicherweise nicht korrekt angezeigt.

Damit die heutige globale Kommunikation funktioniert, brauchen sendende und empfangende Geräte eine Art „gemeinsam vereinbarte Konvention“, durch die eine bestimmte Menge von Zahlen eine bestimmte Menge von Zeichen repräsentiert. Diese Konvention nennt man eine *Kodierung*: eine Menge von Zahlen, die verwendet wird, um eine bestimmte Menge von Zeichen darzustellen, und die Unicode-Kodierung ist heute der *de facto* globale Standard.

## Unicode: Bits und Bytes zum Speichern von Text

Unicode ist ein riesiger Standard, der weit, weit mehr als nur Textkodierung abdeckt, aber hier konzentrieren wir uns nur auf die von ihm bereitgestellte Kodierung.

#### Bits, Bytes und wie viele Zeichen?

Wir haben erwähnt, dass Geräte Text als Zahlen speichern und darstellen – genauer gesagt werden Zeichen als ganze Zahlen gespeichert: Ganzzahlen. Um die Auswirkungen davon für die Unicode-Kodierung zu verstehen, brauchen wir einen *sehr* kurzen, *sehr* grundlegenden Überblick darüber, wie Computer ganze Zahlen speichern (wir beabsichtigen nicht, in die Informatik einzutauchen).

Um eine sehr lange Geschichte kurz zu machen: Heutige Desktop- oder Handheld-Geräte speichern ganze Zahlen in diskreten „Blöcken“, die 1, 2, 4 oder 8 Byte lang sein können. Jede dieser Speichereinheiten kann ganze Zahlen bis zu einem maximalen positiven Wert speichern, der auf der Gesamtzahl der Bits in jeder Speichereinheit basiert:

* 1 Byte (8 Bits): maximale positive Ganzzahl ist 255;
* 2 Bytes (16 Bits): maximale positive Ganzzahl ist 65535;
* 4 Bytes (32 Bits): maximale positive Ganzzahl ist 4.294.967.295;
* 8 Bytes (64 Bits): maximale positive Ganzzahl ist 18.446.744.073.709.551.615.

In der Praxis verwendet der Unicode-Standard Zahlen im Bereich von 0 bis 1.114.111, um alle Zeichen der Welt zu kodieren, sodass er nur 21 Bits benötigt, um den vollen Bereich zu kodieren. Das können wir erkennen, indem wir beachten, dass Speichereinheiten mit n Bits jede positive Ganzzahl von 0 bis zu einem Maximalwert von $$2^n -1$$; folglich:

* der Maximalwert, der in 20 Bits gespeichert werden kann, ist $$2^{20} -1 = 1,048,575$$ (zu klein);
* der Maximalwert, der in 21 Bits gespeichert werden kann, ist $$2^{21} -1 = 2,097,151$$ (groß genug).

Wir haben festgestellt, dass Computer Daten (Zahlen) in Einheiten von 1, 2, 4 (oder 8) Bytes speichern, aber wie groß muss die Speichereinheit sein, wenn wir Werte bis zum maximalen Unicode-Wert von 1.114.111 speichern müssen? Klar, eine speichernde Einheit von Byte-Größe kann maximal den Wert 255 enthalten und 2 Bytes können 65535 speichern: Beides reicht nicht aus, um den gesamten von Unicode kodierten Zeichenbereich zu speichern. Die nächste verfügbare Option sind Speichereinheiten mit einer Größe von 4 Bytes, die ganze Zahlen bis zu einem Maximum von 4.294.967.295 speichern können – weit mehr, als wir tatsächlich bräuchten. Wenn wir also 4 Bytes als unsere Speichereinheit wählen würden, hätten wir sicher mehr als genug Platz, um alle Unicode-Werte zu speichern, wobei jedes Zeichen als Ganzzahl gespeichert würde, die 4 Bytes (32 Bits) benötigt. Allerdings wäre die Verwendung von 4 Bytes zum Speichern von allem äußerst platzverschwendend, denn selbst die größten Unicode-Werte benötigen maximal 21 Bits – was, wenn sie mit 32 Bits gespeichert würden, bedeuten würde, dass 11 dieser 32 Bits niemals verwendet würden.

**Hinweis**: Obwohl sich der Unicode-Bereich von 0 bis 1.114.111 erstreckt, wird nicht jeder Wert in diesem Bereich tatsächlich verwendet: Aus technischen Gründen gelten einige Werte als ungültig für die tatsächliche Verwendung als Unicode-Zeichen.

### Also, was ist UTF-8?

Wenn Sie über XeTeX oder LuaTeX lesen, werden Sie mit ziemlicher Sicherheit auf Erklärungen stoßen, die besagen, dass diese TeX-Engines Text- und LaTeX-Eingabedateien im „UTF-8-Format“ lesen. Also, was ist das „UTF-8-Format“ und wie hängt es mit Unicode zusammen? In der Unicode-Terminologie wird jeder der 1.114.112 Werte (von 0 bis 1.114.111), mit denen die Zeichen der Welt kodiert werden, als [Codepunkt](http://www.unicode.org/glossary/#code_point).

Wir haben gesehen, dass *theoretisch*, wir unseren gesamten Unicode-kodierten Text mit 4 Bytes pro Zeichen speichern müssten, um den gesamten Bereich der Unicode-Codepoints darzustellen. In der Praxis haben jedoch einige ziemlich kluge Leute einen einfachen Weg erfunden, eine einzelne Unicode-Zahl (einen Codepoint) als eine *Folge* Folge kleinerer Zahlen darzustellen, wobei jede dieser kleineren Zahlen in einem einzigen Byte gespeichert wird: ein Verfahren, das *wandelt* eine einzelne (größere) Ganzzahl in eine Folge kleinerer (bytegroßer) um. Durch diese Umwandlung wird jedes Zeichen unserer Textdatei nicht mehr durch einen einzelnen numerischen Wert dargestellt: Jedes Zeichen wird zu einer *Mehrbyte-Sequenz*—alles von 1 bis 4 aufeinanderfolgenden Bytes in der Textdatei kann ein einzelnes Unicode-Zeichen (d. h. seinen Codepoint-Wert) darstellen.

UTF steht für *Unicode Transformation Format* und das Schlüsselwort hier ist *Transformation*. Im Wesentlichen können Sie sich UTF-8 als ein „Rezept“ oder einen Algorithmus vorstellen, der einen einzelnen Unicode-Codepoint-Wert in eine Folge von 1 bis 4 bytegroßen Teilen umwandelt. Je größer der Wert des Unicode-Codepoints ist, desto mehr einzelne Bytes werden benötigt, um ihn im UTF-8-Format darzustellen.

Es gibt technische und historische Gründe für die Entstehung von UTF-8, und die Geschichte hinter der Erfindung von UTF-8 ist [in einer faszinierenden E-Mail aus dem Jahr 2003 festgehalten](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), die nahe dem Anfang der E-Mail die Zeile enthält:

> „Das stimmt nicht. UTF-8 wurde vor meinen Augen auf einer Serviette in einem Diner in New Jersey eines Nachts im September oder so 1992 entworfen.“

#### Ein Beispiel: der arabische Buchstabe ل

Nehmen wir als Beispiel den arabischen Buchstaben ل (Unicode-Name ARABIC LETTER LAM), dem der Unicode-Codepoint-Wert 1604 (dezimal) oder 0644 (hexadezimal) zugewiesen ist: Seine Darstellung in UTF-8 ist die *zweibyteige* Sequenz D9 84 (hex) oder, dezimal, 217 132. Wenn UTF-8 als Format zum Speichern von Text verwendet wird, wird statt einer Textdatei, die die einzelne Zahl 1604 zur Darstellung von ل enthält, diese in zwei bytegroße Werte umgewandelt: 217 und 132 – das Zeichen ل wird als eine *zwei-Byte-Sequenz*. Leser, die den UTF-8-Algorithmus ausführlicher erkunden möchten, finden eine ausführliche Erklärung und C-Code auf meiner [persönlichen Blogseite des Autors](http://www.readytext.co.uk/?p=1284).

Wenn ein Programm (z. B. XeTeX oder LuaTeX) Text im UTF-8-Format liest, muss diese Software den Unicode-Wert jedes in der Datei vorhandenen Zeichens bestimmen und verwendet daher einen Algorithmus, um *umkehren* den UTF-8-Transformationsprozess umzukehren. Durch diesen „Umkehralgorithmus“ werden die beiden Bytes (217 und 132) wieder zusammengeführt, um die Ganzzahl 1604 zu erzeugen, die dann als der Unicode-Codepoint-Wert für den arabischen Buchstaben ل erkannt werden kann.

Also, zusammenfassend ist UTF-8 wirklich nur ein intermediäres Datenformat, das für die Speicherung und Übertragung von Unicode-kodiertem Text verwendet wird.

**Hinweis**: Manche Systeme wählen es, Text mit 32 Bits pro Zeichen zu verwenden/speichern; das nennt man [UTF-32](https://en.wikipedia.org/wiki/UTF-32)—es gibt auch [UTF-16](https://en.wikipedia.org/wiki/UTF-16) aber UTF-8 ist die gängigste Art, Unicode-kodierten Text zu speichern.

## Mehrsprachige TeX-Dateien: XeTeX und LuaTeX

Sowohl XeTeX als auch LuaTeX sind zu sehr ausgefeiltem mehrsprachigem Satz in der Lage, obwohl ihre Mechanismen dafür ziemlich unterschiedlich sind und die Design-/Entwicklungsphilosophie der jeweiligen Engine widerspiegeln. Wir werden das nicht im Detail untersuchen, sondern nur festhalten, dass die XeTeX-Engine Softwarekomponenten enthält (die in ihre ausführbare Datei eingebaut sind), die in LuaTeX nicht vorhanden sind – vor allem Software für einen Prozess namens *OpenType-Shaping* (z. B. über eine Bibliothek namens [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX verfolgt hingegen einen anderen Ansatz: Anstatt Funktionen direkt in die eigentliche TeX-Engine einzubauen, stellt LuaTeX eine äußerst umfangreiche Sammlung von Befehlen (TeX-Primitive) und eine sehr leistungsfähige [Lua-basierte API](/latex/de/ausfuhrliche-artikel/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) über die Entwickler ebenso fortgeschrittene Lösungen für den mehrsprachigen Satz erstellen können. Obwohl die LuaTeX-Philosophie für LaTeX-Paketentwickler zusätzliche Arbeit bedeuten mag, bietet sie ein hohes Maß an zusätzlicher Flexibilität, weil die Lösungen nicht in die eigentliche LuaTeX-Engine „hart codiert“ sind, sondern aus TeX- und Lua-Code – oder Plugins, die in C/C++ geschrieben sind – aufgebaut werden.

**Nebenbei**: Leser, die die faszinierende, aber komplexe Welt des OpenType-Shapings weiter erkunden möchten, könnten daran interessiert sein, über die hervorragende Open-Source-Bibliothek namens [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—die von vielen Anwendungen verwendet wird, darunter Firefox, Chrome und LibreOffice und natürlich von XeTeX. Der Autor dieses Artikels hat HarfBuzz verwendet, um [LuaTeX-Plugins für den arabischen Satz zu erstellen](http://www.readytext.co.uk/?p=3186).

Heutzutage ist es (z. B. in sozialen Medien) üblich, Text zu übertragen, der Zeichen aus mehreren Sprachen enthält, und eine UTF-8-Textdatei, die mehrsprachigen Text speichert, kann leicht Zeichen enthalten, deren Darstellung in UTF-8 1, 2, 3 oder 4 Bytes lang ist. Im Effekt ist eine UTF-8-Textdatei also nur ein Strom einzelner Bytes, aber jedes tatsächliche Zeichen in dieser Datei kann irgendetwas von 1 bis 4 Bytes Länge sein: Die einzelnen Zeichen sind zu *Mehrbyte-Sequenzen*.

Um einige zentrale Aspekte der Arbeit mit mehrsprachigem Text (beim Satz) weiter zu erkunden, werden wir ein Beispiel mit der arabischen Schrift verwenden, weil Arabisch uns Raum bietet, mehrere Konzepte anzusprechen.

#### Nebenbei: die arabische Schrift

Die [Arabische Schrift](https://en.wikipedia.org/wiki/Arabic_script) wird in einer kursiven Schreibweise geschrieben, die von rechts nach links gelesen und geschrieben wird. Jeder arabische Buchstabe kann potenziell eine von 4 verschiedenen Formen annehmen, je nachdem:

* ob er als einzelnes, eigenständiges (isoliertes) Zeichen dargestellt wird (nicht mit etwas anderem verbunden);
* ob er innerhalb eines Wortes vorkommt – am Anfang, in der Mitte oder am Ende eines Wortes: bezeichnet als *Anfangs-*, *Mittel-* und *final* formen bzw.

Jedes Zeichen der arabischen Schrift hat seine eigene Menge an Verbindungsregeln und kann seine Form/Erscheinung ändern oder auch nicht, wenn links, rechts oder links und rechts ein anderes Zeichen steht. Leser, die dies weiter erkunden möchten, finden eine [vollständige Liste auf Wikipedia](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Beispiel: Arabischer und englischer Text in UTF-8

Angenommen, wir erstellen eine UTF-8-Textdatei mit einer einzigen Zeile englischen und arabischen Textes: This is العَرَبِيَّة text!

Diese Textzeile enthält 3 Leerzeichen, 11 englische Zeichen (lateinische Schrift) und 12 arabische Zeichen (auch wenn das vielleicht nicht sofort offensichtlich ist). Als UTF-8-Textdatei gespeichert, belegt sie 38 Bytes Speicher, was sich aus Folgendem ergibt:

* **lateinische Schrift**: Leerzeichen plus englischer Text: 14 ✕ 1-Byte-Zeichen = 14 Bytes;
* **Arabische Schrift**: 12 arabische Zeichen ✕ 2 Bytes pro Zeichen = 24 Bytes.

Insgesamt 14 + 24 = 38 Bytes.

#### Tiefer einsteigen

Wenn wir unseren Beispieltext in einer UTF-8-Datei namens `arabic.txt` speichern und in einem Hex-Editor öffnen, können wir sie untersuchen, um die tatsächlichen Bytes zu sehen, die sie enthält. Aus dem Studium des folgenden kommentierten Screenshots können Sie erkennen, dass der arabische Text mit 2 Bytes pro Zeichen gespeichert ist:

![Eine UTF-8-Textdatei mit englischem und arabischem Text, geöffnet in einem Hex-Editor.](/files/ed31b43424e761562580c22c390394d02797e258)

Eine UTF-8-Textdatei mit englischem und arabischem Text, geöffnet in einem Hex-Editor. Sie können deutlich sehen, dass Zeichen der lateinischen Schrift ein einzelnes Byte benötigen, während Zeichen der arabischen Schrift mit zwei Bytes pro Zeichen gespeichert werden.

Aus diesem Screenshot können Sie ein paar Beobachtungen machen:

* der arabische Text wird in einer links-nach-rechts-Sequenz gespeichert und die Zeichen sind die rohen, ungeformten (isolierten) Versionen der arabischen Buchstaben und Vokale;
* nach dem lateinischen Text „This is “ gibt es keine zusätzlichen Informationen, die einer Software, die diese Datei liest, mitteilen würden, dass das nächste Zeichen in arabischer Schrift ist.

Wenn Sie ein mehrsprachiges Dokument setzen (z. B. mit englischem und arabischem Text), dann muss XeTeX oder LuaTeX beim Lesen/Verarbeiten der Eingabetextdatei (als Datenstrom von Bytes) den Anfang und das Ende jedes Zeichens erkennen und die richtige Anzahl von Bytes lesen, die benötigt werden, um die UTF-8-Transformation rückgängig zu machen und den entsprechenden Unicode-Codepoint zu erzeugen. Es ist der UTF-8-Algorithmus selbst, der Software dies ermöglicht: Er erlaubt die Erkennung des ersten Bytes jedes einzelnen Zeichens und wie viele Bytes gelesen werden müssen, um den entsprechenden Unicode-Codepoint zu berechnen. UTF-8 ist einfach zu verwenden, aber wirklich ziemlich genial.

#### Logische Reihenfolge, Darstellungsreihenfolge und OpenType-Shaping

Wenn Sie sich das Arabische oben (العَرَبِيَّة) genau ansehen, kann es schwierig sein zu erkennen, dass unsere Textdatei tatsächlich 12 einzelne arabische Zeichen enthält – insbesondere, wenn Sie mit der arabischen Schrift nicht vertraut sind! Wenn Sie jedoch die arabischen Zeichen auf der rechten Seite des obigen Screenshots sorgfältig zählen, sehen Sie, dass es insgesamt 12 sind.

Bei Sprachen mit komplexer Schrift, wie Arabisch, was unsere Textdatei *speichert* und was Sie *auf dem Bildschirm sehen* ist sichtbar *sehr* wirklich unterschiedlich! Was Sie sehen, wenn Sie diesen Text beispielsweise in einem Browser anzeigen, ist (je nach verwendeter Schrift):

![Bild von gesetztem arabischem Text](/files/54d9145301547a7aea71f0ebabf42c4a469bfdcc)

Aber wie der obige Screenshot zeigt, enthält die UTF-8-Textdatei tatsächlich Folgendes:

![Bild von nicht gesetztem arabischem Text (isolierte Zeichen)](/files/f668ce66a12c09748f12dfdc0e752eec16119572)

Selbst wenn Sie mit der kursiven Natur der arabischen Schrift nicht vertraut sind, können Sie deutlich sehen, dass während der Übertragung der in einer Textdatei enthaltenen arabischen Zeichen bis hin zum Satz und/oder zur Anzeige auf dem Bildschirm (als Glyphen) „etwas“ passiert ist. Wenn Sie TeX/LaTeX mit Sprachen mit einfacher Schrift verwenden, zum Beispiel mit auf dem Lateinischen basierenden Sprachen, kann das wirklich sehr verwirrend sein!

Hier spielen einige wichtige Konzepte eine Rolle, denn Unicode-Textdateien dienen der Speicherung von … nun ja, Text (Unicode), und Satz- und Anzeigesysteme arbeiten mit Schriften und Glyphen (OpenType):

* die Textdatei speicherte die arabischen Zeichen in links-nach-rechts-Reihenfolge, aber Arabisch wird von rechts nach links gelesen/angezeigt: Textdateien speichern Text in der sogenannten *logischen Reihenfolge*;
* die Textdatei enthält einzelne Zeichen, die ganz anders aussehen als die eigentliche Anzeige auf dem Bildschirm: Die Textdatei enthält die arabischen Zeichen in ihrer isolierten, nicht verbundenen Form.

#### Was geht hier vor?

Innerhalb einer Textdatei wird Arabisch als links-nach-rechts-Sequenz isolierter Zeichen gespeichert: Wenn Sie darüber nachdenken, speichert die Textdatei den arabischen Text in der Reihenfolge/Abfolge *in der er getippt wurde* (die *logischen Reihenfolge*). Erst wenn dieser Text zur Anzeige verarbeitet oder gesetzt wird, wird er in seiner korrekten Leserichtung angezeigt, oft als *visuelle Reihenfolge* oder *Darstellungsreihenfolge*; außerdem werden die isolierten Formen der arabischen Zeichen *geformt* in ihre typografisch korrekten Darstellungsformen. Eine Möglichkeit, dies zu verstehen, besteht darin, dass eine einfache Textdatei Text (Unicode-Zeichen) in der grundlegendsten möglichen Form speichern muss: rohe, ungeformte, einzelne Textzeichen – es ist die Aufgabe der Systemsoftware, diese Zeichen zur Anzeige zu rendern, basierend auf dem Betriebssystem, den Schriften und der auf dem Anzeigegerät verfügbaren Satz-/Render-Software.

Wenn der arabische Text in jener Datei gesetzt/angezeigt wird, durchläuft er einen Prozess namens *Shaping*. Die einzelnen arabischen Zeichen werden in geformte Glyphen umgewandelt, die die jeweilige, gemäß den Verbindungsregeln der arabischen Schrift und des Schriftsystems erforderliche Variante jedes Zeichens korrekt darstellen. Darüber hinaus führt hochwertige Satzsoftware (unter Verwendung guter OpenType-Schriften) weitere Verarbeitungsschritte aus, indem sie zusätzliche typografische Raffinesse durch einen Prozess namens *OpenType-Shaping*—ein Prozess, der ein breites Spektrum typografischer Operationen umfasst, darunter:

* das Ersetzen mehrerer einzelner Glyphen durch eine einzige komplexe Ligatur-Glyphe (sehr häufig im Arabischen) oder
* Positionierungsoperationen, die beispielsweise die Positionen arabischer Vokale je nachdem anpassen, über oder unter welcher Glyphe sie stehen.

![Bild, das die Umwandlung zeigt, die arabischer Text beim Satz durchläuft](/files/c79cc6c3a4c9258b1759386af4e4c6597e77c435)

Der Unterschied zwischen logischer Reihenfolge und visueller (Anzeige-)Reihenfolge. In dieser Grafik sehen Sie, dass arabische Zeichen, die in einer Textdatei gespeichert sind, beim Anzeigen oder Setzen neu angeordnet und geformt werden.

Gestalter und Entwickler fortgeschrittener OpenType-Schriften investieren sehr viel Zeit und Fachwissen, um die ausgefeilten typografischen Fähigkeiten bereitzustellen, die in ihre Schriften eingebaut sind.

Um die auf den arabischen Text angewendete Formung auszuschalten, können wir den hervorragenden, kostenlosen, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) Unicode-Texteditor (nur Windows), mit dem Sie die Formung deaktivieren können, um die rohen, einzelnen, unverbundenen (ungeformten) Zeichen zu sehen, die tatsächlich in der Textdatei vorhanden sind—siehe die untere Hälfte dieses kombinierten Screenshots:

![Bild, das die Fähigkeit des BabelPad-Texteditors zeigt, die OpenType-Formung auszuschalten](/files/b1590326b9596b22a92d810e228bcc6cab1617d3)

Verwendung des BabelPad-Unicode-Texteditors zum Einschalten der OpenType-Formung (oben) oder zum Ausschalten (unten). Das Ausschalten der OpenType-Formung macht das Bearbeiten arabischen Textes erheblich einfacher.

Die Konzepte der logischen Reihenfolge und der Anzeige-Reihenfolge, zusammen mit den Formungsprozessen, können ziemlich verwirrend sein, wenn man ihnen beim Bearbeiten oder Satz von mehrsprachigen Textdateien mit komplexen Schriften wie Arabisch zum ersten Mal begegnet: hoffentlich hat das oben geholfen, einige anfängliche Verwirrung zu vermeiden.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/de/ausfuhrliche-artikel/51-unicode-utf-8-and-multilingual-text-an-introduction.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.