Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Base36 Support #18

Open
jrogers opened this issue Feb 17, 2016 · 2 comments
Open

Base36 Support #18

jrogers opened this issue Feb 17, 2016 · 2 comments

Comments

@jrogers
Copy link

jrogers commented Feb 17, 2016

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 jrogers changed the title Base62 Support Base36 Support Feb 17, 2016
@jrogers
Copy link
Author

jrogers commented Feb 17, 2016

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

@jpetso
Copy link
Collaborator

jpetso commented Feb 17, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants