Normaliser Unicode en NFC

Exemple concret

NFC décompose puis recompose canoniquement les caractères afin de produire la forme composée courante. Convertissez localement dans votre navigateur. Par exemple, la saisie "Café" produit "Café". Comparez les deux côtés caractère par caractère ; l’apparence peut cacher des octets ou marques combinantes différents. Choisissez NFC si une règle de stockage ou de comparaison demande du texte canonique composé. Un accent décomposé peut se recomposer sans changer le mot visible.

Fonctionnement de la représentation

Unicode définit quatre formes de normalisation. NFC et NFD sont canoniques : elles conservent l’équivalence canonique en composant ou décomposant lorsque cela est défini. NFKC et NFKD appliquent aussi des correspondances de compatibilité, comme le passage des lettres latines pleine chasse ou des chiffres cerclés vers des formes ordinaires ; des distinctions peuvent disparaître. C signifie recomposition et D décomposition. Un résultat normalisé peut sembler identique alors que ses points de code changent. La normalisation aide certaines comparaisons exactes et indexations, mais la forme choisie doit être cohérente dans le système. Ce n’est ni un filtre de sécurité universel ni une translittération. NFC décompose puis recompose canoniquement les caractères afin de produire la forme composée courante.

Une transformation de texte a un sens. Déterminez d’abord si la source est du texte Unicode lisible, une liste d’octets, des points de code ou une chaîne déjà encodée. Collez une courte valeur connue, examinez la sortie, puis traitez une entrée plus longue. Gardez la source. Une séquence encodée peut être réversible et révéler chaque octet à quiconque connaît le format ; l’encodage ne protège pas la confidentialité. Le calcul se déroule dans ce navigateur et n’envoie pas le contenu collé à un serveur de conversion. La sortie reste toutefois sensible si vous la collez dans un document, ticket ou lien partagé.

Limites et usage fiable

La normalisation ne traduit pas et n’élimine pas tous les caractères trompeurs. Les formes de compatibilité peuvent modifier des distinctions. Utilisez précisément l’alphabet, le codage d’octets et la forme de normalisation demandés par le système destinataire. Des formats semblables ne sont pas nécessairement compatibles. Une chaîne décodée peut contenir du balisage ou des caractères de contrôle ; l’application suivante doit la traiter comme une entrée non fiable. Une conversion valide ne prouve pas non plus que les données sont autorisées ou correctes. Faites un aller-retour quand l’opération est censée être réversible et comparez les points Unicode ou les octets UTF-8 si deux chaînes semblent identiques mais échouent à une comparaison exacte. Pour des données stockées ou signées, documentez la transformation dans le contrat de données.