Codifica che minimizza la lettura errata/l'errata digitazione/l'errata registrazione?

Question

Supponiamo che tu abbia un sistema in cui un valore chiave abbastanza lungo può essere comunicato con precisione a un utente sullo schermo, via e-mail o tramite carta; ma l'utente deve essere in grado di comunicarti la chiave con precisione leggendola per telefono o leggendola e digitandola in un'altra interfaccia.

Che cos'è un "buon" modo di codificare la chiave per rendere la lettura/l'udito/la digitazione facile & accurata?

Questo potrebbe essere un numero di fattura, un ID documento, un ID transazione o qualche altro valore astratto. Diciamo per motivi di questa discussione il valore di chiave di fondo è un numero grande, diciamo 40 cifre in base 10.

Alcuni pensieri:

Shorter tasti sono generalmente migliori

• 40 -digit base 10 potrebbe non adattarsi allo spazio indicato ed è facile perdersi nel mezzo di
• lo stesso valore potrebbe essere rappresentato nella base 16 in 33-34 cifre
• lo stesso valore potrebbe essere rappresentato in base 36 a 26 cifre
• lo stesso valore potrebbe essere rappresentato in base 64 a 22-23 cifre

caratteri che non possono essere visivamente confuso con l'altro sono meglio

• per esempio una codifica che include sia O (oh) che 0 (zero) o S (ess) e 5 (cinque), potrebbe essere errata
• Questo problema dipende dal carattere/volto utilizzato per visualizzare la chiave, che potresti essere in grado di controllare in alcuni casi (come la stampa su carta) ma non può controllare in altri (come pagine web e e-mail).
• Dipende anche dal fatto che sia possibile controllare l'uso esclusivo di maiuscole e minuscole - ad es. la maiuscola D (dee) può apparire come O (oh) ma la lettera maiuscola d (dee) non lo sarebbe; mentre la lettera minuscola l (ell) ha l'aspetto di 1 (uno) mentre la maiuscola L (ell) non lo sarebbe. (Con eccezioni per caratteri/volti particolarmente esotici).

caratteri che non possono essere verbalmente/foneticamente confuso con l'altro sono meglio

• un (ay) 8 (otto)
• B (ape) C (cee) D (dee) E (ee) g (gee) p (pipì) t (tee) v (vee) z (zee) 3 (tre)
• Questo problema dipende dalla qualità audio del canale end-to-end - sfida maggiore se la base di utenti prevista potrebbe avere un impedimento di pronuncia, o potrebbe dover parlare attraverso una maschera antigas, o il canale di comunicazione potrebbe includere radio CB o sistemi telefonici VOIP instabili.

L'aggiunta di una cifra di controllo o due potrebbe rilevare errori ma non aiutare a risolvere gli errori.

Una finestra di dialogo di tipo alfa - bravo - charlie - delta può essere utile per gli errori di udito, ma non per la lettura degli errori.

possibili scelte di codifica:

• Base 64 - compatti, ma troppi difficili da verbalizzare caratteri (sottolineatura, dash ecc)
• Base 34 - 0-9 e AZ ma con O (oh) e I (aye) omessi come il più facile da confondere con le cifre
• Base 32 - uguale alla base 34 ma lasciare fuori 0 (zero) e 1 (uno) pure

I C'è una codifica generalmente riconosciuta che è una soluzione ragionevole per questo scenario?

Answer 1

Quando l'ho sentito prima, mi è piaciuto l'articolo A Proposal for Proquints: Identifiers that are Readable, Spellable, and Pronounceable. Codifica i dati come una sequenza di consonanti e vocali. È legato alla lingua inglese però. (Perché in tedesco, f e v sono uguali, quindi non dovrebbero essere usati entrambi). Ma mi piace l'idea generale.