Unicode-Normalisierer

Unicode bietet für manche Zeichen mehr als eine Schreibweise. Der Buchstabe é kann ein einzelner Codepunkt sein, U+00E9, oder ein gewöhnliches e, gefolgt von einem kombinierenden Akut, U+0065 U+0301. Beide sehen auf dem Bildschirm gleich aus, drucken gleich, und als Zeichenfolgen sind sie verschieden: Sie haben unterschiedliche Längen, unterschiedliche UTF-8-Bytes, und 'é' === 'e\u0301' ist false.

Das ist keine Kuriosität, sondern eine Fehlerklasse. Ob Sie die eine oder die andere Form bekommen, hängt vom Tastaturlayout, dem Betriebssystem, der Eingabemethode und davon ab, ob der Text je über eine Textverarbeitung kopiert wurde. Eine Passwortprüfung, ein eindeutiger Datenbankindex, eine Sperrliste oder ein Cache-Schlüssel, der Zeichenfolgen byteweise vergleicht, behandelt die beiden Schreibweisen als zwei verschiedene Werte — so kann ein Nutzer ein Passwort auf einem Gerät setzen und sich auf einem anderen nicht anmelden, und dasselbe Wort kann in einer Liste bereits vergebener Namen zweimal erscheinen.

Die Trennung besteht, weil zwei verschiedene Ziele bedient werden. Zusammensetzen und Zerlegen von Text ist eine kanonische Änderung: Das Ergebnis bedeutet dasselbe, und bei den ersten beiden Formen geht nichts verloren. Das Auflösen von Ligaturen, Hochstellungen, eingekreisten Buchstaben und Vollbreitenformen ist dagegen eine Kompatibilitäts-Änderung: Sie erfolgt zur Erleichterung des Abgleichs, und sie zerstört tatsächlich die Unterscheidung zwischen zwei Zeichenfolgen, die Unicode als verschieden ausweist. Die vier Formen sind alle Kombinationen der beiden Entscheidungen.

Die Tabelle oben ist die Fallliste der Datendatei dieser Seite, geprüft gegen die eigene String.prototype.normalize der Plattform, und der Selbsttest prüft jede Zeile davon vor Ihren Augen erneut. Lesen Sie die ersten beiden Zeilen zusammen: Es ist derselbe Text, zweimal geschrieben, und nach der Normalisierung sind es dieselbe Zeichenfolge.

Das sind die Zeichenfolgen, die die Schaltfläche Beispiel durchgeht; die Seite normalisiert sie live, statt sie als vorgegebene Antworten einzutippen. Jede wurde gewählt, weil eine Form etwas Sichtbares mit ihr macht.

NFKC und NFKD sind verlustbehaftet, und der Verlust ist beabsichtigt. Sie beantworten die Frage „ist das dasselbe Wort“, nicht die Frage „ist das dieselbe Zeichenfolge“. Daraus folgen drei Konsequenzen, die im Produktivcode leicht falsch gehandhabt werden:

• Speichern Sie niemals ein Passwort, ein Token oder eine Signatur in einer Kompatibilitätsform. Zwei verschiedene Eingaben würden auf denselben gespeicherten Wert zusammenfallen, wodurch eine Längen- oder Zeichenprüfung schwächer wird. Normalisieren Sie Passwörter mit NFC (oder gar nicht) und vergleichen Sie sie byteweise, nachdem auf beiden Seiten genau dasselbe geschehen ist.
• Eine Kompatibilitätsfaltung kann ein Zeichen in mehrere verwandeln. Die Ligatur fi ist ein Codepunkt, der zu zwei Buchstaben wird, daher kann ein Feld, das vor der Normalisierung auf Länge geprüft wurde, danach länger sein. Erst normalisieren, dann validieren, dann speichern.
• NFKC entfernt nicht alles Unsichtbare. Ein Variationsselektor übersteht NFKC und NFKD, ebenso ein Nullbreiten-Verbinder. Deshalb hat diese Seite einen Prüfmodus: Normalisierung beantwortet eine Frage zur Form und Identität eines Zeichens, der Scanner beantwortet die Frage, ob überhaupt etwas da ist.

Die Normalisierung verändert die zweite dieser Zahlen und lässt die erste meist in Ruhe. Die drei Zahlen sind alle „die Länge des Textes“ und alle verschieden, weshalb ein Formularfeld mit einer Begrenzung auf 20 Zeichen zu einer Zeichenfolge gehören kann, die 20 Codepunkte, 30 UTF-16-Einheiten und 47 Bytes lang ist.

Die Zahl in der Graphemspalte ist das, was ein Mensch zählt. Die Lücke zwischen ihr und der Codepunktanzahl ist genau der Gegenstand des Scanners: Ein Name aus 12 Codepunkten kann als 12 Buchstaben erscheinen, als 3 Buchstaben mit 9 unsichtbaren Zeichen dazwischen oder als ein einziges Emoji.

Ein Nullbreiten-Leerzeichen belegt keine Breite, verändert kein Schriftbild und ist ein echtes Zeichen mit einem echten Codepunkt. Zwei Bezeichner, die auf dem Bildschirm identisch aussehen, können sich durch eines davon unterscheiden — so kann ein Name in einer Liste ein Hochstapler sein, der anders sortiert, sucht und authentifiziert als der Name daneben. Dasselbe gilt für die bidirektionalen Steuerzeichen, die eine Zeichenfolge in einer anderen Reihenfolge darstellen können, als sie geschrieben wurde — ein Trick, mit dem Dateinamen getarnt wurden.

Der Scanner im dritten Modus listet jedes dieser Zeichen mit seiner Position auf: Nullbreiten- und Verbindungszeichen, bidirektionale Steuerzeichen, Variationsselektoren, ungewöhnliche Leerzeichen, C0- und C1-Steuerzeichen, Codepunkte für private Nutzung und einen Ersatz, der keine Hälfte eines gültigen Paares ist und daher gar kein Zeichen ist. Die Klassentabelle weiter oben auf dieser Seite beschreibt, was jede Klasse bewirkt, und die Schaltfläche zum Entfernen löscht eine Kopie dieser Zeichen, ohne Ihre Eingabe zu berühren.

• Zwei Zeichenfolgen vergleichen, ohne sie zu normalisieren. 'é' === 'e\u0301' ist falsch. Normalisieren Sie beide Seiten mit derselben Form, bevor Sie vergleichen, und verwenden Sie dieselbe Form im Index, gegen den Sie vergleichen.
• Nur auf einer Seite normalisieren. Eine Suche, die die Anfrage normalisiert, den gespeicherten Wert aber nicht, findet nichts und sieht wie ein Datenproblem aus, nicht wie ein Normalisierungsproblem.
• Ein Formular mit einer Kompatibilitätsform gestalten und es als NFC-sicher bezeichnen. NFKC auf ein Passwort angewendet verkürzt den Raum möglicher Passwörter und führt Eingaben zusammen, die verschieden sein sollten.
• Die Annahme, eine Normalisierungsform behebe eine Fälschung. Sie entfernt weder einen Nullbreiten-Verbinder noch einen Variationsselektor oder ein Homoglyph — ein kyrillisches а und ein lateinisches a sind verschiedene Codepunkte, die NFC unberührt lässt.
• Einer Zeichenanzahl vertrauen. Die Anzahl, die ein Nutzer sieht, die Anzahl, die eine Datenbankspalte erzwingt, und die Anzahl, die ein Byte-Limit erzwingt, sind drei verschiedene Zahlen, und die Zeilen oben zeigen, wie weit sie auseinanderliegen können.
• Die Annahme, dass Sie NFC erhalten. Text, der aus einer Eingabemethode, einer Datei oder einem anderen System kommt, liegt in der Form vor, die dieses System erzeugt hat. Diese Seite startet mit NFC, weil das die Form ist, die für das Web vorgesehen ist — nicht weil das Ihre Eingabe ist.

„Warum sind diese beiden Zeichenfolgen nicht gleich, obwohl sie gleich aussehen?“

Weil eines davon mit einem zusammengesetzten Zeichen geschrieben ist und das andere mit einem Basisbuchstaben plus kombinierendem Zeichen oder weil eines davon ein Zeichen enthält, das gar nichts zeichnet. Wechseln Sie in den Vergleichsmodus und geben Sie je eine Zeichenfolge in jedes Feld: Die Seite meldet die erste Position, an der sich die normalisierten Zeichenfolgen unterscheiden, und was an dieser Position in jeder von ihnen steht.

„Welche Form sollte ich in einer Anwendung verwenden?“

NFC für alles, was ein Mensch liest, anzeigt, speichert und durchsucht — die Form, die das W3C für das Web empfiehlt. NFD ist die richtige Antwort, wenn der Code dahinter Basisbuchstaben und getrennte Zeichen erwartet, was in der Textverarbeitung und auf manchen Dateisystemen unter macOS üblich ist. Verwenden Sie NFKC oder NFKD nur dort, wo Sie abgleichen statt speichern: Suchindizes, Stichwortfilter, Dublettenerkennung.

„Ist eine bereits normalisierte Zeichenfolge noch normalisiert, nachdem ich etwas angehängt habe?“

Nicht unbedingt. Normalisierung bleibt beim Aneinanderhängen nicht erhalten: Das Verbinden zweier NFC-Zeichenfolgen kann eine Folge erzeugen, die NFC anders geschrieben hätte, weil ein kombinierendes Zeichen am Anfang der zweiten Zeichenfolge sich an das Zeichen am Ende der ersten anhängen kann. Normalisieren Sie nach dem Zusammensetzen, nicht nur davor.

„Entfernt die Normalisierung die unsichtbaren Zeichen?“

Nein, mit einer teilweisen Ausnahme: NFKC und NFKD ersetzen das geschützte Leerzeichen durch ein gewöhnliches Leerzeichen, was ein sichtbares Ergebnis einer Kompatibilitätsfaltung ist. Alles andere — Nullbreiten-Leerzeichen, Verbinder, bidirektionale Steuerzeichen, Variationsselektoren — bleibt in allen vier Formen unberührt. Dafür gibt es den dritten Modus.

„Warum ändert sich die Byteanzahl, obwohl sich die Zeichenanzahl nicht ändert?“

Weil die beiden Formen aus verschiedenen Codepunkten aufgebaut sind, die in UTF-8 unterschiedlich viele Bytes kosten. Ein vorkomponiertes é sind zwei Bytes; das zerlegte Paar sind drei. Die Zählertabelle oben gibt alle vier Zahlen für die Eingabe und für jede Form nebeneinander aus, sodass der Unterschied sichtbar und nicht nur beschrieben ist.

„Woher weiß ich, dass die Ergebnisse auf dieser Seite richtig sind?“

Drücken Sie Selbsttest. Er normalisiert jeden Fall in der Datendatei dieser Seite, prüft die vier Formen gegeneinander auf die dokumentierten Beziehungen (NFC ist idempotent, NFD einer NFC-Zeichenfolge ist dasselbe wie NFD des Originals usw.), schickt jedes Zeichen aus den Tabellen für unsichtbare und Steuerzeichen durch den Scanner und zählt die Graphemfälle gegen Intl.Segmenter.

Die vier Formen und ihre Definitionen stammen aus dem Unicode-Standard, Anhang 15 (Unicode Normalization Forms). Die Codepunkte, die als Zerlegungsbeispiele dienen, sind diejenigen, die der Standard vorgibt; diese Seite implementiert die Zerlegungstabellen selbst nicht — sie ruft die eigene String.prototype.normalize des Browsers auf, dieselbe Implementierung, die die Plattform für Texteingabe, Sortierung und Vergleich nutzt. Was hier gemeldet wird, ist also, was der Rest des Systems mit derselben Zeichenfolge tut. Graphem-Cluster stammen aus Intl.Segmenter, wo der Browser es hat, und sonst aus einer dokumentierten Näherung.

Der Seitentext wurde für diese Website geschrieben. Jedes durchgerechnete Beispiel auf dieser Seite wurde vom eigenen Code der Seite erzeugt und dann gegen die aufgezeichnete Fallliste der Datendatei geprüft, die wiederum gegen die NormalizationTest-Daten von Unicode für dieselben Zeichen geprüft wurde. Die Tabellen für unsichtbare und gefährliche Zeichen sind eine kuratierte Auswahl für gut lesbare Warnungen, nicht das vollständige Unicode-Sicherheitsprofil (UTS #39), und die Seite sagt das ausdrücklich, statt eine Vollständigkeit vorzutäuschen, die sie nicht hat.