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

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

Что такое "хороший" способ кодирования ключа, чтобы сделать чтение / слух / ввод его легким и точным?

Это может быть номер счета, идентификатор документа, идентификатор транзакции или другое абстрактное значение. Давайте предположим, что для этого обсуждения базовым значением ключа является большое число, скажем, 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) не будет. (За исключением особо экзотических шрифтов / граней).

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

• a (ay) 8 (восемь)
• B (bee) C (cee) D (dee) E (ee) g (Джи) п (Пи) Т (ти) в (ви) з (Зи) 3 (три)
• эта проблема зависит от качества звука сквозного канала - более сложная задача, если ожидаемая пользовательская база может иметь дефект речи, или может говорить через противогаз, или канал связи может включать радио CB или прерывистые телефонные системы VOIP.

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

Диалог типа Альфа - Браво - Чарли - дельта может помочь с ошибки слуха,но не чтения.

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

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

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