573 Taïwanais portent un nom de famille qu'Unicode ne peut pas encoder

Le ministère de l'Intérieur taïwanais publie un registre des noms de famille sans seuil de confidentialité. Chaque nom de famille y figure avec son effectif exact de porteurs, jusqu'aux 643 noms de famille portés par exactement une personne sur 23,4 millions. C'est l'un des jeux de données nationaux sur les noms les plus complets qui existent.

Lisez-le jusqu'en bas et vous tombez sur des lignes où la colonne du nom de famille ne contient pas un nom de famille. C'est un point de code qu'Unicode n'a jamais assigné à quoi que ce soit.

Il existe 23 lignes de ce type, qui totalisent 573 personnes. Ces 573 citoyens possèdent un nom de famille légal, enregistré, reconnu par l'État, qu'aucun logiciel conforme aux normes ne peut afficher ni transmettre, et sur lequel deux logiciels ne peuvent pas s'accorder.

Cette page traite de ces 23 lignes, ainsi que d'une seconde classe, plus discrète, de 14 lignes de notre propre corpus qui semblent correctes jusqu'à ce que quelque chose les normalise.

Ce que nous avons mesuré

Vérifié par rapport à tw_surname_112.csv (la publication en données ouvertes du ministère, date de référence du 30 juin 2023) le 21 juillet 2026. Vingt-deux points de code distincts répartis sur vingt-trois entrées, parce que U+FD13A est utilisé dans deux noms de famille composés différents.

Ce qu'est un point de code de la Private Use Area

Unicode réserve trois régions où il promet de ne jamais assigner de caractère :

Ce ne sont pas des « caractères auxquels Unicode n'a pas encore eu le temps de s'attaquer ». Ce sont des points de code qu'Unicode a définitivement refusé de définir, afin que des parties privées puissent convenir entre elles de ce qu'ils signifient. Le logo Apple se trouve en U+F8FF dans les polices d'Apple et n'est qu'une case vide partout ailleurs. Ce n'est pas un défaut ; c'est tout le principe.

La conséquence, c'est qu'un point de code PUA n'a aucune signification en dehors du système qui la lui a attribuée. Il n'a pas de nom, pas de propriétés de caractère sur lesquelles il vaille la peine de s'appuyer, pas de forme canonique, et aucune garantie que la prochaine version de quoi que ce soit l'affichera de la même façon. Deux systèmes peuvent être tous deux parfaitement corrects et être en désaccord complet sur ce qu'est U+FBF33.

Les 23 entrées taïwanaises se situent toutes dans le plan 15, entre U+F9000 et U+FFFEE.

Pourquoi un registre d'État en contient

L'enregistrement des foyers taïwanais (戶籍) consigne la forme écrite d'un nom, pas sa prononciation. Si une famille a pour nom de famille un caractère rare, apparu dans les registres de l'époque Qing et jamais entré dans aucune norme de caractères moderne, le système d'enregistrement des foyers doit tout de même le stocker — le citoyen existe, le nom figure sur sa carte d'identité, et « nous ne pouvons pas l'encoder » n'est pas une option administrative.

Le ministère a donc fait ce que fait tout registre d'Asie de l'Est depuis les années 1980 : il a alloué des points de code internes pour les caractères dont il avait besoin et les a placés dans l'espace qu'Unicode a réservé précisément à cela. Le 住基ネット japonais, la zone définie par l'utilisateur de la norme chinoise GB 18030 et les jeux supplémentaires hongkongais antérieurs au HKSCS ont tous fait la même chose. Le registre n'est pas défectueux. Il est en avance sur Unicode, et il a l'obligation légale de ne pas attendre.

Les effectifs sont faibles, mais pas négligeables :

Cinq des 23 sont des noms de famille composés qui mêlent un idéogramme ordinaire à un idéogramme privé, ce qui vaut la peine d'être vu parce que cela réfute l'idée qu'il s'agirait de lignes parasites :

Les deux derniers sont reconnaissables comme des noms de famille de type japonais (飯?谷, ?原), portés par une personne chacun — exactement le genre de résidu qu'un registre des foyers accumule et qu'une norme de caractères n'accumule pas.

Le nom de famille à 179 porteurs n'est pas une curiosité. Dans le registre, il occuperait le rang 458 par effectif de porteurs. Cela le place juste en dessous de 諸葛 (180 porteurs — le nom de famille de Zhuge Liang, que connaît tout lecteur des Trois Royaumes) et nettement au-dessus de 皇甫 (115), 尉遲 (63) et 司馬 (49). Le nom de famille le plus fréquent qu'Unicode ne peut pas encoder est plus fréquent que plusieurs noms de famille que tout le monde saurait citer.

À quoi cela ressemble dans un navigateur

À rien. Un point de code PUA qu'aucune police ne couvre s'affiche sous la forme du glyphe de remplacement — la case notdef, universellement appelée « tofu » (豆腐), parfois avec les chiffres hexadécimaux imprimés à l'intérieur. Lequel des deux vous voyez dépend de la pile de polices, pas des données.

Il existe un cas pire qu'une case vide, et c'est la raison pour laquelle nous ne livrons pas ces lignes du tout. Parce que la PUA est privée, telle police sur telle machine peut fort bien y avoir un glyphe — un autre. Segoe UI Emoji, les polices système d'Apple, une police d'icônes d'entreprise, une ancienne police Big5 d'un éditeur taïwanais et la zone de caractères définis par l'utilisateur d'un IME chinois revendiquent tous des portions de la PUA qui se chevauchent. Un nom de famille stocké sous la forme U+F9000 peut s'afficher comme une case sur une machine, comme un idéogramme rare sur une deuxième et comme un dingbat sur une troisième. Les octets sont identiques. Le nom, non.

C'est là le véritable mode de défaillance : non pas « illisible », mais lisible en silence comme autre chose.

Ce que nous en faisons

Nous excluons les 23. Notre corpus taïwanais contient 2 707 des 2 731 noms de famille du registre, et les 24 lignes exclues sont ces 23 plus la ligne d'agrégation 其他 (« autres », 5 174 personnes), qui est une catégorie statistique et non un nom.

Mesuré sur le fichier livré :

La règle est étroite et mérite d'être énoncée avec précision : nous ne supprimons pas les noms de famille rares, nous supprimons les noms de famille que nous ne pouvons pas afficher. 慕容 (1 porteur), 呼延 (1), 公羊 (1) et 澹臺 (2) figurent tous dans le fichier. La rareté n'est jamais une raison d'écarter une ligne ; une ligne qui produit une case vide sur l'écran du lecteur, si.

Il n'y a pas d'alternative honnête ici. Nous ne pouvons pas les remplacer par un caractère d'aspect similaire, parce que « d'aspect similaire » est un jugement porté sur un glyphe que nous n'avons jamais vu. Nous ne pouvons pas translittérer, parce qu'il n'y a rien à partir de quoi translittérer. Nous ne pouvons pas inventer une valeur de remplissage, parce qu'une identité générée portant U+F9000 est pire qu'une identité portant un vrai nom de famille. Les 573 personnes sont simplement en dehors de ce qu'un système fondé sur le texte peut représenter, et la réponse correcte consiste à le dire plutôt qu'à en donner une approximation.

La seconde classe : 14 noms de famille qui survivent jusqu'à ce que quelque chose les normalise

Aucun point de code PUA n'atteint notre fichier livré. Mais le fichier contient bel et bien 1 780 points de code distincts, et ils ne sont pas tous dans le bloc auquel on s'attendrait :

Les 14 du CJK Compatibility Ideographs Supplement (U+2F800–U+2FA1F) sont les cas intéressants. Ce bloc n'existe que pour la compatibilité aller-retour avec des normes plus anciennes, et chaque caractère qu'il contient possède une décomposition canonique singleton : la norme dit qu'il se décompose en exactement un autre caractère, et l'étape de composition ne le reconstitue jamais.

Concrètement : NFC, NFD, NFKC et NFKD transforment tous ces caractères en un idéogramme unifié ordinaire. Non pas « peuvent » — la norme Unicode l'exige.

Pour les 14, le jumeau unifié est déjà une ligne distincte dans le même fichier, avec son propre effectif de porteurs :

Les deux colonnes paraissent identiques parce que, sur votre écran, elles le sont — même glyphe, même forme, point de code différent. 284 porteurs se trouvent du côté gauche, soit 0,0012 % du poids du corpus.

Ce ne sont pas des défauts. Le ministère les conserve comme des lignes distinctes parce que, pour l'enregistrement des foyers, ce sont des formes écrites distinctes, et notre fichier reflète le registre. Mais elles sont un pistolet chargé braqué sur le consommateur.

Pourquoi c'est la normalisation qui est la partie dangereuse, pas l'encodage

Un nom de famille non encodable échoue bruyamment. Vous voyez une case, vous ouvrez un rapport de bogue. Un idéogramme de compatibilité échoue en silence, et seulement dans certaines couches de votre pile.

Prenez un seul enregistrement qui traverse une application web ordinaire :

1. La base de données conserve 周 U+2F83F (25 porteurs) et 周 U+5468 (282 185 porteurs) comme deux lignes.
2. Un front-end JavaScript exécute name.normalize() avant d'envoyer une requête de recherche — la pratique actuelle, recommandée. U+2F83F devient U+5468. Deux noms de famille n'en font plus qu'un.
3. Un back-end PHP dépourvu de l'extension intl ne peut pas normaliser du tout : Normalizer n'existe pas. (Notre installation locale de PHP 8.5.8 est exactement dans ce cas — nous l'avons vérifié.) La même chaîne circulant dans l'autre sens reste donc U+2F83F.
4. Un index de recherche doté d'un filtre de normalisation ICU les fusionne ; une requête LIKE, non.
5. Un client macOS qui écrit le nom dans un nom de fichier obtient du NFD du système de fichiers ; un client Linux, non.

Rien dans cette chaîne n'est erroné. Chaque composant se comporte comme documenté. L'enregistrement finit malgré tout avec deux identités différentes selon la porte par laquelle il est entré.

Deux symptômes concrets de plus :

La longueur n'est pas la longueur. 周 U+2F83F fait 4 octets en UTF-8 et 2 unités de code en UTF-16 ; 周 U+5468 fait 3 octets et 1 unité de code. Donc LENGTH() dans MySQL renvoie 4 contre 3, le .length de JavaScript renvoie 2 contre 1, et une colonne VARCHAR(1) rejettera l'un des deux. Un nom de famille « d'un caractère » échoue à une validation d'un caractère.

Les index uniques peuvent aller dans les deux sens et vous ne pouvez pas savoir lequel. Que utf8mb4_unicode_ci les traite ou non comme égaux dépend de la version de l'UCA que votre serveur implémente et du fait que la collation normalise ou non — et nous n'avons délibérément pas testé de MariaDB en fonctionnement pour cette page, nous n'allons donc pas vous dire ce que fait la vôtre. Ce que nous pouvons vous dire, c'est que la réponse n'est pas évidente, qu'elle peut changer lors d'une mise à niveau du serveur, et que si votre contrainte d'unicité sur une colonne de noms se met silencieusement à rejeter une insertion après un saut de version mineure, c'est de cette famille de raisons qu'il s'agit.

La ligne qui illustre le mieux le propos est 丸 : U+2F801 a un porteur et U+4E38 a un porteur. Normalisez, et vous obtenez un nom de famille à deux porteurs, sans aucune trace du fait que deux foyers distincts ont enregistré deux glyphes différents. L'arithmétique est préservée. Le fait a disparu.

Que faire

Décidez une fois pour toutes où se produit la normalisation, et écrivez-le. Pas « nous utilisons NFC » — quelle couche l'applique, à l'écriture ou à la lecture, et quelle est la forme de stockage. Un système où trois couches normalisent chacune de leur côté est un système où la forme de stockage est celle du dernier qui a écrit.

Stockez la forme enregistrée ; dérivez-en la forme de recherche. Même structure que le problème de tri des noms de famille européens à préfixe : l'affichage et l'appariement veulent deux chaînes différentes. Gardez dans une colonne la séquence d'octets que le registre vous a donnée, et construisez dans une autre une clé explicitement normalisée pour la consultation, les jointures et l'unicité. Ne faites pas de la forme normalisée la seule forme.

Ne normalisez pas les noms comme étape de nettoyage. Appliquer NFC à un texte fourni par l'utilisateur à la frontière de votre API est raisonnable ; appliquer NFC à une colonne de noms dans une migration, c'est une perte de données assortie d'un message de commit. Les 14 lignes ci-dessus représentent 284 personnes dont le nom de famille enregistré ne diffère d'un autre nom de famille que par le point de code, et un seul UPDATE ... SET name = NORMALIZE(name) les fusionne sans erreur et sans retour possible.

Validez sur la possibilité d'affichage, pas sur la plausibilité. Si vous filtrez tant soit peu les saisies de noms, une règle raisonnable est « rejeter les points de code situés dans les Private Use Areas » — non pas parce qu'ils sont invalides, mais parce que vous ne pouvez pas promettre que le destinataire verra ce que l'expéditeur a tapé. Cette règle est étroite, défendable, et ne rejette pas accidentellement 慕容 ni 澹臺.

Attendez-vous à ce que le registre ait raison et que la norme soit en retard. Chaque fois que nous avons trouvé un nom que notre outillage ne savait pas traiter, c'est l'outillage qui était le problème. U+FBF33, ce sont 179 personnes vivantes ; le fait qu'ISO 10646 n'ait pas de point de code pour leur nom de famille est un fait à propos d'ISO 10646.

Limites connues

• Nous ne pouvons pas vous dire à quoi ressemblent les 23 caractères. Nous avons leurs points de code, pas leurs glyphes. Le ministère ne publie pas de correspondance de glyphes avec le jeu de données ouvert, nous pouvons donc rapporter que ces personnes existent, mais pas quel est leur nom de famille.
• Nous n'avons pas testé le comportement de collation sur une base de données en fonctionnement. L'affirmation de cette page au sujet de MariaDB est délibérément un aveu d'incertitude, pas un résultat.
• Les 14 lignes compat sont livrées non fusionnées, à dessein. Les fusionner modifierait 14 effectifs de porteurs et détruirait une distinction que le registre établit. Notre position est qu'un consommateur qui a besoin de les voir fusionnées doit les fusionner en connaissance de cause, dans sa propre colonne de clé.
• La réconciliation interne du registre est inexpliquée. Le ministère indique ailleurs que Taïwan compte 1 785 noms de famille, alors que le jeu de données ouvert compte 2 731 lignes. Nous avons une lecture plausible de cet écart, et aucune confirmation de celle-ci.

Données arrêtées au 2026-07-21

Date de référence du registre : 30 juin 2023 (民國112年6月30日), publié par 內政部戶政司 sous la Government Open Data Licence v1. Tous les chiffres de cette page ont été recalculés le 21 juillet 2026 à partir du CSV brut et de notre fichier de poids livré ; les fichiers de noms de famille masculins et féminins sont identiques octet pour octet, parce que les noms de famille taïwanais ne se fléchissent pas selon le genre.

Sources

• 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