3 ms·
I have only one complaint about this Base32 encoding choice, and it stems from the fact that I prefer to encode Base32 using lower case letters, instead of the
by keithlfrost 6y ago
I have only one complaint about this Base32 encoding choice, and it stems from the fact that I prefer to encode Base32 using lower case letters, instead of the choice made here to make upper case canonical. When using lower case, the main source of possible confusion is that it can be difficult to tell l and 1 apart, as in l1l1l1l... and this scheme uses both l (canonically "L") and 1.
- edoceo 6y agoHmm, other base32 system avoid that by not including I and L (and O) - and some other refs I've read (ULID comes to mind) say produce UPPER output but accept either case input. And, like this spec, the values are aliases so 0/o are the same, 1/I/l are the same, etc https://github.com/ulid/spec https://github.com/ulid/spec
- keithlfrost 6y agoYes. I'm surprised the author would be more concerned about confusion between U/V (or u/v) than between 1/l ... the former has always seemed relatively far-fetched to me, whereas depending on the font, the latter can be a real problem. Again, I attribute the issue to the choice of upper case as canonical, because L is not easily confused with any other letter or number.
- yellowapple 6y ago> Again, I attribute the issue to the choice of upper case as canonical, because L is not easily confused with any other letter or number. That is indeed why I settled for that tradeoff, yep; as long as it's all VPPERCA5E it'll be distinct enough.
- sedatk 6y agoCrockford's Base32 already does that. I/l/1 are all synonyms.