Unicode peut contenir des séquences distinctes, canoniquement liées et souvent visuellement proches. La lettre é précomposée vaut U+00E9 ; la forme décomposée utilise U+0065 puis U+0301. Les considérer égales peut aider la recherche, mais convertir l’une en l’autre est une normalisation séparée qui détruirait la preuve exacte de l’entrée.
Les deux formes donnent des preuves distinctes
En UTF-8, U+00E9 devient C3 A9 et U+0065 U+0301 devient 65 CC 81. Les comptes sont un et deux scalaires, une et deux unités UTF-16, deux et trois octets. UnicodeLens montre ces faits sans décider si une police les rend pareil. Le preset place les deux formes autour d’un séparateur pour vérifier l’ordre.
Inspection et normalisation sont des tâches distinctes
Un inspecteur doit préserver la valeur inspectée. UnicodeLens n’applique ni NFC, NFD, NFKC ou NFKD, ne replie pas la casse et ne retire ni sélecteurs ni jointures. Un futur normaliseur exigerait formes explicites, preuves avant/après, avertissements de perte et données de conformité exécutables. Cette séparation garantit que les copies U+ et octets correspondent au champ, sans réparation cachée.
Le système consommateur choisit la comparaison
Bases de données, langages, systèmes de fichiers et moteurs ne normalisent ni ne comparent tous pareil. L’équivalence canonique ne règle pas collation locale, graphèmes, usurpation ou politiques d’identifiants. Utilisez UnicodeLens pour saisir la séquence exacte, puis une politique documentée dans le système consommateur. N’inférez jamais identité, interchangeabilité ou sécurité du seul glyphe.