Begriff
UTF-8 (8-Bit Unicode Transformation Format)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Unicode ist die Liste der Nummern (A=65).
UTF-8 ist die Regel, wie man diese Nummern als Nullen und Einsen speichert.
Der geniale Trick:
- Ein normales
A(65) braucht nur 1 Byte. (Genau wie in ASCII. Alte Dateien bleiben lesbar!). - Ein
übraucht 2 Bytes. - Ein
€braucht 3 Bytes. - Ein
💩braucht 4 Bytes. UTF-8 ist "variabel lang". Es verschwendet keinen Platz für englische Texte, kann aber trotzdem alle Zeichen darstellen. Deshalb nutzen heute 98% aller Webseiten UTF-8.
Merksatz: Die dominierende Zeichenkodierung im Internet, die jedem Unicode-Zeichen eine variable Anzahl von Bytes (1 bis 4) zuweist und dabei abwärtskompatibel zu ASCII ist.
HTML:
<meta charset="utf-8">.
Ohne das rät der Browser (und rät oft falsch -> ??? statt Umlaute).
Datenbanken (MySQL):
Nutze utf8mb4.
(Das alte utf8 in MySQL konnte nur 3 Bytes und damit keine Emojis. Das war ein Bug, der zum Feature wurde).
1. Self-Synchronization
UTF-8 ist so gebaut, dass man nie "mitten in ein Zeichen" fällt.
Start-Bytes sehen so aus: 110xxxxx, 1110xxxx.
Folge-Bytes sehen so aus: 10xxxxxx.
Wenn die Verbindung abbricht und du mitten im Stream wieder einsteigst, erkennst du sofort: "Ah, das ist ein Folge-Byte, ich suche das nächste Start-Byte."
Bei anderen Encodings (UTF-16) führt ein fehlendes Byte dazu, dass sich der ganze Text verschiebt (Müll).
2. Overlong Encodings (Security!)
Ein Hacker könnte versuchen, das Zeichen / (2F) als langes 2-Byte-Monster zu codieren, um Sicherheitsfilter zu umgehen.
Der UTF-8 Standard verbietet das. Es gibt nur eine gültige Schreibweise für jedes Zeichen (die kürzeste).
Parser müssen "Overlong Encodings" als Fehler ablehnen.
3. UTF-8 vs UTF-16
Windows und Java nutzen intern UTF-16 (jedes Zeichen fast immer 2 Bytes). Vorteil: Schneller zu springen "Gehe zu Zeichen 50". Nachteil: Verschwendet Platz bei englischem Text (jedes zweite Byte ist 0). Linux und Web nutzen UTF-8.
Validierung an Systemgrenzen
UTF-8 ist nicht nur ein Speicherformat, sondern ein Vertrag zwischen Systemen. Ein Backend sollte Eingaben beim Eintritt validieren und ungueltige Bytefolgen ablehnen oder bewusst ersetzen. Sonst können Logs, Suchindizes oder Datenbanken unterschiedliche Zeichen sehen, obwohl der Nutzer scheinbar denselben Text gesendet hat.
Normalisierung
Manche Zeichen können in Unicode auf mehreren Wegen dargestellt werden. Ein "ae" mit Akzent kann als fertiges Zeichen oder als Buchstabe plus kombinierendes Zeichen gespeichert sein. Für Suche, Login-Namen und Signaturen braucht man deshalb Normalisierung, damit gleiche sichtbare Zeichen auch gleich verglichen werden.
Security-Gotchas
Parser dürfen keine Overlong Encodings akzeptieren, weil Angreifer sonst Filter umgehen können. Ebenso kritisch sind unsichtbare Steuerzeichen, Right-to-Left-Markierungen und Lookalike-Zeichen. In Quellcode, Domains oder Logs können sie Menschen taeuschen, obwohl die Bytes technisch gueltig sind.
Quick-Check
BOM bei UTF-8?
Meistens schlecht. Das Byte Order Mark am Anfang der Datei macht Scripts kaputt (Shebang#!/bin/bashwird nicht mehr erkannt). "UTF-8 without BOM" ist der Standard.Warum 4 Bytes?
Unicode geht bis U+10FFFF (ca 1.1 Mio). Um 1.1 Mio darzustellen, reichen 21 Bits. UTF-8 packt diese 21 Bits geschickt in 4 Bytes à 8 Bit (mit Markern).Emoji-Support?
Erfordert 4 Bytes. Viele alte Systeme (SMS, alte DBs) konnten nur 3 Bytes (BMP - Basic Multilingual Plane) und scheiterten an Emojis.