Comprendre et éviter les caractères visuellement ambigus dans les identifiants

Comprendre les caractères visuellement ambigus dans les identifiants

• Les caractères visuellement ambigus désignent des caractères difficiles à distinguer dans certaines polices ou en écriture manuscrite
  • O/0, I/l/1/7, 5/S, 2/Z, 8/B, 6/G, 9/q/g, etc.
• Ces caractères peuvent provoquer des erreurs et de la confusion lors de la saisie des données
  • Par exemple, l'utilisateur peut avoir du mal à distinguer O et 0 et saisir un code erroné, ce qui dégrade l'expérience utilisateur
• C'est particulièrement important lorsque l'identifiant est transmis oralement ou doit être écrit à la main
  • support client, code promo, code de suivi, ID d'erreur, ID produit, etc.

Décider si l'on distingue les majuscules et les minuscules

• Il faut décider si les identifiants feront la distinction entre majuscules et minuscules
  • Avec distinction casse sensible, 53 caractères restent disponibles après exclusion des ambiguïtés visuelles
  • Sans distinction casse insensible, 22 caractères restent disponibles
• Pour des identifiants de 5 caractères, le nombre d'identifiants possibles est :
  • Distinction majuscules/minuscules : 53^5 = 418,195,493
  • Sans distinction majuscules/minuscules : 22^5 = 5,153,632
• Cependant, plus la longueur de l'identifiant augmente, plus le nombre de combinaisons possibles croît de façon exponentielle
• Il faut donc trouver un compromis entre la longueur de l'identifiant et le risque d'ambiguïté visuelle
• En outre, si l'on utilise à la fois majuscules et minuscules, des problèmes inattendus peuvent survenir avec des systèmes tiers qui ne distinguent pas la casse

Jeu de caractères visuellement clair

• Si la lisibilité est prioritaire, il est recommandé d'utiliser le jeu de caractères suivant :
  • [ "a", "b", "c", "d", "e", "f", "h", "i", "j", "k", "m", "n", "o", "p", "r", "s", "t", "w", "x", "y", "3", "4"]

Autres points à prendre en compte

• Certaines combinaisons de caractères peuvent ressembler à d'autres caractères (par ex. rn peut ressembler à m, et 3 à w)
  • Il est préférable d'éviter ces combinaisons dès l'étape de génération des identifiants
• Il vaut aussi mieux éviter les caractères dont la prononciation est proche (par ex. b et p)
  • C'est particulièrement important lorsque l'identifiant est communiqué oralement

Exemples existants

• Crockford's Base32 : décode les caractères ambigus comme une même valeur et prend aussi en compte les jurons accidentels
• Open Location Code : utilise le jeu de caractères 23456789CFGHJMPQRVWX. L'objectif est d'éviter les ambiguïtés visuelles tout en évitant aussi la formation de mots dans les langues courantes. Toutefois, 6/G et 9/Q sont inclus.

Avis de GN⁺

• Lors de la génération d'identifiants, l'utilisabilité et la lisibilité doivent être des priorités absolues. C'est d'autant plus vrai lorsque les identifiants sont souvent transmis oralement ou notés à la main.
• Il est important de choisir un jeu de caractères qui minimise l'ambiguïté visuelle, tout en trouvant un bon compromis entre la longueur de l'identifiant et le nombre de combinaisons possibles.
• Il faut aussi décider avec prudence si les identifiants seront sensibles à la casse, car des problèmes inattendus peuvent apparaître lors de l'intégration avec des systèmes tiers.
• La logique de génération des identifiants doit également prendre en compte des critères supplémentaires, comme l'exclusion de certaines combinaisons de caractères ou l'évitement de caractères à prononciation proche.
• Il est souhaitable de s'appuyer sur des exemples comme Crockford's Base32 ou Open Location Code afin de concevoir le jeu de caractères le plus adapté aux exigences du projet.

[roxie]

Ça a l’air bien aussi : https://stackoverflow.com/a/58098360/8556340

[roxie]

Le fait qu’ils aient même pris en compte la prononciation est vraiment remarquable.

[GN⁺]

Avis Hacker News

• Il existe un cas réel, sur le terrain, où l’utilisation de numéros de série contenant des caractères ambigus sur des millions d’appareils a créé d’énormes difficultés pour le support client. Une expérience cauchemardesque a consisté à générer des variantes de fautes de frappe avec des expressions régulières puis à les comparer à la base de données pour déduire le vrai numéro de série.
• Il faut adapter la méthode d’encodage selon les utilisateurs. Base32 convient bien grâce à son jeu de caractères clair, et pour une transmission orale il vaut mieux utiliser une représentation par liste de mots (par ex. "TIDE ITCH SLOW REIN RULE MOT"). Attention toutefois aux pièges des expressions idiomatiques, des homophones, des dialectes, etc. ; il ne faut donc pas créer sa propre liste de mots.
• Quelqu’un a déjà reçu des demandes de support inattendues à cause d’un module de calcul en base arbitraire publié pour plaisanter sur CPAN (Math::Fleximal). La cause était que quelqu’un avait utilisé en production le code de démonstration convertissant de l’hexadécimal en code alphanumérique.
• Sur l’écran de saisie des numéros de série de DLC de la Nintendo Switch, les touches correspondant aux caractères ambigus sont désactivées, ce qui améliore l’UX.
• Il faut aussi éviter les caractères difficiles à distinguer lorsqu’ils sont écrits à la main. En particulier, '7' et '1' se confondent facilement.
• Si l’on utilise à la fois majuscules et minuscules, on peut avoir de mauvaises surprises plus tard à cause de systèmes ou protocoles insensibles à la casse. Il existe même des systèmes commerciaux qui ne considèrent pas cela comme un bug au nom du confort utilisateur.
• Chaque fois qu’on note des codes de secours 2FA sur papier, une angoisse surgit face à certains caractères (o/0, v/u, 5/S, etc.). Pour l’éviter, certains ajoutent des ornements aux caractères.
• Comme mot de passe Wi‑Fi, certains choisissent un mot courant qu’un enfant de CE2 peut écrire correctement, comme "vacation".
• KeepassXC améliore fortement la lisibilité en utilisant des couleurs différentes selon les types de caractères (majuscules, minuscules, chiffres, symboles, etc.).
• Les adresses Bitcoin utilisent un encodage Base58 modifié.
• L’article orthographie par erreur la police Arial en Ariel.