编码可以最大限度地减少误读/错误输入/错误提示?

时间:2012-03-09 18:36:02

标签: encoding character-encoding error-correction human-readable

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

对键进行编码的“好”方式是什么,使阅读/听觉/打字变得简单和放大准确吗

这可以是发票号,文档ID,交易ID或其他一些抽象值。让我们说,为了讨论这个问题,基础密钥值是一个很大的数字,比如基数为10的数字。

一些想法:

更短的键通常更好

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

不能在视觉上彼此混淆的角色更好

  • e.g。包含O(oh)和0(零),或S(ess)和5(五)的编码可能不好
  • 此问题取决于用于显示密钥的字体/面,在某些情况下您可以控制(例如在纸上打印)但在其他情况下无法控制(如网页和电子邮件)。
  • 还取决于您是否可以控制上壳和/或下壳的专用 - 例如资本D(dee)可能看起来像O(哦)但是小写d(dee)不会;小写l(ell)看起来像1(一),而大写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(3)
  • 此问题取决于端到端频道的音质 - 如果预期的用户群可能存在语音障碍,或者可能需要通过防毒面具讲话,或者通信渠道可能包含CB,则会遇到更大的挑战无线电或波涛汹涌的VOIP电话系统。

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

alpha - bravo - charlie - delta类型对话框可以帮助解决听力错误,但不会有读错误。

可能的编码选择:

  • Base 64 - 紧凑,但有太多难以言语化的角色(下划线,短划线等)。
  • Base 34 - 0-9和A-Z但是O(oh)和I(aye)被遗漏为最容易混淆的数字
  • Base 32 - 与base 34相同,但也忽略0(零)和1(一)

对于这种情况,是否存在公认的编码是合理的解决方案?

1 个答案:

答案 0 :(得分:0)

当我第一次听到它时,我喜欢文章A Proposal for Proquints: Identifiers that are Readable, Spellable, and Pronounceable。它将数据编码为辅音和元音序列。它虽然与英语联系在一起。 (因为在德语中,fv听起来相同,所以不应该同时使用它们。)但我喜欢这个概念。