Я использую UUID, но они не особенно приятны для чтения, записи и общения. Поэтому я хотел бы их закодировать. Я мог бы использовать base64 или base32, но в любом случае им было бы нелегко: base64 имеет заглавные буквы и символы. Base32 немного лучше, но вы все равно можете получить неуклюжие вещи.
Мне было интересно, есть ли хороший и чистый способ кодировать число в приятные фонемы, поэтому для достижения большей удобочитаемости и, надеюсь, немного сжатия.
Bubble Babble - это хорошая попытка попробовать. Он генерирует бессмысленный, но читаемый вывод, например:
xesef-disof-gytuf-katof-movif-baxux
Надеюсь, вы не используете эту идею: Автоматизированный генератор проклятия:)
Почему бы не использовать что-то похожее на то, что PGP делает для создания читаемых ключей, просто найдите хороший список слов, которые являются отличительными, скажем, вы используете 128-битные UUID, список из 256 слов (2 ^ 8) означает 16 слова.
Глупый вопрос, но почему люди читают/пишут UUID/etc. в отношении вашей заявки?
Если все, что вам нужно, - это способ чтения шестнадцатеричных значений (т.е. по телефону или при указании кому-то словесно, что набирать), то я предлагаю вам использовать один из различных фонетических алфавитов, например Фонетический алфавит НАТО или
S/KEY использует словарь из 2048 слов для сопоставления 64-битных чисел с последовательностью 6 предопределенные слова/слоги. (Люди всегда будут искать ругательства, если они ищут их;))
Bubble babble и base32 неэффективны, особенно в вашем случае. Я предлагаю вам сделать свой собственный алгоритм. Поскольку имеется 20 согласных и 6 гласных (включая "y" ), вы можете иметь ок. 20 * 6 * 2 + 6 * 6 = 276 согласных/гласных гласных/согласных пар. Таким образом, каждый байт вашего номера может быть представлен парой. С небольшим количеством настроек ваш алгоритм мог бы произносить произносимые слова намного короче, чем болтовня пузыря. Вы даже можете сыграть в кости и заменить все нечетные цифры согласным/гласным. Например, 0123456789ABCDEF (hex) кодирует ABECIDOFUGYHKRM. 3141592654 (dec) кодирует HHIA-ROIR. У вас осталось десять запасных согласных, которые могут быть соединены с гласными, чтобы заменить несколько двойных согласных и т.д.
и, надеюсь, немного сжатия
Не уверен, что вы имеете в виду; что-то "читаемое" или "произносимое" неизбежно расширит пространство, необходимое для этого. Может быть, вы имели в виду "надеюсь, немного избыточность"? Было бы хорошо, если даже если пользователь совершит небольшую ошибку, система может обнаружить и, возможно, даже исправить ее.
На самом деле это сильно зависит от того, насколько велики ваши UUID и как они чаще всего сообщаются. Если их нужно обменивать по телефону или VoIP, вам нужно больше слышимого резервирования. Если их нужно вводить в мобильные устройства с числовыми клавиатурами, бывает сложно вводить буквенные символы, например, если они чувствительны к регистру. Если они записаны много, вам нужно беспокоиться о персонажах, которые выглядят одинаково (например, O и 0 и o). Если их нужно запомнить, то, вероятно, строки реальных слов являются лучшими (посмотрите Список слов PGP).
Однако я считаю, что отличное всестороннее решение просто использует числовые цифры. Их гораздо сложнее смешивать друг с другом (как в разговорах, так и в письменной форме), чем с некоторыми алфавитными символами. Легко вводить на мобильные устройства, и люди не так уж плохо запоминают номера.
И длина строки тоже не так уж плоха. Пусть сравните base32 с базой 10 (десятичной). Длина десятичной строки равна log_10(32) times length соответствующей строки base32 или примерно в 1,5 раза длиннее. Десять символов base32 соответствуют 15 десятичным знакам.
Не так много наказания, ИМО, видя, как в базе 32, легко спутать C и T, или S, F и X (когда говорят), а кто-то, говорящий с иностранным акцентом, скорее всего вызовет проблемы.
Если бы их было легко читать, они, вероятно, не были бы особенно уникальными.