Hacker News Reader

Comment by BugsJustFindMe | Hacker News Reader

> Uses Crockford's base32 for better efficiency and readability

Ugh. Crockford's base32 character set doesn't actually solve any of the problems it sets out to solve. Using it suggests to me some uncritical thinking.

It[0] says things like L is excluded, because "[uppercase] L Can be confused with 1". Ignoring the part where that is wildly inaccurate for any font that I've ever seen, why not then also remove G, 6, B, 8, Z, 2, S, or 5?

Reducing 1/I/i/L/l to just 1 does little to resolve visual ambiguity for users, because a user could just as easily read l or I instead of 1 or O instead of 0, because users don't know your made-up rules, which causes real problems because you often don't control both sides of the channel.

[0] - https://www.crockford.com/wrmg/base32.html

View on HN

Crockford Base32 folds those ambiguous characters on reading: l, L, I, and i are treated as 1; o and O are treated as 0. The user doesn’t need to know the rules.

From the page you quote:

> ”When decoding, upper and lower case letters are accepted, and i and l will be treated as 1 and o will be treated as 0. When encoding, only upper case letters are used.”

G/6, B/8, Z/2, and S/5 are much more likely to actually be visually ambiguous than L/1.

1/l is visually ambiguous. Since the encoding is case-insensitive, upper-case L must also be excluded. For the same reason lower-case L is not included in Base58.

All codes are encoded only to uppercase in crockford32. If you actually want to get rid of the ambiguity, get rid of 1 and keep L.

>All codes are encoded only to uppercase.

False. ULID specification clearly says that these identifiers are case-insensitive. There's no "uppercase" requirement anywhere.

crockford3 accepts any case, but the canonical output is uppercase

I have never typo'd a G for a 6, but I sure am glad my password manager shows digits in a different color from letters, because I confuse l/1/I and O/0 all the time.

I have confused these when they were handwritten, but not in typed form in a reasonable font.

You didn't read very carefully. 1/I/i/L/l are all interpreted as 1, so it doesn't matter which one they are misreading it as. Do you contest that l can be misread as 1 or I? Because that's what the table means. The code is case-insensitive.

> Do you contest that l can be misread as 1 or I?

I declare that 5 can be misread as S and yet there they are. (And that L looks like 1 or I far less frequently than 5 looks like S)

I'm pretty sure l looks like I more frequently than 5 looks like S. You have to draw the line somewhere.

  it's a1so very different in monospaced fonts where these
  identifiers are 1ike1y to be read.  'l' 1ooks much more
  1ike '1' in these fonts.

Crockford also excludes the letter U, because of potential profanity, which I find incredibly odd. He's afraid of a rare FU embedded somewhere in an ID? Why would we care about that?

You seem upset.

Aren't your complaints solved by simply having the parser resolve inputs 1/I/i/L/l to the symbol 1, and inputs 0/O to the symbol 0?

Reply on news.ycombinator.com