5
かなり長いキー値を電子メールや紙で画面上でユーザーに正確に伝えることができるシステムがあるとします。ユーザは、電話でそれを読むことによって、またはそれを読んで、それを他のインタフェースに戻して、キーを正確に伝えることができる必要があります。誤読/ミスタイプ/ミスピークを最小限に抑えるエンコーディングですか？
読み取り/聴覚/入力を容易にするためにキーをエンコードする「良い」方法は何ですか？&は正確ですか？
これは、請求書番号、文書ID、取引IDまたはその他の抽象的な値です。のは、基礎となるキー値が大きな数である。この議論のために言ってみましょう、ベースにある40桁の10
いくつかの考えを言う：
短い鍵は一般的に優れている
- 40 -digit base 10の値が与えられたスペースに収まらず、途中で紛失しやすい
- 同じ値が33〜34桁で16進数で表現できる
- より良好な26桁
- にベース36に示される同一の値が互いに視覚的に混乱することができない22-23数字
文字がベース64で表すことができるされ
- 例えばO（oh）と0（ゼロ）、またはS（ess）と5（five）の両方を含むエンコーディングが悪い可能性があります。
- この問題は、キーを表示するために使用されるフォント/場合によっては（紙に印刷するなど）制御できるが、他のページ（Webページや電子メールなど）では制御できない。
- また、大文字/小文字の排他使用を制御できるかどうかによっても異なります。大文字D（ディ）はO（あ）のように見えるかもしれないが、小文字d（ディ）はそうではない。小文字のl（ell）は1（1）のように見えますが、大文字のL（ell）はそうではありません。 （特にエキゾチックなフォント/面の例外を除いて）。互いに口頭/聴覚的に混乱することができない
文字（AY）8（8）
- 優れていますE（EE）G（ジー）P（おしっこ）T（ティー）V（ヴィー）Z（ジー）3（3）この問題は、エンドツーエンドのチャンネルのオーディオ品質に依存
- - 大きな挑戦予想されるユーザベースが音声障害を有する可能性がある場合、またはガスマスクを介して発言する必要がある場合、または通信チャネルにCB無線またはホッピングVOIP電話システムを含めることができる。
エラーの解決に役立つエラーを検出しなくなり、チェック桁または2を追加します。
アルファ - ブラボー - チャーリー - デルタ型ダイアログは、聴覚エラーで助けるが、エラーを読み込むことができません。符号の
選択肢：
- ベース64 - コンパクト、あまりにも多くのハード・ツー・言葉で表現文字（下線などダッシュ）
- ベース34 - 0-9と（0）と1（1）も除外します。
- ベース32 - ベース34と同じですが、0（ゼロ）と1（1）も除外します。
Iこのシナリオでは合理的な解決策である一般的に認識されているエンコードがありますか？
ICAO（http://en.wikipedia.org/wiki/NATO_phonetic_alphabet）を使用しますか？ – ninjalj