A character set I like to use when I need something like this is the one used by Open Location Code, which is 23456789CFGHJMPQRVWX. It was apparently chosen not only to avoid visually ambiguous characters, but also to avoid spelling words in common languages. It does however include both 6 and G, as well as 9 and Q.
I have a different solution (that doesn’t really solve the problem completely): always use monospace fonts to display IDs, card numbers, usernames, passwords (when you click *show password), this includes when inputting them as well. It constantly frustrates me this isn’t the standard.
In most if not all monospace fonts you can distinguish the ambiguous characters fairly well with, admittedly a few exceptions, it’s far more distinguishable from all default sans-serif fonts.
I would like an encoding that uses the extra space in a larger alphabet for an error correcting code. Eg, you can fit over 37 bits in 8 letters, which is surely enough for 32 bits of data plus some useful error correction.
I guess this is implied in the OP, but I figure it’s worth explicitly calling out: depending on use-case, you may need to Care about (and thus be informed about and have veto over) downstream stuff like font and typography choices whenever your IDs (or codes/keys following similar rules) show up somewhere new or there’s a design refresh.
Even when you think you’ve chosen a fairly safe character set.
Being informed about uses before they ~ship isn’t usually essential, but the stakes go up if someone decides to print these IDs in, say, an invoice / billing statement / mailer / book / manual / quick start / device serial / certificate of authenticity and so on.
Source: generate 12-char codes with alphabet 02345679bcdfghjkmnpqrstvwxz. Approved 3 fonts with publisher for unambiguous layout of these in printed textbooks in 2014. In 2020 discovered they’d changed the font at some point without telling us. (This had happened for a while, but we only discovered it once codes with the ~wrong characters got printed and we eventually received enough reports of people with character confusion to decide it wasn’t complete PEBKAC.)
These problems included some people mistaking:
“q” for “g” (as OP outlines, we did ~invite this one–but the approved fonts did all have a clear bowled g)
I used this mostly successfully in a greenfield system where people sometimes needed to type in printed IDs (on labels, invoices, etc.). Our IDs were 10 characters, so I added the slight nuance that IDs are generated with hyphens after every five characters, to make them easier to read (hyphens not required for decoding, just encoding).
I recommend not using the special check characters and just adding a base 32 check digit from the main set.
My wish after that was to reduce verbal ambiguity by further limiting the character set, but I never got the time.
A character set I like to use when I need something like this is the one used by Open Location Code, which is
23456789CFGHJMPQRVWX. It was apparently chosen not only to avoid visually ambiguous characters, but also to avoid spelling words in common languages. It does however include both6andG, as well as9andQ.Thanks. Mentioned in Prior Art section https://gajus.com/blog/avoiding-visually-ambiguous-characters-in-ids#prior-art
It’s worth disambiguating “base32” because Crockford’s version is different from the two described in RFC 4648
What were font designers thinking when they made I and l look the same? seriously
Goodbye to barcode usernames like IIIlllIIlIlIlIlllIIllI
how am i gonna create burner accounts now!?
I have a different solution (that doesn’t really solve the problem completely): always use monospace fonts to display IDs, card numbers, usernames, passwords (when you click *show password), this includes when inputting them as well. It constantly frustrates me this isn’t the standard.
In most if not all monospace fonts you can distinguish the ambiguous characters fairly well with, admittedly a few exceptions, it’s far more distinguishable from all default sans-serif fonts.
Generating ids is only half the battle. You have to parse ids with incorrect characters as well.
I would like an encoding that uses the extra space in a larger alphabet for an error correcting code. Eg, you can fit over 37 bits in 8 letters, which is surely enough for 32 bits of data plus some useful error correction.
I guess this is implied in the OP, but I figure it’s worth explicitly calling out: depending on use-case, you may need to Care about (and thus be informed about and have veto over) downstream stuff like font and typography choices whenever your IDs (or codes/keys following similar rules) show up somewhere new or there’s a design refresh.
Even when you think you’ve chosen a fairly safe character set.
Being informed about uses before they ~ship isn’t usually essential, but the stakes go up if someone decides to print these IDs in, say, an invoice / billing statement / mailer / book / manual / quick start / device serial / certificate of authenticity and so on.
Source: generate 12-char codes with alphabet
02345679bcdfghjkmnpqrstvwxz. Approved 3 fonts with publisher for unambiguous layout of these in printed textbooks in 2014. In 2020 discovered they’d changed the font at some point without telling us. (This had happened for a while, but we only discovered it once codes with the ~wrong characters got printed and we eventually received enough reports of people with character confusion to decide it wasn’t complete PEBKAC.)These problems included some people mistaking:
Might be worth mentioning the Crockford Alphabet (the same Crockford who originally specified the JSON format).
I used this mostly successfully in a greenfield system where people sometimes needed to type in printed IDs (on labels, invoices, etc.). Our IDs were 10 characters, so I added the slight nuance that IDs are generated with hyphens after every five characters, to make them easier to read (hyphens not required for decoding, just encoding).
I recommend not using the special check characters and just adding a base 32 check digit from the main set.
My wish after that was to reduce verbal ambiguity by further limiting the character set, but I never got the time.
Would be interesting to use the local script, for things that are by definition for a local audience.
That would give us plenty more letters here.