【发布时间】：2012-03-09 18:36:02
【问题描述】：
假设您有一个系统，其中相当长的键值可以通过电子邮件或纸质在屏幕上准确地传达给用户；但是用户需要能够通过电话阅读或通过阅读并将其输入回某个其他界面来准确地将密钥传达给您。
对密钥进行编码以使阅读/听力/打字变得容易和准确的“好”方法是什么？
这可以是发票编号、文档 ID、交易 ID 或其他一些抽象值。假设为了讨论，底层键值是一个大数字，比如以 10 为底的 40 位。
一些想法：
键越短越好
- 40 位以 10 为底的值可能不适合给定的空间，并且很容易在中间迷路
- 相同的值可以用 33-34 位以 16 进制表示
- 相同的值可以以 36 为基数以 26 位表示
- 相同的值可以用 22-23 位的 64 进制表示
不能在视觉上相互混淆的字符更好
- 例如同时包含 O（哦）和 0（零）或 S（ess）和 5（五）的编码可能是错误的
- 此问题取决于用于显示密钥的字体/外观，在某些情况下您可能能够控制（例如在纸上打印）但在其他情况下无法控制（例如网页和电子邮件）。李>
- 还取决于您是否可以控制大写和/或小写的独占使用——例如大写的 D (dee) 可能看起来像 O (oh) 但小写的 d (dee) 不会；而小写 l (ell) 看起来像 1 (one) 而大写 L (ell) 则不会。 （特别奇特的字体/面孔除外）。
不能在口头/听觉上相互混淆的字符更好
- a (ay) 8 (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 和 A-Z，但 O (oh) 和 I (aye) 最容易与数字混淆
- 基数 32 -- 与基数 34 相同，但也省略了 0（零）和 1（一）
对于这种情况，是否有一种普遍认可的编码是合理的解决方案？
【问题讨论】：
-
使用国际民航组织 (en.wikipedia.org/wiki/NATO_phonetic_alphabet)？
标签： encoding character-encoding error-correction human-readable