Кодировка, которая сводит к минимуму неправильное чтение/опечатку/промахивание?

Question

Предположим, у вас есть система, в которой довольно длинное ключевое значение может быть точно передано пользователю на экране, по электронной почте или через бумагу; но пользователь должен иметь возможность быстро передать вам ключ, прочитав его по телефону или прочитав его и вернув в другой интерфейс.

Что такое «хороший» способ кодирования ключа для чтения/прослушивания/ввода его легко &?

Это может быть номер счета, идентификатор документа, идентификатор транзакции или другое абстрактное значение. Скажем, ради этой дискуссии основного значения ключа является большим числом, скажем, 40 цифр в базе 10.

Некоторых мысли:

Более короткие ключи, как правило, лучше

• 40 -значное значение базы 10 может не вписываться в заданное пространство и легко затеряться в середине
• такое же значение может быть представлено в базе 16 в 33-34 цифрах
• такое же значение может быть представлена ​​в основании 36 в 26 цифр
• то же значение может быть представлено в базе 64 в 22-23 цифр

символы, которые не могут быть визуально путать друг с другом лучше

• например кодировка, которая включает в себя как O (oh), так и 0 (ноль), или S (ess) и 5 ​​(пять), может быть плохим
• Эта проблема зависит от шрифта/лица, используемого для отображения ключа, (например, печать на бумаге), но не может управлять другими (например, веб-страницами и электронной почтой).
• Также зависит от того, можете ли вы контролировать эксклюзивное использование верхнего и/или нижнего регистра - например, капитал D (dee) может выглядеть как O (oh), но нижний регистр d (dee) не будет; в то время как нижний регистр l (ell) выглядит как 1 (один), а капитал L (ell) - нет. (С исключениями для особо экзотических шрифтов/лиц).

символы, которые не могут быть в устной форме/устно путать друг с другом лучше

• а (ау) 8 (восемь)
• В (пчелиный) С (СЕЕ) D (ди) E (ee) g (gee) p (pee) t (tee) v (vee) z (zee) 3 (три)
• Эта проблема зависит от качества звука сквозного канала - большая проблема если ожидаемая пользовательская база может иметь речевое препятствие или, возможно, придется говорить через противогаз, или канал связи может включать радиосигналы СВ или прерывистые телефонные системы VOIP.

Добавление контрольной цифры или двух будет обнаруживать ошибки, но не помогать в устранении ошибок.

Диалог с диафрагмой alpha-bravo-charlie-delta может помочь с ошибками слуха, но не с ошибками чтения.

Возможные варианты кодирования:

• Base 64 - компактный, но слишком много труднодоступных многословным символов (подчеркивание, тире и т.д.)
• Base 34 - 0-9 и AZ, но с O (oh) и I (aye), которые проще всего путать с цифрами
• База 32 - то же, что и основание 34, но не содержит 0 (ноль) и 1 (один), а также

I существует ли общепризнанная кодировка, которая является разумным решением для этого сценария?

Answer 1

Когда я впервые услышал это, мне понравилась статья A Proposal for Proquints: Identifiers that are Readable, Spellable, and Pronounceable. Он кодирует данные как последовательность согласных и гласных. Однако это связано с английским языком. (Потому что на немецком языке f и v звук равный, поэтому их не следует использовать и так.) Но мне нравится общая идея.