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

Question

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

Каков «хороший» способ закодировать ключ, чтобы его было легко и точно читать/слышать/печатать?

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

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

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

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

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

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

Персонажи, которых невозможно спутать на слух/вербально, лучше

• а (ау) 8 (восемь)
• B (пчела) C (си) D (ди) E (ее) г (ги) p (пи) t (тройник) v (ви) z (зи) 3 (три)
• Эта проблема зависит от качества звука в сквозном канале. Более сложная задача, если ожидаемая база пользователей может иметь проблемы с речью, или ей придется говорить через противогаз, или канал связи может включать CB-радиоприемники или прерывистые каналы связи. VOIP телефонные системы.

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

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

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

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

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

Answer 1

Когда я впервые услышал об этом, статья мне понравилась. Предложение для Proquints:Идентификаторы, которые можно читать, писать и произносить.Он кодирует данные как последовательность согласных и гласных.Хотя это связано с английским языком.(Потому что в немецком языке f и v звучат одинаково, поэтому их не следует использовать оба.) Но общая идея мне нравится.