假设您有一个系统，其中相当长的键值可以通过电子邮件或纸质在屏幕上准确地传达给用户；但是用户需要能够通过电话阅读或通过阅读并将其输入回某个其他界面来准确地将密钥传达给您。
什么是对密钥进行编码以使阅读/听力/打字变得容易和准确的“好”方法？
这可以是发票编号、文档 ID、交易 ID 或其他一些抽象值。假设为了讨论，底层键值是一个大数字，比如以 10 为底的 40 位数字。
一些想法：
较短的键通常更好
- 一个 40 位的以 10 为底的值可能不适合给定的空间，并且很容易在中间迷失
- 相同的值可以用 33-34 位以 16 为基数表示
- 相同的值可以以 36 为基数以 26 位表示
- 相同的值可以用 22-23 位的 base 64 表示
不能在视觉上相互混淆的字符更好
- 例如，同时包含 O（哦）和 0（零）或 S（ess）和 5（五）的编码可能不好
- 此问题取决于用于显示密钥的字体/外观，在某些情况下您可能能够控制（例如在纸上打印）但在其他情况下无法控制（例如网页和电子邮件）。
- 还取决于您是否可以控制大写和/或小写的独占使用——例如大写的 D (dee) 可能看起来像 O (oh) 但小写的 d (dee) 不会；而小写 l (ell) 看起来像 1 (one) 而大写 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 类型的对话框可以帮助解决听力错误，但不能帮助解决阅读错误。
可能的编码选择：
- Base 64——紧凑，但有太多难以表达的字符（下划线、破折号等）
- Base 34 -- 0-9 和 AZ 但 O (oh) 和 I (aye) 最容易与数字混淆
- 基数 32 - 与基数 34 相同，但也省略了 0（零）和 1（一）
是否有公认的编码是这种情况的合理解决方案？