Un encodage qui minimise les erreurs de lecture, les fautes de frappe et les fautes de langage ?

Question

Supposons que vous disposiez d'un système dans lequel une valeur clé assez longue peut être communiquée avec précision à un utilisateur à l'écran, par courrier électronique ou sur papier ;mais l'utilisateur doit être capable de vous communiquer la clé avec précision en la lisant par téléphone, ou en la lisant et en la retapant dans une autre interface.

Quelle est une « bonne » façon d’encoder la clé pour rendre la lecture/l’audition/la saisie facile et précise ?

Il peut s'agir d'un numéro de facture, d'un identifiant de document, d'un identifiant de transaction ou d'une autre valeur abstraite.Supposons que, pour les besoins de cette discussion, la valeur clé sous-jacente soit un grand nombre, disons 40 chiffres en base 10.

Quelques idées:

Les clés plus courtes sont généralement meilleures

• une valeur en base 10 à 40 chiffres peut ne pas tenir dans l'espace indiqué et il est facile de se perdre au milieu de
• la même valeur pourrait être représentée en base 16 sur 33-34 chiffres
• la même valeur pourrait être représentée en base 36 sur 26 chiffres
• la même valeur pourrait être représentée en base 64 sur 22-23 chiffres

Les personnages qui ne peuvent pas être visuellement confondus sont meilleurs

• par exemple.un encodage qui inclut à la fois O (oh) et 0 (zéro), ou S (ess) et 5 (cinq), pourrait être mauvais
• Ce problème dépend de la police/face utilisée pour afficher la clé, que vous pouvez contrôler dans certains cas (comme l'impression sur papier) mais que vous ne pouvez pas contrôler dans d'autres (comme les pages Web et les e-mails).
• Cela dépend également si vous pouvez contrôler l'utilisation exclusive des majuscules et/ou des minuscules -- par ex.Le D majuscule (dee) peut ressembler à O (oh), mais pas le d minuscule (dee) ;tandis que le l minuscule (ell) ressemble à un 1 (un), alors que le L majuscule (ell) ne le serait pas.(À l'exception des polices/visages particulièrement exotiques).

Les personnages qui ne peuvent pas être confondus verbalement/auditivement sont meilleurs

• a (ay) 8 (huit)
• B (abeille) C (cee) D (dee) E (ee) g (gee) p (pipi) t (tee) v (vee) z (zee) 3 (trois)
• Ce problème dépend de la qualité audio du canal de bout en bout - un défi plus important si la base d'utilisateurs attendue peut avoir un trouble de la parole, ou doit parler à travers un masque à gaz, ou si le canal de communication peut inclure des radios CB ou des perturbations. Systèmes téléphoniques VOIP.

L’ajout d’un ou deux chiffres de contrôle détecterait les erreurs mais n’aiderait pas à les résoudre.

Une boîte de dialogue de type alpha - bravo - charlie - delta peut aider en cas d'erreurs d'audition, mais pas d'erreurs de lecture.

Choix d'encodage possibles :

• Base 64 -- compacte, mais trop de caractères difficiles à verbaliser (trait de soulignement, tiret, etc.)
• Base 34 -- 0-9 et A-Z mais avec O (oh) et I (oui) laissés de côté car les chiffres les plus faciles à confondre
• Base 32 – identique à la base 34, mais en omettant également le 0 (zéro) et le 1 (un).

Existe-t-il un codage généralement reconnu qui constitue une solution raisonnable pour ce scénario ?

Answer 1

Quand je l'ai entendu pour la première fois, j'ai aimé l'article Une proposition pour Proquints :Identifiants lisibles, orthographiables et prononçables.Il code les données sous forme de séquence de consonnes et de voyelles.C'est cependant lié à la langue anglaise.(Parce qu'en allemand, f et v sonnent de manière égale, ils ne doivent donc pas être utilisés tous les deux.) Mais j’aime l’idée générale.