UTF-8

UTF-8 (Unicode Transformation Format, 8-Bit) ist eine Kodierung variabler Breite für Unicode-Zeichen. Jeder Codepoint wird je nach Wert zu 1–4 Byte kodiert: ASCII-Zeichen (U+0000 bis U+007F) belegen ein Byte; gängige lateinische Erweiterungen sowie Griechisch/Kyrillisch zwei; CJK-Ideogramme drei; Emojis und seltene Schriften vier.

Entworfen von Ken Thompson und Rob Pike im Jahr 1992, vor allem für Plan 9. Wesentliche Eigenschaften:

• ASCII-kompatibel. Reiner ASCII-Text ist Byte für Byte gültiges UTF-8.
• Selbstsynchronisierend. Wird ein Datenstrom mitten im Zeichen beschädigt, kann der Dekoder die nächste Zeichengrenze finden, ohne zurückspulen zu müssen.
• Kein Byte-Reihenfolge-Problem. Byte werden von links nach rechts verarbeitet; es gibt keine Unterscheidung zwischen Big-Endian und Little-Endian.
• Kompakt für lateinische Schriften, weniger kompakt als UTF-16 bei CJK-dominierten Inhalten (3 Byte pro Zeichen statt 2).

UTF-8 ist die dominierende Kodierung im Web — über 98 % der Seiten stand 2024. Es ist der Standard für HTML5, JSON (wo die RFC-8259-Spezifikation UTF-8 sogar vorschreibt) und praktisch jedes moderne Protokoll. Alte Kodierungen (Windows-1252, ISO-8859-1, Shift-JIS) überleben in Altsystemen, sollten aber beim Eintritt in einen modernen Stack konvertiert werden.

Die BOM-Kontroverse (Byte Order Mark): UTF-16 und UTF-32 nutzen am Dateianfang eine 2- oder 4-Byte-BOM, um die Byte-Reihenfolge anzuzeigen, doch UTF-8 hat keine Byte-Reihenfolge zu kennzeichnen. Microsoft-Werkzeuge stellen dennoch gewohnheitsmäßig eine 3-Byte-UTF-8-BOM (EF BB BF) voran, während Unix-Werkzeuge das in der Regel nicht tun. Das Ergebnis: aus Notepad gespeicherte Shell-Skripte gehen kaputt, CSV-Importe zeigen unsichtbaren Müll in der ersten Zelle, und YAML/JSON-Parser weisen die Datei ab. Der Unicode-Standard duldet eine UTF-8-BOM, schreibt sie aber nicht vor; die moderne Empfehlung lautet „keine hinzufügen“. Erhält man eine Datei mit BOM, sollte man sie beim Lesen entfernen.

Zeichenlänge vs. Byte-Länge — der stets relevante Stolperstein: in den meisten Sprachen liefert "hello".length 5 (Zeichen), aber Buffer.byteLength("hello", "utf8") liefert 5 (Byte — bei ASCII gleich). Für "café" ist die Zeichenlänge 4, die Byte-Länge aber 5 (das é sind 2 Byte). Für "🎉" ist die Zeichenlänge in JavaScript 2 (Surrogatpaar), die Byte-Länge aber 4 und die Graphem-Länge 1. UTF-8-Strings nach Byte-Anzahl ohne Graphem-Bewusstsein abzuschneiden erzeugt regelmäßig Mojibake — die übliche Lösung ist die Intl.Segmenter-API (moderne Browser) oder das npm-Paket graphemer. Quelle: RFC 3629 — UTF-8, a transformation format of ISO 10646.

Durchgerechnetes Beispiel

Kodieren Sie die Zeichenfolge „A€🎉“. Codepoint und UTF-8-Byte-Sequenz jedes Zeichens: A (U+0041) → 1 Byte 0x41. € (U+20AC) → 3 Byte 0xE2 0x82 0xAC (die hohen Bits kodieren die Länge: 1110xxxx 10xxxxxx 10xxxxxx). 🎉 (U+1F389) → 4 Byte 0xF0 0x9F 0x8E 0x89. Insgesamt: 8 Byte für 3 Zeichen. In einer als VARCHAR(10) mit UTF-8-Zeichensemantik deklarierten Datenbankspalte (modernes PostgreSQL, MySQL mit utf8mb4) passt das bequem. In einer festen Byte-Spalte VARCHAR(10) BYTES (älteres MySQL utf8, das tatsächlich auf 3 Byte begrenzt war) passt die 4-Byte-Kodierung des Emojis überhaupt nicht — der klassische Fehler „Emoji lässt sich in MySQL nicht speichern“. Die Lösung in MySQL seit 5.5.3 ist die Verwendung von utf8mb4 als Spalten- und Verbindungs-Zeichensatz.

Wann und warum es zählt

Fast jedes Byte, das Sie im modernen Web verarbeiten, ist wahrscheinlich UTF-8, doch mehrere Schichten machen es noch immer falsch. HTTP-Anfragen ohne explizites Content-Type: text/...; charset=utf-8 können in älteren Proxys auf ISO-8859-1 fallen; alte Mainframe-ETL-Jobs liefern EBCDIC-Dateien, die beim Einlesen umkodiert werden müssen; die Windows-Konsolenausgabe verwendet standardmäßig die System-Codepage (CP-1252 auf den meisten US-englischen Installationen) und beschädigt durchgeleiteten Text ohne ein vorheriges chcp 65001. Die defensive Praxis: UTF-8 überall explizit deklarieren (HTML <meta charset="utf-8">, HTTP-Header, Datei-Encoding-Pragmas, Datenbank-Verbindungszeichensätze) und alle eingehenden Byte gegen die UTF-8-Grammatik validieren — ungültige Byte-Sequenzen sind ein verlässliches Zeichen für eine vorgelagerte Zeichensatz-Diskrepanz. Quelle: WHATWG Encoding Standard.