このアイデアを使用しないでください：自動呪いジェネレーター:)
Bubble Babbleは試してみるのに適しています。次のような無意味ですが読みやすい出力が生成されます。
xesef-disof-gytuf-katof-movif-baxux
PGPが読み取り可能なキーを作成するのと同じようなものを使用してみませんか。特徴的な単語のリストを見つけてください。たとえば、128ビットのUUIDを使用している場合、256単語（2 ^ 8）のリストは16単語を意味します。
ばかげた質問ですが、なぜ人々はUUIDなどを読み書きしているのですか。あなたのアプリケーションに関して？
この質問は非常に古いものです。興味深いことに、これから紹介するソリューションと同じくらい古いものですが、ここではまだ言及されていません。
プロキントです。Bubble Babble に似ていますが、私の意見では、この違いにより結果が読みやすくなっています。
ドキュメントからの仕組みは次のとおりです。
要約すると、次のように、子音と母音を交互に並べた proquint [PRO 名詞化可能 QUINT-uplet] として 16 ビット文字列をエンコードすることを提案します。
子音としての 4 ビット:
0 1 2 3 4 5 6 7 8 9 A B C D E F b d f g h j k l m n p r s t v z母音としての 2 ビット:
0 1 2 3 a i o u"con" = 子音、"vo" = 母音の 16 ビット ワード全体:
0 1 2 3 4 5 6 7 8 9 A B C D E F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |con |vo |con |vo |con | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ダッシュを使用して proquint を区切ります。これは、発音されないか、「えー」と発音される可能性があります。proquint のシーケンスに推奨されるオプションのマジック ナンバー プレフィックスは「0q-」です。
以下は、いくつかの IP ドット付きクワッドとそれに対応するプロキントです。
127.0.0.1 lusab-babad 63.84.220.193 gutih-tugad 63.118.7.35 gutuk-bisog 140.98.193.141 mudof-sakat 64.255.6.200 haguz-biram 128.30.52.45 mabiv-gibot 147.67.119.2 natag-lisaf 212.58.253.68 tibup-zujah 216.35.68.215 tobog-higil 216.68.232.21 todah-vobij 198.81.129.136 sinid-makam 12.110.110.204 budov-kuras
16 進数値を読みやすく伝える方法だけが必要な場合 (つまり、電話で、または入力する内容を口頭で誰かに指示する場合)、NATO フォネティック アルファベットやUSなどのさまざまなフォネティック アルファベットのいずれかを使用することをお勧めします。陸軍/海軍の音声記号。
後者では、AF の文字はそれぞれ「able」、「baker」、「charlie」、「dog」、「easy」、「fox」と読み上げられるため、16 進シーケンス「3fd2cc0e」を「three」と読むことになります。フォックス・ドッグ・トゥー・チャーリー チャーリー・ゼロ・イージー」. uuid はまったく同じ方法で読み取られます。
特にあなたの場合、バブルバブルとbase32は非効率的です。独自のアルゴリズムを作成することをお勧めします。子音は 20 個、母音は 6 個 (「y」を含む) あるため、約 20*6*2+6*6=276 の子音/母音/子音のペア。したがって、数値のすべてのバイトをペアで表すことができます。アルゴリズムを少し調整すると、バブルバブルよりもはるかに短い発音可能な単語を生成できます。サイコロを振って、すべての奇数桁を子音/母音に置き換えることもできます。たとえば、0123456789ABCDEF (16 進数) は ABECIDOFUGYHKRM にエンコードされます。3141592654 (dec) は HHIA-ROIR にエンコードされます。母音とペアにしていくつかの二重子音などを置き換えることができる10個の予備の子音が残されています.
うまくいけば、少しの圧縮
あなたが何を意味するのか正確にはわかりません。「読みやすい」または「発音しやすい」ものを作成すると、それに必要なスペースが必然的に拡大します。たぶん、「できれば少しの冗長性」を意味していましたか？ユーザーが小さな間違いを犯したとしても、システムがそれを検出し、場合によっては修正することさえできればよいのです。
実際には、UUID の大きさと、それらが最も頻繁に伝達される方法に大きく依存します。電話または VoIP で通信する必要がある場合は、より多くの可聴冗長性が必要です。テンキーを備えたモバイル デバイスに入力する必要がある場合、アルファベット文字は入力しにくくなる傾向があり、大文字と小文字が区別される場合はなおさらです。それらがたくさん書き留められている場合は、似ている文字 (たとえば、O と 0 と O) に注意する必要があります。暗記する必要がある場合は、おそらく実際の単語の文字列が最適です ( PGP Word Listを参照してください)。
ただし、万能の優れたソリューションは、数字を使用することだと思います。これらは、一部のアルファベット文字よりも (話し言葉と書き言葉の両方で) 互いに混同するのがはるかに困難です。携帯端末で簡単に入力でき、数字を覚えるのが苦手な人もいません。
また、紐の長さも悪くありません。base32 と base10 (10 進数) を比較してみましょう。10 進文字列log_10(32)の長さは、対応する base32 文字列の長さの倍、つまり約 1.5 倍です。base32 の 10 文字は、10 進数の 15 桁に相当します。
たいしたペナルティではありませんが、32 進法では C と T、または S、F と X (話された場合) を混同しやすく、外国のアクセントで話す人は問題を引き起こす可能性が高くなります。
それらが読みやすいのであれば、おそらく特にユニークではないでしょう。