Кодирование, которое сводит к минимуму неправильное прочтение/опечатку/опечатку?
-
10-12-2019 - |
Вопрос
Допустим, у вас есть система, в которой довольно длинное значение ключа может быть точно сообщено пользователю на экране, по электронной почте или на бумаге;но пользователь должен иметь возможность точно передать вам ключ, прочитав его по телефону или прочитав его и введя обратно в какой-либо другой интерфейс.
Каков «хороший» способ закодировать ключ, чтобы его было легко и точно читать/слышать/печатать?
Это может быть номер счета, идентификатор документа, идентификатор транзакции или какое-либо другое абстрактное значение.Допустим, в целях обсуждения базовое значение ключа представляет собой большое число, скажем, 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 (единица).
Существует ли общепризнанная кодировка, которая является разумным решением для этого сценария?
Решение
Когда я впервые услышал об этом, статья мне понравилась. Предложение для Proquints:Идентификаторы, которые можно читать, писать и произносить.Он кодирует данные как последовательность согласных и гласных.Хотя это связано с английским языком.(Потому что в немецком языке f
и v
звучат одинаково, поэтому их не следует использовать оба.) Но общая идея мне нравится.