573 Taiwaner tragen einen Nachnamen, den Unicode nicht kodieren kann

Das taiwanische Innenministerium veröffentlicht ein Nachnamenregister ohne Datenschutzschwelle. Jeder Nachname ist mit seiner exakten Trägerzahl aufgeführt, bis hinunter zu den 643 Nachnamen, die von genau einer Person unter 23,4 Millionen getragen werden. Es ist einer der vollständigsten nationalen Namensdatensätze, die es gibt.

Liest man es bis zum Ende, stößt man auf Zeilen, in denen die Nachnamenspalte kein Nachname ist. Es ist ein Codepunkt, den Unicode nie irgendetwas zugewiesen hat.

Es gibt 23 solcher Zeilen, die 573 Menschen tragen. Diese 573 Bürger haben einen legalen, registrierten, staatlich anerkannten Nachnamen, den keine standardkonforme Software anzeigen, übertragen oder auf den sie sich einigen kann.

Diese Seite handelt von diesen 23 Zeilen und von einer zweiten, leiseren Klasse von 14 Zeilen in unserem eigenen Korpus, die in Ordnung aussehen, bis etwas sie normalisiert.

Was wir gemessen haben

Geprüft gegen tw_surname_112.csv (die Open-Data-Veröffentlichung des Ministeriums, Referenzdatum 30. Juni 2023) am 21. Juli 2026. Zweiundzwanzig verschiedene Codepunkte über dreiundzwanzig Einträge, weil U+FD13A in zwei verschiedenen zusammengesetzten Nachnamen verwendet wird.

Was ein Private-Use-Area-Codepunkt ist

Unicode reserviert drei Regionen, in denen es verspricht, nie ein Zeichen zuzuweisen:

Das sind keine „Zeichen, zu denen Unicode noch nicht gekommen ist". Es sind Codepunkte, die Unicode dauerhaft zu definieren abgelehnt hat, damit private Parteien untereinander vereinbaren können, was sie bedeuten. Das Apple-Logo liegt in Apples Schriften bei U+F8FF und ist überall sonst ein leeres Kästchen. Das ist kein Fehler; das ist der gesamte Entwurf.

Die Folge ist, dass ein PUA-Codepunkt keine Bedeutung außerhalb des Systems hat, das ihn zugewiesen hat. Er hat keinen Namen, keine verlässlichen Zeicheneigenschaften, keine kanonische Form und keine Garantie, dass die nächste Version irgendeiner Software ihn gleich darstellt. Zwei Systeme können beide völlig korrekt sein und sich vollständig darüber uneinig sein, was U+FBF33 ist.

Alle 23 taiwanischen Einträge liegen in Ebene 15, zwischen U+F9000 und U+FFFEE.

Warum ein staatliches Register sie enthält

Die taiwanische Haushaltsregistrierung (戶籍) erfasst die Schriftform eines Namens, nicht seine Aussprache. Ist der Nachname einer Familie ein seltenes Zeichen, das in Registern der Qing-Zeit auftauchte und nie in einen modernen Zeichenstandard gelangte, muss das Haushaltsregistrierungssystem ihn trotzdem speichern — der Bürger existiert, der Name steht auf seinem Personalausweis, und „wir können ihn nicht kodieren" ist keine administrative Option.

Also tat das Ministerium, was jedes ostasiatische Register seit den 1980er-Jahren getan hat: Es vergab interne Codepunkte für die Zeichen, die es brauchte, und legte sie in den Raum, den Unicode genau dafür vorgesehen hat. Japans 住基ネット, Chinas benutzerdefinierter GB-18030-Bereich und Hongkongs Ergänzungssätze vor HKSCS taten alle dasselbe. Das Register ist nicht kaputt. Es ist Unicode voraus, und es hat eine gesetzliche Pflicht, nicht zu warten.

Die Zählungen sind klein, aber nicht verschwindend:

Fünf der 23 sind zusammengesetzte Nachnamen, die ein gewöhnliches Ideogramm mit einem privaten mischen — was sehenswert ist, weil es die Vorstellung widerlegt, dass dies Müllzeilen seien:

Die letzten beiden sind erkennbar Nachnamen japanischen Musters (飯?谷, ?原), die von je einer Person getragen werden — genau die Art von Rückstand, die ein Haushaltsregister ansammelt und ein Zeichenstandard nicht.

Der Nachname mit 179 Trägern ist keine Kuriosität. Im Register läge er nach Trägerzahl auf Rang 458. Das setzt ihn knapp unter 諸葛 (180 Träger — der Nachname von Zhuge Liang, den jeder Leser der Drei Reiche kennt) und bequem über 皇甫 (115), 尉遲 (63) und 司馬 (49). Der häufigste Nachname, den Unicode nicht kodieren kann, ist häufiger als etliche Nachnamen, die jeder benennen kann.

Wie es in einem Browser aussieht

Nichts. Ein PUA-Codepunkt ohne Schriftabdeckung wird als Ersatzglyphe dargestellt — das notdef-Kästchen, allgemein „Tofu" (豆腐) genannt, manchmal mit den darin abgedruckten Hexadezimalziffern. Welches der beiden Sie sehen, hängt vom Font-Stack ab, nicht von den Daten.

Es gibt einen schlimmeren Fall als ein leeres Kästchen, und er ist der Grund, warum wir diese Zeilen überhaupt nicht ausliefern. Weil die PUA privat ist, kann irgendeine Schrift auf irgendeiner Maschine dort durchaus eine Glyphe haben — eine andere. Segoe UI Emoji, Apples Systemschriften, eine Unternehmens-Icon-Schrift, eine alte Big5-Schrift eines taiwanischen Anbieters und der benutzerdefinierte Zeichenbereich einer chinesischen IME beanspruchen alle überlappende Teile der PUA. Ein als U+F9000 gespeicherter Nachname kann auf einer Maschine als Kästchen, auf einer zweiten als seltenes Ideogramm und auf einer dritten als Dingbat erscheinen. Die Bytes sind identisch. Der Name ist es nicht.

Das ist der eigentliche Fehlermodus: nicht „unlesbar", sondern stillschweigend als etwas anderes lesbar.

Was wir mit ihnen tun

Wir schließen alle 23 aus. Unser taiwanisches Korpus trägt 2.707 der 2.731 Nachnamen des Registers, und die 24 ausgeschlossenen Zeilen sind diese 23 plus der Sammeleimer 其他 („andere", 5.174 Menschen), der eine statistische Kategorie und kein Name ist.

Gemessen an der ausgelieferten Datei:

Die Regel ist eng und wert, präzise formuliert zu werden: Wir löschen keine seltenen Nachnamen, wir löschen Nachnamen, die wir nicht darstellen können. 慕容 (1 Träger), 呼延 (1), 公羊 (1) und 澹臺 (2) sind alle in der Datei. Seltenheit ist nie ein Grund, eine Zeile zu verwerfen; eine Zeile, die auf dem Bildschirm des Lesers ein leeres Kästchen erzeugt, schon.

Es gibt hier keine ehrliche Alternative. Wir können kein ähnlich aussehendes Zeichen einsetzen, denn „ähnlich aussehend" ist ein Urteil über eine Glyphe, die wir nie gesehen haben. Wir können nicht transliterieren, weil es nichts gibt, wovon transliteriert werden könnte. Wir können keinen Platzhalter erfinden, denn eine generierte Identität, die U+F9000 trägt, ist schlimmer als eine, die einen echten Nachnamen trägt. Die 573 Menschen liegen schlicht außerhalb dessen, was ein textbasiertes System darstellen kann, und die korrekte Antwort ist, das zu sagen, statt zu approximieren.

Die zweite Klasse: 14 Nachnamen, die überleben, bis etwas sie normalisiert

Null PUA-Codepunkte erreichen unsere ausgelieferte Datei. Aber die Datei enthält 1.780 verschiedene Codepunkte, und sie liegen nicht alle in dem Block, den man erwarten würde:

Die 14 im CJK Compatibility Ideographs Supplement (U+2F800–U+2FA1F) sind die interessanten. Dieser Block existiert allein zur Rundlauf-Kompatibilität mit älteren Standards, und jedes Zeichen darin hat eine kanonische Singleton-Zerlegung: Der Standard sagt, es zerlegt sich in genau ein anderes Zeichen, und der Kompositionsschritt setzt es nie wieder zusammen.

Die praktische Übersetzung: NFC, NFD, NFKC und NFKD verwandeln diese Zeichen allesamt in ein gewöhnliches vereinheitlichtes Ideogramm. Nicht „können" — der Unicode-Standard verlangt es.

Bei allen 14 ist der vereinheitlichte Zwilling bereits eine eigene Zeile in derselben Datei, mit seiner eigenen Trägerzahl:

Die beiden Spalten sehen identisch aus, weil sie auf Ihrem Bildschirm identisch sind — dieselbe Glyphe, dieselbe Form, ein anderer Codepunkt. 284 Träger sitzen auf der linken Seite, 0,0012 % des Korpusgewichts.

Das sind keine Defekte. Das Ministerium führt sie als getrennte Zeilen, weil sie für die Haushaltsregistrierung getrennte Schriftformen sind, und unsere Datei spiegelt das Register. Aber sie sind eine geladene Waffe, die auf den Konsumenten gerichtet ist.

Warum die Normalisierung der gefährliche Teil ist, nicht die Kodierung

Ein nicht kodierbarer Nachname scheitert laut. Sie sehen ein Kästchen, Sie melden einen Fehler. Ein Kompatibilitäts-Ideogramm scheitert still und nur in einigen Schichten Ihres Stacks.

Betrachten Sie einen einzelnen Datensatz, der durch eine gewöhnliche Webanwendung wandert:

1. Die Datenbank hält 周 U+2F83F (25 Träger) und 周 U+5468 (282.185 Träger) als zwei Zeilen.
2. Ein JavaScript-Frontend führt name.normalize() aus, bevor es eine Suchanfrage sendet — die aktuelle, empfohlene Praxis. U+2F83F wird zu U+5468. Zwei Nachnamen sind jetzt einer.
3. Ein PHP-Backend ohne die intl-Erweiterung kann überhaupt nicht normalisieren: Normalizer existiert nicht. (Unser lokaler PHP-8.5.8-Build ist genau dieser Fall — wir haben es geprüft.) Also bleibt derselbe String, der in die andere Richtung wandert, U+2F83F.
4. Ein Suchindex mit einem ICU-Normalisierungsfilter faltet sie zusammen; eine LIKE-Abfrage nicht.
5. Ein macOS-Client, der den Namen in einen Dateinamen schreibt, erhält NFD vom Dateisystem; ein Linux-Client nicht.

Nichts in dieser Kette ist falsch. Jede Komponente verhält sich wie dokumentiert. Der Datensatz endet dennoch mit zwei verschiedenen Identitäten, je nachdem, durch welche Tür er kam.

Zwei weitere konkrete Symptome:

Länge ist nicht Länge. 周 U+2F83F ist 4 Bytes in UTF-8 und 2 Codeeinheiten in UTF-16; 周 U+5468 ist 3 Bytes und 1 Codeeinheit. Also gibt LENGTH() in MySQL 4 gegen 3 zurück, JavaScripts .length gibt 2 gegen 1 zurück, und eine VARCHAR(1)-Spalte wird eines der beiden ablehnen. Ein „Ein-Zeichen"-Nachname besteht eine Ein-Zeichen-Validierung nicht.

Eindeutige Indizes gehen in beide Richtungen, und Sie können nicht erkennen, welche. Ob utf8mb4_unicode_ci diese als gleich behandelt, hängt von der UCA-Version ab, die Ihr Server implementiert, und davon, ob die Kollation überhaupt normalisiert — und wir haben für diese Seite absichtlich keine laufende MariaDB getestet, also werden wir Ihnen nicht sagen, was Ihre tut. Was wir Ihnen sagen können: Die Antwort ist nicht offensichtlich, sie kann sich bei einem Server-Upgrade ändern, und wenn Ihre Eindeutigkeitsbedingung auf einer Namensspalte nach einem Minor-Version-Sprung still ein Insert abzulehnen beginnt, gehört das zu dieser Familie von Gründen.

Die Zeile, die den Punkt am besten macht, ist 丸: U+2F801 hat einen Träger und U+4E38 hat einen Träger. Normalisieren Sie, und Sie haben einen Nachnamen mit zwei Trägern und keinen Beleg dafür, dass zwei getrennte Haushalte zwei verschiedene Glyphen registrierten. Die Arithmetik bleibt erhalten. Die Tatsache ist weg.

Was zu tun ist

Entscheiden Sie ein für alle Mal, wo die Normalisierung geschieht, und schreiben Sie es auf. Nicht „wir verwenden NFC" — welche Schicht wendet sie an, beim Schreiben oder beim Lesen, und was die Speicherform ist. Ein System, in dem drei Schichten jeweils unabhängig normalisieren, ist ein System, in dem die Speicherform das ist, was zufällig der letzte Schreiber war.

Speichern Sie die registrierte Form; leiten Sie die Suchform ab. Dieselbe Gestalt wie das Sortierproblem bei europäischen Nachnamen mit Präfix: Anzeige und Abgleich wollen zwei verschiedene Strings. Behalten Sie die Bytefolge, die das Register Ihnen gab, in einer Spalte und bauen Sie in einer anderen einen explizit normalisierten Schlüssel für Nachschlag, Joins und Eindeutigkeit. Machen Sie die normalisierte Form nicht zur einzigen Form.

Normalisieren Sie Namen nicht als Aufräumschritt. NFC auf benutzergelieferten Text am Rand Ihrer API ist vernünftig; NFC über eine Namensspalte in einer Migration ist Datenverlust mit einer Commit-Nachricht. Die 14 Zeilen oben sind 284 Menschen, deren registrierter Nachname sich von einem anderen Nachnamen nur im Codepunkt unterscheidet, und ein einziges UPDATE ... SET name = NORMALIZE(name) führt sie ohne Fehler und ohne Weg zurück zusammen.

Validieren Sie auf Darstellbarkeit, nicht auf Plausibilität. Wenn Sie Namenseingaben überhaupt filtern, ist eine vernünftige Regel „Codepunkte in den Private Use Areas ablehnen" — nicht weil sie ungültig sind, sondern weil Sie nicht versprechen können, dass der Empfänger sieht, was der Absender getippt hat. Diese Regel ist eng, vertretbar und lehnt nicht versehentlich 慕容 oder 澹臺 ab.

Erwarten Sie, dass das Register recht hat und der Standard hinterher ist. Jedes Mal, wenn wir einen Namen gefunden haben, den unser Werkzeug nicht verarbeiten konnte, war das Werkzeug das Problem. U+FBF33 sind 179 lebende Menschen; dass ISO 10646 keinen Codepunkt für ihren Nachnamen hat, ist eine Tatsache über ISO 10646.

Bekannte Einschränkungen

• Wir können Ihnen nicht sagen, wie die 23 Zeichen aussehen. Wir haben ihre Codepunkte, nicht ihre Glyphen. Das Ministerium veröffentlicht mit dem offenen Datensatz keine Glyphenzuordnung, also können wir berichten, dass diese Menschen existieren, aber nicht, wie ihr Nachname aussieht.
• Wir haben das Kollationsverhalten nicht an einer laufenden Datenbank getestet. Die Aussage auf dieser Seite über MariaDB ist bewusst ein Eingeständnis von Unsicherheit, kein Befund.
• Die 14 Kompat-Zeilen werden absichtlich unzusammengeführt ausgeliefert. Sie zusammenzuführen würde 14 Trägerzahlen ändern und eine Unterscheidung zerstören, die das Register macht. Unsere Position ist, dass ein Konsument, der sie zusammengeführt braucht, sie wissentlich zusammenführen sollte, in seiner eigenen Schlüsselspalte.
• Der Registerabgleich selbst ist unerklärt. Das Ministerium gibt andernorts an, dass Taiwan 1.785 Nachnamen hat, während der offene Datensatz 2.731 Zeilen trägt. Wir haben eine plausible Lesart der Lücke und keine Bestätigung dafür.

Daten mit Stand 2026-07-21

Referenzdatum des Registers 30. Juni 2023 (民國112年6月30日), veröffentlicht von 內政部戶政司 unter der Government Open Data Licence v1. Alle Zahlen auf dieser Seite wurden am 21. Juli 2026 aus dem rohen CSV und aus unserer ausgelieferten Gewichtsdatei neu berechnet; die Männer- und Frauendateien sind byteweise identisch, weil taiwanische Nachnamen nicht nach Geschlecht flektieren.

Quellen

• data.gov.tw dataset 126774 — 姓氏排名與人數按三階段年齡分
• Unicode Standard Annex #15: Unicode Normalization Forms
• Unicode Standard, Chapter 23.5: Private-Use Characters
• CJK Compatibility Ideographs Supplement (U+2F800–U+2FA1F) code chart