4 ms·

I considered that, but wanted to preserve Crockford's partial defense against accidental profanity generation while still allowing U/u to be decoded (if Crockfo

I considered that, but wanted to preserve Crockford's partial defense against accidental profanity generation while still allowing U/u to be decoded (if Crockford's aliased it I probably wouldn't have bothered to whip up Base32H, lol). As for 1/l/I, yeah, that's definitely the main flaw. The workaround (as described in the FAQ) would be to always emit uppercase and take advantage of L being pretty visually distinct. A bit ugly for URLs, but for things like asset tags, product keys, and item codes / SKUs (the main things I had in mind) that's already the norm.

sharpercoder 6y ago
A language is a tool. Is special-casing the U u to prevent a single case of profanity worth it? People will come up with many ways to generate profane language. See guids/uuids for example, or l33tsp34k. A major change to hypothetically prevent a single case seems unbalanced.
- yellowapple 6y ago
  > A language is a tool. Is special-casing the U u to prevent a single case of profanity worth it? It was important enough that Douglas Crockford entirely removed the letter U from his system except as one of several choices for a check digit. I opted for the same tradeoff for Base32H; if anything, keeping U/u as a separate digit would be the major change. V and U look close enough together (more so than I and L, especially in real-world conditions where legibility is poor) that it didn't seem unreasonable for the latter to be an alias of the former.
AQXt 6y ago
> I considered that, but wanted to preserve Crockford's partial defense against accidental profanity... I don't understand the point of this "partial" defense against profanity. In the same way you can write "FVCK" in Base36H, you can write "F0DA" in hexadecimal (which means the same thing in Portuguese). So, people will still be offended by random numbers.

sharpercoder 6y ago

A language is a tool. Is special-casing the U u to prevent a single case of profanity worth it? People will come up with many ways to generate profane language. See guids/uuids for example, or l33tsp34k. A major change to hypothetically prevent a single case seems unbalanced.

yellowapple 6y ago
> A language is a tool. Is special-casing the U u to prevent a single case of profanity worth it? It was important enough that Douglas Crockford entirely removed the letter U from his system except as one of several choices for a check digit. I opted for the same tradeoff for Base32H; if anything, keeping U/u as a separate digit would be the major change. V and U look close enough together (more so than I and L, especially in real-world conditions where legibility is poor) that it didn't seem unreasonable for the latter to be an alias of the former.

AQXt 6y ago

> I considered that, but wanted to preserve Crockford's partial defense against accidental profanity... I don't understand the point of this "partial" defense against profanity. In the same way you can write "FVCK" in Base36H, you can write "F0DA" in hexadecimal (which means the same thing in Portuguese). So, people will still be offended by random numbers.