Convertisseur de normalisation Unicode | Vue parallèle des quatre formes

Collez n'importe quelle chaîne et observez sa normalisation simultanée en NFC, NFD, NFKC et NFKD, avec le nombre de caractères, le nombre d'octets UTF-8 et l'écart d'octets par rapport à l'original pour chaque forme. L'outil s'adresse aux équipes backend, aux responsables d'indexation et aux développeurs i18n qui ont besoin de voir précisément ce que chaque normalisation fait à une chaîne sensible avant de figer un correctif en production.

💡 À propos de cet outil

La normalisation Unicode existe parce que le même caractère « visible » peut s'écrire sous plusieurs séquences d'octets différentes. Le é peut être un seul point de code U+00E9 (forme précomposée) ou deux points de code, e (U+0065) suivi d'un accent aigu combinant (U+0301) (forme décomposée). Les deux s'affichent identiquement dans n'importe quelle police moderne, mais === en JavaScript, WHERE en SQL et equals() en Java les jugent inégaux. C'est la source réelle de la plupart des bugs « le nom existe mais la requête ne le trouve pas ».

L'outil prend votre texte, le passe dans String.prototype.normalize() pour les quatre formes officielles du standard Unicode, et affiche le résultat en parallèle : la chaîne normalisée, le nombre de caractères (comptés en points de code perceptibles par l'utilisateur), la taille en octets UTF-8 et l'écart par rapport à l'entrée. L'indicateur « forme d'entrée » détecte aussi à quelle des quatre formes appartient déjà votre texte, ce qui évite une conversion superflue lorsque la source est déjà conforme.

NFKC et NFKD sont les décompositions de compatibilité : elles transforment les latines pleine chasse en ASCII, étendent les ligatures typographiques (fi → fi) et réécrivent les chiffres entourés (① → 1). C'est exactement ce qu'on veut pour une clé de recherche ou un hash de déduplication, et c'est exactement ce qu'on ne veut pas pour le stockage canonique du nom propre d'une personne.

🧐 Questions fréquentes

Q. Quelle forme choisir pour le stockage en base ? A. NFC, dans la quasi-totalité des cas. Le W3C, dans sa spécification « Character Model for the World Wide Web » (Charmod-Norm), recommande NFC pour HTML, les URL, les attributs du DOM et tout texte qui franchit une frontière de processus. NFD reste utile comme représentation intermédiaire (par exemple pour dépouiller les diacritiques avant une recherche approximative), mais la forme canonique de stockage doit être NFC.

Q. Est-il vrai que macOS stocke les noms de fichiers en NFD ? A. C'était vrai pour HFS+, qui utilisait une variante spécifique appelée « NFD with reserved range ». APFS, le système de fichiers par défaut depuis macOS High Sierra, ne normalise plus : il enregistre exactement les octets que l'application fournit. « macOS = NFD » est donc une demi-vérité. En revanche, les fichiers issus d'une vieille sauvegarde Time Machine, d'un rsync historique ou d'un disque externe en HFS+ arrivent toujours en NFD et cassent les comparaisons côté Linux. Cet outil sert précisément à vérifier sous quelle forme se trouve réellement un texte en main.

Q. Quand utiliser NFKC plutôt que NFC ? A. Pour construire une clé de recherche ou un hash de comparaison où la typographie n'a pas d'importance. Wikipédia normalise les titres avec NFKC suivi de casefold(), les moteurs full-text comme Elasticsearch normalisent à l'indexation, et certains systèmes d'authentification appliquent NFKC aux identifiants pour éviter l'attaque homographe (Admin latin contre Аdmin cyrillique). Règle pratique : NFKC pour la clé, NFC pour la valeur.

Q. Quelle est la différence entre canonique (NFC/NFD) et compatibilité (NFKC/NFKD) ? A. Les normalisations canoniques sont réversibles : NFC(NFD(s)) === s pour toute chaîne Unicode bien formée. Elles ne perdent ni n'altèrent l'information. Les normalisations de compatibilité, elles, écartent des distinctions typographiques que le standard juge « secondaires » : pleine chasse contre demi-chasse, exposants contre base, ligatures contre caractères séparés. Si vous voulez appliquer NFKC, faites-le sur la clé de recherche, jamais sur le texte que l'utilisateur verra.

Q. Pourquoi certains caractères pèsent deux octets en NFC et trois en NFD ? A. Parce que la forme décomposée utilise plus de points de code, et chaque point de code occupe entre 1 et 4 octets en UTF-8. Un à précomposé est U+00E0 (2 octets en UTF-8). Le même à décomposé est U+0061 (1 octet) plus U+0300 (2 octets), soit 3 octets au total. La colonne « écart » de la table reflète directement cette différence.

Q. Que se passe-t-il avec les émojis ? A. Les émojis composés (familles, drapeaux, modificateurs de teint) sont des séquences ZWJ ou des paires d'indicateurs régionaux, et non des points de code uniques. Aucune des quatre normalisations ne les modifie. Ce qui change avec NFKC, ce sont les caractères mathématiques décoratifs (𝒜, 𝓗) qui se réduisent à du latin ordinaire — pratique pour la déduplication, désastreux si vous les stockez comme nom de marque.

Q. La fonction marche-t-elle sur de très longs textes ? A. Oui. normalize() est natif au moteur JavaScript (ICU dessous) et traite plusieurs mégaoctets en quelques millisecondes. Le goulot d'étranglement est plutôt la zone de texte du navigateur, pas la normalisation elle-même. Pour analyser un long log, échantillonnez quelques milliers de caractères significatifs en entrée.

📚 Le saviez-vous

Une décision technique étonnamment lourde de l'histoire récente du web a été le traitement de la normalisation de compatibilité par IDN (Internationalized Domain Names). La première version du standard, IDNA2003, imposait l'application de NFKC et du casefolding à tout nom de domaine, via un processus appelé « Nameprep ». Cela signifiait que ①.example résolvait littéralement vers 1.example, et que la plupart des caractères ressemblant à de l'ASCII s'écrasaient entre eux. Le résultat fut un désastre de sécurité : les attaques par homographe sont devenues triviales. La révision IDNA2008 a supprimé Nameprep et exige désormais que les noms d'hôte soient stockés en NFC, en rejetant toute étiquette que NFKC aurait modifiée. La barre d'adresse du navigateur est aujourd'hui l'une des rares surfaces logicielles qui interdit explicitement la normalisation de compatibilité.

Côté français, le piège classique concerne les voyelles accentuées issues de vieux exports Mac : é, à, ç arrivent parfois en NFD parce que l'export venait d'un système HFS+. La requête WHERE nom LIKE '%François%' renvoie alors zéro résultat, même si la valeur s'affiche correctement dans la console. La solution standard consiste à passer la chaîne de recherche et les données par la même forme (NFC, en pratique) avant de comparer — exactement ce que ce convertisseur permet de vérifier en quelques secondes sur un échantillon avant d'écrire la migration.