Кодировка, которая сводит к минимуму неправильное прочтение / опечатки / неправильный перевод? - PullRequest
5 голосов
/ 09 марта 2012

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

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

Это может быть номер счета, идентификатор документа, идентификатор транзакции или другое абстрактное значение. Допустим, ради этого обсуждения базовое значение ключа представляет собой большое число, скажем, 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 (пчела) C (cee) D (ди) E (ee) g (gee) p (pee) t (tee) v (vee) z (zee) 3 (три)
  • Эта проблема зависит от качества звука сквозного канала - более сложная задача, если ожидаемая абонентская база может иметь речевую помеху или, возможно, придется говорить через противогаз или канал связи может включать CB радио или прерывистые телефонные системы VOIP.

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

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

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

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

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

1 Ответ

0 голосов
/ 29 мая 2014

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

...