3 ms·
> 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
by BugsJustFindMe 8y ago
> 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 https://www.crockford.com/wrmg/base32.html
- grzm 8y agoCrockford 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.”
- BugsJustFindMe 8y agoG/6, B/8, Z/2, and S/5 are much more likely to actually be visually ambiguous than L/1.
- ivan_gammel 8y ago1/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.
- BugsJustFindMe 8y agoAll 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.
- ivan_gammel 8y ago>All codes are encoded only to uppercase. False. ULID specification clearly says that these identifiers are case-insensitive. There's no "uppercase" requirement anywhere.
- jacobr1 8y agocrockford3 accepts any case, but the canonical output is uppercase
- deleted 8y ago[deleted]
- cheald 8y agoI 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.
- RcouF1uZ4gsC 8y agoI have confused these when they were handwritten, but not in typed form in a reasonable font.
- AaronFriel 8y agoYou 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?
- gliptic 8y agoYou 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.
- BugsJustFindMe 8y ago> 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)
- gliptic 8y agoI'm pretty sure l looks like I more frequently than 5 looks like S. You have to draw the line somewhere.
- throw_away2 8y agoit's a1so very different in monospaced fonts where these identifiers are 1ike1y to be read. 'l' 1ooks much more 1ike '1' in these fonts.
- Solar19 8y agoCrockford 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?