4 ms·

At least they document the tradeoffs with comparisons to other encodings. https://base32h.github.io/comparisons https://base32h.github.io/comparisons

by kbaker 6y ago

sedatk 6y ago
So, according the document the only difference is Base32H solves ambiguity between S and 5 but allows ambiguity between l and 1. I think that's the worse tradeoff to be made, let alone a reason to create whole another encoding scheme.
- benatkin 6y ago
  > allows ambiguity between l and 1 It doesn't really. The canonical is L (uppercase). In practice lowercase l will never appear, unless for some reason you want it to (you could convert L05ER to l05ER just for presentation, there are worse leetspeek offensive terms that would be allowed though). Also the U/V thing neatly gets rid of FUCK. S/5 and I/1 take care of others.
  - sedatk 6y ago
    I wouldn’t want ALLUPPERCASE identifiers on my URLs for instance. I presume that would be one of the most common scenarios it would be used in.
    - benatkin 6y ago
      Well, it will still work but you'll lose the benefit of it. Most of these don't look like SHOUTING to me. They look uppercase but not aggressive.
      - sedatk 6y ago
        You don't want upper-case in URLs for social reasons. It simply looks out of place, takes more screen real-estate, and stands out unnecessarily. I'm just saying, if canonical is good enough, "S/5" fix isn't sufficient to get a whole new standard then. If it isn't good enough, then the value this one promises over Crockford is arguable due to lack of I/l/1 aliasing.
        deleted 6y ago
        [deleted]
  - w-ll 6y ago
    I downcase all ids, sometimes this includes uuids and string ids.
    - benatkin 6y ago
      This is suggesting that you don't. It shouldn't be that hard to start using it in the canonical form - just start treating IDs as if they're case sensitive.
- yellowapple 6y ago
  > I think that's the worse tradeoff to be made That's definitely a fair conclusion. If you're using lowercase identifiers, then I agree wholeheartedly, and you'd be better served by Crockford's (or perhaps some Crockford/Base32H hybrid that aliases L/l to 1 and de-aliases S/s from 5). What motivated me to make that tradeoff was two-fold: 1) For my use-cases, identifiers were/are always uppercase by default (and indeed, the Base32H specification requires encoders to emit uppercase-only), which eliminates ambiguity between L and I/1 2) Smudges and grime and scratches and such can and frequently do make it difficult to distinguish S from 5 or V from U; it was therefore a pragmatic choice to alias those (while preserving Crockford's partial profanity defense as a nice side-effect)
  - sedatk 6y ago
    That's fair and what you say makes sense in that context. Crockford doesn't have U/V problem either by the way, because it doesn't have U in its alphabet. It's only missing aliasing for it, so there is no possibility of passing on the wrong value by confusing V with U. That just leaves 5 and S. Whole another standard just for that might be acceptable if the use case you mentioned (mostly upper-case) gets significantly more benefit from it.

At least they document the tradeoffs with comparisons to other encodings. https://base32h.github.io/comparisons https://base32h.github.io/comparisons

by kbaker 6y ago

At least they document the tradeoffs with comparisons to other encodings. https://base32h.github.io/comparisons https://base32h.github.io/comparisons

sedatk 6y ago

So, according the document the only difference is Base32H solves ambiguity between S and 5 but allows ambiguity between l and 1. I think that's the worse tradeoff to be made, let alone a reason to create whole another encoding scheme.

benatkin 6y ago
> allows ambiguity between l and 1 It doesn't really. The canonical is L (uppercase). In practice lowercase l will never appear, unless for some reason you want it to (you could convert L05ER to l05ER just for presentation, there are worse leetspeek offensive terms that would be allowed though). Also the U/V thing neatly gets rid of FUCK. S/5 and I/1 take care of others.
- sedatk 6y ago
  I wouldn’t want ALLUPPERCASE identifiers on my URLs for instance. I presume that would be one of the most common scenarios it would be used in.
  - benatkin 6y ago
    Well, it will still work but you'll lose the benefit of it. Most of these don't look like SHOUTING to me. They look uppercase but not aggressive.
    - sedatk 6y ago
      You don't want upper-case in URLs for social reasons. It simply looks out of place, takes more screen real-estate, and stands out unnecessarily. I'm just saying, if canonical is good enough, "S/5" fix isn't sufficient to get a whole new standard then. If it isn't good enough, then the value this one promises over Crockford is arguable due to lack of I/l/1 aliasing.
      - deleted 6y ago
        [deleted]
- w-ll 6y ago
  I downcase all ids, sometimes this includes uuids and string ids.
  - benatkin 6y ago
    This is suggesting that you don't. It shouldn't be that hard to start using it in the canonical form - just start treating IDs as if they're case sensitive.
yellowapple 6y ago
> I think that's the worse tradeoff to be made That's definitely a fair conclusion. If you're using lowercase identifiers, then I agree wholeheartedly, and you'd be better served by Crockford's (or perhaps some Crockford/Base32H hybrid that aliases L/l to 1 and de-aliases S/s from 5). What motivated me to make that tradeoff was two-fold: 1) For my use-cases, identifiers were/are always uppercase by default (and indeed, the Base32H specification requires encoders to emit uppercase-only), which eliminates ambiguity between L and I/1 2) Smudges and grime and scratches and such can and frequently do make it difficult to distinguish S from 5 or V from U; it was therefore a pragmatic choice to alias those (while preserving Crockford's partial profanity defense as a nice side-effect)
- sedatk 6y ago
  That's fair and what you say makes sense in that context. Crockford doesn't have U/V problem either by the way, because it doesn't have U in its alphabet. It's only missing aliasing for it, so there is no possibility of passing on the wrong value by confusing V with U. That just leaves 5 and S. Whole another standard just for that might be acceptable if the use case you mentioned (mostly upper-case) gets significantly more benefit from it.