一组明确的外观字母和数字为用户输入

Question

是否有现有的字母数字子集更容易阅读？特别是,是否有一个子集具有较少的视觉模糊字符,通过删除(或等同)某些字符,我们减少了人为错误？

我知道"视觉模糊"在某种程度上是一种表达方式,但很明显D,O和0都是相似的,1和I也是相似的.我想最大化alpha-numerics集的大小,但最大限度地减少可能被误解的字符数.

我所知道的唯一先例是加拿大邮政编码系统,它删除字母D,F,I,O,Q和U,并创建该子集以帮助邮政系统的OCR过程.

我最初的想法是只使用大写字母和数字如下:

A
B = 8
C = G
D = 0 = O = Q
E = F
H
I = J = L = T = 1 = 7
K = X
M
N
P
R
S = 5
U = V = Y
W
Z = 2
3
4
6
9

这个问题可能难以与给定的类型面分开.所选字体中字符的独特性可能会显着影响任何两个字符的潜在视觉模糊性,但我希望在大多数现代字体中,等同的上述字符将具有相似的足够外观以保证等同它们.

我对以上的想法感激不已 - 以上方程是否合适,或者是否有更多应该等同的字符？小写字符会更合适吗？

Answer 1

主要从@rwb提到的这个ux线程中汲取灵感,

• 有些 程序使用类似的东西.您的帖子中的列表似乎与这些程序中使用的列表非常相似,我认为它应该足以满足大多数目的.您可以添加始终添加冗余(纠错)以"原谅"轻微错误; 但是,这将要求您将代码空出(参见汉明距离).
• 没有关于用于推导列表的特定方法的参考,除了与人类的试验和错误(非常适合非ocr:您的用户是人类)
• 使用字符分组(例如,5个组)来增加上下文("5组中第二个中的第一个字符")可能是有意义的
• 使用完整的名词(来自字典,几乎没有相似之处;字编辑距离在这里可能很有用)而不是字符,可以消除歧义.人们可能会混淆"1"和"我",但很少会将"一"与"冰"混淆.
• 另一个选择是将您的代码变成一个可以大声读出的(假)字.一个马尔可夫模型可以帮助你.

Answer 2

出于类似的原因,我需要替换十六进制(基数为16)(例如,对于密钥编码等),我能想到的最好的是以下16个字符集,可以用作十六进制的替换:

0 1 2 3 4 5 6 7 8 9 A B C D E F     Hexadecimal
H M N 3 4 P 6 7 R 9 T W C X Y F     Replacement

在替换集中,我们考虑以下内容:

所有使用的字符都具有主要的区别特征,只能在真正糟糕的字体中省略.

元音AEIOU省略以避免意外拼写单词.

完全避免在某些字体中可能非常相似或相同的字符集(根本不使用任何集合中的字符):

0 O D Q 
1 I L J
8 B 
5 S
2 Z

通过完全避免这些字符,希望用户将输入正确的字符,而不是尝试纠正错误输入的字符.

对于不那么相似但可能令人困惑的字符集,我们在每个集合中只使用一个字符,希望最有特色:

Y U V 

这里使用了Y,因为它总是具有较低的垂直部分,以及衬线字体的衬线

C G         

这里使用C,因为C似乎不太可能作为G输入,反之亦然

X K         

这里使用X,因为它在大多数字体中更加一致

F E         

这里使用F,因为它不是元音

在这些类似集合的情况下,集合中任何字符的输入可以自动转换为实际使用的字符(每个集合中列出的第一个字符).请注意,如果可能使用十六进制输入,则不得将E自动转换为F(参见下文).

请注意,替换集中仍然存在类似声音的字母,这几乎是不可避免的.大声朗读时,应使用语音字母.

在替换集中使用标准十六进制中也存在的字符时,它们用于相同的base-16值.理论上,如果E不自动转换为F,则可以支持十六进制和替换字符的混合输入.

由于这只是一个字符替换,因此应该很容易转换为十六进制/从十六进制转换.

大写似乎最适合输出的"规范"形式,虽然小写也看起来合理,除了"h"和"n",在大多数字体中仍然应该相对清晰:

h m n 3 4 p 6 7 r 9 t w c x y f

输入当然可以不区分大小写.

基本32有几个类似的系统,请参阅http://en.wikipedia.org/wiki/Base32然而,这些显然需要引入更多相似的字符,以换取每个字符额外25%的信息.

显然,以下集合也用于基础24中的Windows产品密钥,但同样具有更多相似的字符:

B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9

Answer 3

我的 23 个明确字符集是：

c,d,e,f,h,j,k,m,n,p,r,t,v,w,x,y,2,3,4,5,6,8,9

我需要一组明确的字符用于用户输入，但我找不到其他人已经生成符合我的标准的字符集和规则集的任何地方。

我的要求：

1. 没有大写字母：这应该用在 URI 中，并且由可能没有很多打字经验的人打字，对他们来说，即使是 shift 键也会减慢他们的速度并导致不确定性。我也希望有人能够说“全部小写”以减少不确定性，所以我想避免大写字母。

2. 很少或没有元音：避免制造粗口或令人惊讶的词的简单方法是简单地省略大多数元音。我认为保留“e”和“y”是可以的。

3. 始终如一地解决歧义：我愿意使用一些歧义字符，只要我只使用每组中的一个字符（例如，小写 s、大写 S 和五个，我可能只使用五个）；这样，在后端，我可以用他们组中的一个正确字符替换这些含糊不清的字符中的任何一个。因此，在我在数据库中查找匹配项之前，输入字符串“3Sh”将被替换为“35h”。

4. 只需要创建令牌：我不需要像 base64 或 base32 那样编码信息，所以我的集合中的确切字符数并不重要，除了我希望尽可能大之外。它只需要用于生成随机 UUID 类型的 id 令牌。

5. 强烈更喜欢无歧义：我认为某人输入一个令牌并出现问题比某人必须输入更长的令牌要昂贵得多。当然，有一个权衡，但我更喜欢非歧义而不是简洁。

我确定的易混淆的字符组：

• A/4
• b/6/G
• 8/B
• 碳/碳
• 女/女
• 9/g/q
• i/I/1/l/7 - 使用起来太模棱两可；请注意，欧洲的“1”可能看起来很像许多人的“7”
• 千/千
• o/O/0 - 使用起来太模棱两可
• 点/点
• 秒/秒/5
• 体积/体积
• 瓦/瓦
• ×/ ×
• 年/年
• z/Z/2

明确的字符：

我认为这仅留下 9 个完全明确的小写/数字字符，没有元音：

d,e,h,j,m,n,r,t,3

从每个含糊不清的组中添加一个字符（并尝试选择看起来最独特的字符，同时避免大写），有 23 个字符：

c,d,e,f,h,j,k,m,n,p,r,t,v,w,x,y,2,3,4,5,6,8,9

分析：

根据经验，具有 N 个可能性的数值等效范围的 UUID 足以避免 sqrt(N) 实例发生冲突：

• 使用此字符集的 8 位 UUID 应该足以避免大约 300,000 个实例的冲突
• 使用此字符集的 16 位 UUID 应该足以避免大约 800 亿个实例的冲突。

Answer 4

如果您可以选择仅使用大写字母，我会根据用户经常输入错误的字符创建此集合，但这完全取决于他们阅读文本时使用的字体。

使用的字符： A C D E F G H J K L M N P Q R T U V W X Y 3 4 6 7 9

要避免的字符：

B similar to 8
I similar to 1
O similar to 0
S similar to 5
Z similar to 2