Trois niveaux pour une valeur textuelle
Une personne voit du texte, parfois avec une marque associée à la lettre précédente. Unicode attribue des points de code à des caractères abstraits ; un encodage comme UTF-8 transforme ensuite ces points en octets pour le stockage ou la transmission. Un caractère visible peut comprendre plusieurs points de code, et un seul point peut occuper plusieurs octets UTF-8. Compter les octets ne revient donc pas nécessairement à compter les lettres ni les caractères perçus par l’utilisateur. L’outil texte vers points de code montre les valeurs Unicode d’une chaîne ; l’outil texte vers octets UTF-8 montre un autre niveau. Ces vues servent au diagnostic, mais ne sont pas des écritures substituables sans connaître l’encodage attendu par le destinataire.
Deux écritures de café
Le mot visible café peut se terminer par le seul point U+00E9, LETTRE MINUSCULE LATINE E ACCENT AIGU. C’est une forme composée. Il peut aussi se terminer par U+0065, LETTRE MINUSCULE LATINE E, suivi de U+0301, ACCENT AIGU COMBINANT. La deuxième écriture ajoute un point de code bien que le résultat soit souvent identique à l’écran. En UTF-8, le mot composé donne les octets hexadécimaux 63 61 66 C3 A9 ; la forme décomposée donne 63 61 66 65 CC 81. Ces suites d’octets sont différentes : une comparaison exacte ou une empreinte peut donc changer. NFC ramène cet exemple à la suite composée et NFD à la suite décomposée. Le convertisseur intégré affiche les octets en décimal : 99 97 102 195 169 pour la forme composée et 99 97 102 101 204 129 pour la forme décomposée. Comparez ces valeurs à la notation hexadécimale ci-dessus.
- café : U+00E9 → finit par C3 A9
- café : U+0065 U+0301 → finit par 65 CC 81
- NFC ⇢ composé · NFD ⇢ décomposé
Portée de la normalisation
La normalisation Unicode définit des représentations pour des suites canoniquement équivalentes. NFC effectue une composition canonique après décomposition ; NFD conserve une suite canoniquement décomposée. Cela aide à comparer du texte venu de claviers, fichiers ou systèmes différents. La normalisation ne traduit pas, ne supprime pas les accents et ne rend pas identiques toutes les chaînes qui se ressemblent. Des caractères visuellement voisins appartiennent parfois à d’autres écritures ou portent un autre sens. Les formes de compatibilité NFKC et NFKD peuvent modifier davantage de distinctions de présentation : retenez-les seulement si votre usage tolère ces changements. Appliquez une politique de normalisation cohérente aux valeurs comparées, indexées ou hachées ; autrement, deux entrées proches peuvent suivre des chemins distincts.
Diagnostiquer étape par étape
Lorsqu’un nom ne correspond pas, conservez d’abord la saisie d’origine. Regardez ses points de code pour déterminer si l’accent est un caractère précomposé ou une lettre de base suivie d’une marque combinante. Regardez ensuite les octets UTF-8 qui seront réellement transmis par une API ou écrits dans un fichier. Normalisez des copies en NFC ou NFD, comparez les points obtenus, puis utilisez le convertisseur inverse d’octets UTF-8 pour vérifier que la suite est valide et décodée comme prévu. Pour un échange de fichiers, indiquez explicitement l’encodage choisi au lieu de supposer que tous les logiciels partagent le même réglage. Un caractère de remplacement signale souvent un problème de décodage ; normaliser un texte déjà mal décodé ne recrée pas les octets perdus.
Choisir le bon test d’égalité
Pour vérifier exactement l’intégrité d’un fichier, d’une empreinte ou d’une signature, les octets sont déterminants : modifier la normalisation change les octets et donc l’empreinte. Pour une recherche destinée aux utilisateurs ou une détection de doublons, un service peut normaliser d’abord, mais doit expliquer et tester cette règle. Casse, ponctuation, espaces et classement propre à une langue sont des sujets distincts ; NFC ne les résout pas. Ne modifiez pas silencieusement l’orthographe saisie par une personne lors de l’affichage ou de l’exportation sans besoin explicite. Dans les outils ci-dessous, commencez avec café et ses octets UTF-8, puis collez une version construite avec e et un accent combinant. Comparez les points de code et les résultats de normalisation pour voir où naît la différence.