Unicode

Unicode est la norme universelle d’encodage des caractères maintenue par le Consortium Unicode. Il attribue un numéro unique (un « point de code ») à chaque caractère de chaque système d’écriture qui a été formellement proposé et accepté — actuellement environ 150 000 caractères sur 161 scripts, incluant les langues modernes, les scripts historiques, les symboles mathématiques, la notation technique et les emoji.

Les points de code sont écrits sous la forme U+XXXX (4-6 chiffres hexadécimaux). La lettre A est U+0041 ; le i sans point turc est U+0131 ; l’emoji fusée est U+1F680.

Unicode en lui-même ne spécifie pas comment les points de code sont sérialisés en octets — c’est le rôle des encodages. Les trois principaux encodages :

• UTF-8 — largeur variable de 1-4 octets par point de code. Compatible ASCII. L’encodage web dominant.
• UTF-16 — 2 ou 4 octets par point de code. Utilisé en interne par Java, les chaînes JavaScript et Windows.
• UTF-32 — exactement 4 octets par point de code. Simple mais gaspilleur ; rarement utilisé pour le stockage.

Les outils de Convertitive gèrent l’Unicode complet là où ils le devraient — l’encodeur Base64 gère correctement UTF-8, le compteur de mots compte les points de code et les graphèmes, le convertisseur de casse respecte la casse spécifique au turc (le problème du I pointé vs sans point).

Point de code ≠ caractère ≠ graphème — la distinction qui casse toutes les bibliothèques de chaînes : la lettre « é » peut être représentée de deux façons en Unicode — comme le point de code unique U+00E9 (précomposé) ou comme U+0065 (e) suivi de U+0301 (accent aigu combinant). Les deux se rendent identiquement ; les deux comptent comme « un caractère » pour un humain ; l’un est un point de code, l’autre en est deux. Les emoji sont pires : 👨‍👩‍👧 (famille) est une séquence ZWJ de sept points de code mais un seul graphème. Les comptes de longueur en JavaScript (str.length) retournent des unités de code UTF-16, pas des graphèmes — l’emoji famille a une longueur de chaîne de 11. Utilisez Intl.Segmenter (navigateurs modernes, Node 16+) pour des comptes de graphèmes précis.

Formes de normalisation Unicode — quand le texte ne correspond pas à lui-même : deux chaînes visuellement identiques peuvent avoir des représentations d’octets différentes à cause de la division précomposé vs décomposé ci-dessus. La norme Unicode définit quatre formes de normalisation (NFC, NFD, NFKC, NFKD) qui canonicalisent cela. NFC (composé) est la valeur par défaut pour HTML et la plupart des systèmes de fichiers ; NFD (décomposé) est la valeur par défaut de macOS HFS+ et la raison pour laquelle les chemins de fichiers semblent parfois identiques mais se comparent inégalement entre systèmes. Les recherches d’égalité de chaînes en base de données et les recherches dans les index devraient normaliser en NFC à l’écriture pour éviter le bug « la requête identique ne retourne rien ». Référence : La norme Unicode, version 15.

Exemple concret

Prenez la chaîne « café ». Deux représentations Unicode également valides : NFC = U+0063 U+0061 U+0066 U+00E9 (4 points de code), NFD = U+0063 U+0061 U+0066 U+0065 U+0301 (5 points de code, « e » + accent aigu combinant). Les deux se rendent identiquement. Maintenant, considérez ce que chacun ressemble dans différents comptes : en UTF-8 NFC fait 5 octets (63 61 66 C3 A9) ; NFD fait 6 octets (63 61 66 65 CC 81). En JavaScript : "café".length = 4 pour NFC, 5 pour NFD. Comparez l’égalité sans normalisation : nfc === nfd est false. Passez les deux dans String.prototype.normalize("NFC") d’abord : ils deviennent identiques. Bug corrigé. C’est la cause profonde exacte du « j’ai cherché José et l’enregistrement existe mais ne revient pas » dans les bases de données stockant des noms soumis par des utilisateurs depuis des clients Mac et Windows mixtes.

Quand et pourquoi cela est important

Toute application internationalisée rencontre des cas limites Unicode à un moment donné : noms d’utilisateur avec des marques de combinaison, chemins de fichiers copiés entre macOS (NFD) et Linux (NFC), vietnamien avec des signes diacritiques empilés, règles de casse turques (la minuscule de « I » est « ı » et non « i » — le « problème Turkish-I » a causé de vrais crashs iOS en 2018), rendu de droite à gauche en arabe et hébreu, et emoji basés sur ZWJ. Les règles défensives : normaliser en NFC à l’entrée, utiliser Intl.Collator pour le tri adapté à la locale (pas le tri par point de code de Array.sort), utiliser Intl.Segmenter pour la troncature tenant compte des graphèmes, et laisser CLDR (la base de données de locale d’Unicode) piloter le comportement spécifique à la locale. Référence : Rapport technique Unicode #15 — Formes de normalisation.