Base36 Support #18

New issue

Open

opened 2016-02-17 00:15:52 -06:00 by jrogers · 2 comments

jrogers commented

2016-02-17 00:15:52 -06:00

(Migrated from github.com)

Adding base62 and/or base36 might also be useful, they are often used for url shorteners in particular, since they just include numbers/letters, no special characters.

jrogers commented

2016-02-17 00:17:24 -06:00

(Migrated from github.com)

I see you have probably already covered Base62 with the saltpack stuff.

jpetso commented

2016-02-17 00:56:47 -06:00

(Migrated from github.com)

Probably, yeah. Many URL shorteners seem to be encoding numeric values using place-based single number codecs (as opposed to octet stream codecs), which I covered a bit in TODO.md (haven't migrated all items to the GitHub issue queue) but is not on my immediate list of low-hanging fruit.

Saltpack and its base62/baseX codecs are still octet stream based, so they might not cover this particular use case, although a generic implementation of their baseX might push us closer towards that.

In general I prefer implementing codecs with clear specifications, or ones in wide use but most of those are pretty well specified. This way we can avoid confusing one variant from others that might use the same radix but different encoding subtleties and/or alphabets. If you know of any particular format - ideally documented - that you'd like to see implemented, I would appreciate a link to its spec. Although I guess for base36 it could be straightforward enough, I'd feel comfortable giving the Wikipedia variant a name base36_hex analogous to the well-specified base32 equivalent and preserving its behavior.

However, the place-based single number codec issue (call it "int to string" if you want) is still an issue and won't be resolved until I have a second, alternative codec interface that takes numeric values instead of byte arrays. I imagine this might take a while, unless my employer finds it worthwhile to work on or an outside contributor makes it happen themselves.

Probably, yeah. Many URL shorteners seem to be encoding numeric values using place-based single number codecs (as opposed to octet stream codecs), which I covered a bit in [TODO.md](https://github.com/tplgy/cppcodec/blob/master/TODO.md) (haven't migrated all items to the GitHub issue queue) but is not on my immediate list of low-hanging fruit. Saltpack and its base62/baseX codecs are still octet stream based, so they might not cover this particular use case, although a generic implementation of their baseX might push us closer towards that. In general I prefer implementing codecs with clear specifications, or ones in wide use but most of those are pretty well specified. This way we can avoid confusing one variant from others that might use the same radix but different encoding subtleties and/or alphabets. If you know of any particular format - ideally documented - that you'd like to see implemented, I would appreciate a link to its spec. Although I guess for base36 it could be straightforward enough, I'd feel comfortable giving the Wikipedia variant a name `base36_hex` analogous to the well-specified base32 equivalent and preserving its behavior. However, the place-based single number codec issue (call it "int to string" if you want) is still an issue and won't be resolved until I have a second, alternative codec interface that takes numeric values instead of byte arrays. I imagine this might take a while, unless my employer finds it worthwhile to work on or an outside contributor makes it happen themselves.