Set of unambiguous looking letters & numbers for user input

Brian_M_Hunt_19212 0
Viewed 21902

Is there an existing subset of the alphanumerics that is easier to read? In particular, is there a subset that has fewer characters that are visually ambiguous, and by removing (or equating) certain characters we reduce human error?

I know "visually ambiguous" is somewhat waffly of an expression, but it is fairly evident that D, O and 0 are all similar, and 1 and I are also similar. I would like to maximize the size of the set of alpha-numerics, but minimize the number of characters that are likely to be misinterpreted.

The only precedent I am aware of for such a set is the Canada Postal code system that removes the letters D, F, I, O, Q, and U, and that subset was created to aid the postal system's OCR process.

My initial thought is to use only capital letters and numbers as follows:

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

This problem may be difficult to separate from the given type face. The distinctiveness of the characters in the chosen typeface could significantly affect the potential visual ambiguity of any two characters, but I expect that in most modern typefaces the above characters that are equated will have a similar enough appearance to warrant equating them.

I would be grateful for thoughts on the above – are the above equations suitable, or perhaps are there more characters that should be equated? Would lowercase characters be more suitable?

typography hid character
10 Answers

My set of 23 unambiguous characters is:

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

I needed a set of unambiguous characters for user input, and I couldn't find anywhere that others have already produced a character set and set of rules that fit my criteria.

My requirements:

  1. No capitals: this supposed to be used in URIs, and typed by people who might not have a lot of typing experience, for whom even the shift key can slow them down and cause uncertainty. I also want someone to be able to say "all lowercase" so as to reduce uncertainty, so I want to avoid capital letters.

  2. Few or no vowels: an easy way to avoid creating foul language or surprising words is to simply omit most vowels. I think keeping "e" and "y" is ok.

  3. Resolve ambiguity consistently: I'm open to using some ambiguous characters, so long as I only use one character from each group (e.g., out of lowercase s, uppercase S, and five, I might only use five); that way, on the backend, I can just replace any of these ambiguous characters with the one correct character from their group. So, the input string "3Sh" would be replaced with "35h" before I look up its match in my database.

  4. Only needed to create tokens: I don't need to encode information like base64 or base32 do, so the exact number of characters in my set doesn't really matter, besides my wanting to to be as large as possible. It only needs to be useful for producing random UUID-type id tokens.

  5. Strongly prefer non-ambiguity: I think it's much more costly for someone to enter a token and have something go wrong than it is for someone to have to type out a longer token. There's a tradeoff, of course, but I want to strongly prefer non-ambiguity over brevity.

The confusable groups of characters I identified:

  • A/4
  • b/6/G
  • 8/B
  • c/C
  • f/F
  • 9/g/q
  • i/I/1/l/7 - just too ambiguous to use; note that european "1" can look a lot like many people's "7"
  • k/K
  • o/O/0 - just too ambiguous to use
  • p/P
  • s/S/5
  • v/V
  • w/W
  • x/X
  • y/Y
  • z/Z/2

Unambiguous characters:

I think this leaves only 9 totally unambiguous lowercase/numeric chars, with no vowels:

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

Adding back in one character from each of those ambiguous groups (and trying to prefer the character that looks most distinct, while avoiding uppercase), there are 23 characters:

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

Analysis:

Using the rule of thumb that a UUID with a numerical equivalent range of N possibilities is sufficient to avoid collisions for sqrt(N) instances:

  • an 8-digit UUID using this character set should be sufficient to avoid collisions for about 300,000 instances
  • a 16-digit UUID using this character set should be sufficient to avoid collisions for about 80 billion instances.
user_23081900

If you have the option to use only capitals, I created this set based on characters which users commonly mistyped, however this wholly depends on the font they read the text in.

Characters to use: 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

Characters to avoid:

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

Unambiguous looking letters for humans are also unambiguous for optical character recognition (OCR). By removing all pairs of letters that are confusing for OCR, one obtains:

 !+2345679:BCDEGHKLQSUZadehiopqstu

See https://www.monperrus.net/martin/store-data-paper

user_11534760

base58:123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

user_16875270
Related