最大限度地减少误读/错误输入/错误说出的编码？

Question

假设您有一个系统，其中一个相当长的键值可以通过屏幕，通过电子邮件或纸张准确地传达给用户;但是用户需要能够通过电话阅读，或者通过阅读并将其输入回其他界面来准确地将密钥传达给您。

什么是编码密钥的"好"方法，使阅读/听力/打字变得简单和准确？

这可以是发票号码，文档ID，交易ID或其他抽象值。为了讨论这个问题，假设基础键值是一个很大的数字，比如以10为基数的40位数字。

一些想法:

较短的键通常更好

• 一个40位的基数10值可能不适合给定的空间，并且很容易在
• 相同的值可以用33-34位的基数16表示
• 相同的值可以用26位数字以36为基数表示
• 相同的值可以用22-23位的基数64表示

在视觉上不能相互混淆的角色更好

• 例如包含O（oh）和0（零）或S（ess）和5（五）的编码可能是不好的
• 此问题取决于用于显示密钥的字体/面，您可能可以在某些情况下控制（如在纸上打印），但在其他情况下无法控制（如网页和电子邮件）。
• 还取决于您是否可以控制大写和/或小写的独家使用-例如大写D（dee）可能看起来像O（oh），但小写d（dee）不会;而小写l（ell）看起来像1（1），而大写L（ell）则不会。（特别是异国情调的字体/面孔除外）。

不能口头/耳语混淆的角色更好

• a(ay)8(八)
• B(bee)C(cee)D(dee)E(ee)g(gee)p(pee)t(tee)v(vee)z(zee)3(三)
• 这个问题取决于端到端信道的音频质量--如果预期的用户群可能有语音障碍，或者可能必须通过防毒面具说话，或者通信信道可能包括CB无线电或波涛汹涌的VOIP电话系统，则面临更大的挑战。

添加一两个校验位可以检测错误，但无助于解决错误。

Alpha-bravo-charlie-delta类型对话框可以帮助解决听力错误，但不能帮助解决阅读错误。

编码的可能选择:

• Base64--紧凑，但太多难以表达的字符（下划线，破折号等）。)
• 基数34--0-9和A-Z，但用O（oh）和I（aye）遗漏为最容易与数字混淆
• 基数32--与基数34相同，但也省略了0（零）和1（一）

是否有一种普遍认可的编码是这种情况的合理解决方案？

Answer 1

当我第一次听到它时，我喜欢这篇文章 提出建议:可读、拼写和发音的标识符.它将数据编码为辅音和元音序列。但它与英语有关。（因为在德语中, f 和 v 听起来相等，所以它们不应该同时使用。）但我喜欢一般的想法。