Unicode

Unicode ist der universelle Zeichenkodierungsstandard, der vom Unicode-Konsortium gepflegt wird. Er weist jedem Zeichen jedes Schriftsystems, das formal vorgeschlagen und angenommen wurde, eine eindeutige Zahl (einen „Codepunkt“) zu — derzeit rund 150.000 Zeichen über 161 Schriften hinweg, einschließlich moderner Sprachen, historischer Schriften, mathematischer Symbole, technischer Notation und Emoji.

Codepunkte werden als U+XXXX geschrieben (4–6 Hexadezimalziffern). Der Buchstabe A ist U+0041; das türkische punktlose i ist U+0131; das Raketen-Emoji ist U+1F680.

Unicode selbst legt nicht fest, wie Codepunkte in Bytes serialisiert werden — das ist die Aufgabe der Kodierungen. Die drei wichtigsten Kodierungen:

• UTF-8 — variable Breite, 1–4 Byte pro Codepunkt. ASCII-kompatibel. Die vorherrschende Web-Kodierung.
• UTF-16 — 2 oder 4 Byte pro Codepunkt. Intern von Java, JavaScript-Strings und Windows genutzt.
• UTF-32 — genau 4 Byte pro Codepunkt. Einfach, aber verschwenderisch; selten zur Speicherung genutzt.

Die Tools von Convertitive verarbeiten vollständiges Unicode dort, wo sie es sollten — der Base64-Encoder verarbeitet UTF-8 korrekt, der Wortzähler zählt Codepunkte und Grapheme, der Groß-/Kleinschreibungs-Konverter berücksichtigt türkische Besonderheiten (das Problem mit punktiertem vs. punktlosem I).

Codepunkt ≠ Zeichen ≠ Graphem — die Unterscheidung, die jede String-Bibliothek bricht: Der Buchstabe „é“ lässt sich in Unicode auf zwei Arten darstellen — als einzelner Codepunkt U+00E9 (vorkomponiert) oder als U+0065 (e) gefolgt von U+0301 (kombinierender Akut). Beide werden identisch dargestellt; beide zählen für einen Menschen als „ein Zeichen“; einer ist ein Codepunkt, der andere sind zwei. Emoji sind schlimmer: 👨‍👩‍👧 (Familie) ist eine ZWJ-Sequenz aus sieben Codepunkten, aber ein Graphem. Längenangaben in JavaScript (str.length) liefern UTF-16-Codeeinheiten zurück, keine Grapheme — das Familien-Emoji hat eine String-Länge von 11. Verwenden Sie Intl.Segmenter (moderne Browser, Node 16+) für korrekte Graphem-Zählungen.

Unicode-Normalisierungsformen — wenn Text nicht mit sich selbst übereinstimmt: Zwei optisch identische Strings können aufgrund der oben genannten Trennung von vorkomponiert vs. zerlegt unterschiedliche Byte-Darstellungen haben. Der Unicode-Standard definiert vier Normalisierungsformen (NFC, NFD, NFKC, NFKD), die dies kanonisieren. NFC (komponiert) ist der Standard für HTML und die meisten Dateisysteme; NFD (zerlegt) ist der Standard von macOS HFS+ und der Grund, warum Dateipfade manchmal identisch aussehen, aber systemübergreifend ungleich verglichen werden. Datenbank-String-Gleichheit und Suchindex-Abfragen sollten beim Schreiben auf NFC normalisieren, um den Fehler „identische Abfrage trifft nicht zu“ zu vermeiden. Quelle: The Unicode Standard, Version 15.

Durchgerechnetes Beispiel

Nehmen Sie den String „café“. Zwei gleichermaßen gültige Unicode-Darstellungen: NFC = U+0063 U+0061 U+0066 U+00E9 (4 Codepunkte), NFD = U+0063 U+0061 U+0066 U+0065 U+0301 (5 Codepunkte, „e“ + kombinierender Akut). Beide werden identisch dargestellt. Betrachten Sie nun, wie jede in unterschiedlichen Zählungen aussieht: In UTF-8 ist NFC 5 Byte (63 61 66 C3 A9); NFD ist 6 Byte (63 61 66 65 CC 81). In JavaScript: "café".length = 4 für NFC, 5 für NFD. Vergleichen Sie die Gleichheit ohne Normalisierung: nfc === nfd ist false. Lassen Sie beide zuerst durch String.prototype.normalize("NFC") laufen: Sie werden identisch. Fehler behoben. Genau dies ist die Ursache von „Ich habe nach José gesucht und der Datensatz existiert, kommt aber nicht zurück“ in Datenbanken, die von Nutzern eingereichte Namen aus gemischten Mac- und Windows-Clients speichern.

Wann und warum es zählt

Jede internationalisierte Anwendung stößt irgendwann auf Unicode-Grenzfälle: Benutzernamen mit kombinierenden Zeichen, zwischen macOS (NFD) und Linux (NFC) kopierte Dateipfade, Vietnamesisch mit gestapelten Diakritika, türkische Schreibregeln (Kleinbuchstabe von „I“ ist „ı“, nicht „i“ — das „Türkisch-I-Problem“ verursachte 2018 echte iOS-Abstürze), arabische und hebräische Rechts-nach-links-Darstellung und ZWJ-basierte Emoji, deren Codepunkt-Bestandteile sich schneller weiterentwickeln als die Schriftarten-Updates Ihres Telefons. Die defensiven Regeln: bei der Eingabe auf NFC normalisieren, Intl.Collator für locale-bewusstes Sortieren verwenden (nicht die Codepunkt-Sortierung von Array.sort), Intl.Segmenter für graphembewusstes Kürzen einsetzen und CLDR (die Locale-Datenbank von Unicode) das locale-spezifische Verhalten steuern lassen, statt Regeln fest zu verdrahten. Quelle: Unicode Technical Report #15 — Normalization Forms.