3 ms·
'.' is not a standard base64 character; did you roll your own? Base36 and base32 are popular where portability and paranoia of being MIME/URL-mangled are conce
by sk5t 12y ago
'.' is not a standard base64 character; did you roll your own?
Base36 and base32 are popular where portability and paranoia of being MIME/URL-mangled are concerns, e.g., Google Authenticator's OATH TOTP implementation for the secret key.
- jimktrains2 12y agoif you check http://en.wikipedia.org/wiki/Base64 http://en.wikipedia.org/wiki/Base64 there are actually RFC-standard alphabets that use . and - because they're URL-safe.
- bazzargh 12y agoI was surprised when I read that, since I've implemented those RFCs before and didn't remember this coming up - so I checked. Unfortunately, that's just a problem with the wikipedia article. The only one listed there as an RFC using '.' is RFC 4686, (in the padding column right now it says "= (optional, not recommended. Recommended use .)"). That's wrong though. In RFC 4648 it actually says: The remaining unreserved URI character is ".", but some file system environments do not permit multiple "." in a filename, thus making the "." character unattractive as well. And... The pad character "=" is typically percent-encoded when used in an URI, but if the data length is known implicitly, this can be avoided by skipping the padding The data length is known for a cryptographic hash, so you would omit the '='. I'll fix wikipedia.