Not implementing the RFC, is not implementing Base32, changing the order, or using 32 emoji does not make it Base32. Put another way, you can change the order of characters in Base64, or use a different dictionary, and indeed there are several variants of that too (BinHex4, Uuencoding, Base64Url, B64) - there are specific implementation detail concerns there too.
Base64 won out as a reasonably dense way to encode binary data in 7-bit safe ASCII for use in email, and later http headers (where spacing and line length may be modified in transit, and some ASCII characters are prohibited - eg 0x00/null). Part of the reason is; bit-grouping makes encode/decode simpler (you can use bit shifting). Something like ASCII85/Base85 which is a more dense encoding, and close to the maximum you can get in 7 bit safe ASCII (94 characters 33-126 if space is important, 95 if space quantity can be preserved) but you have to use multiply/divide instructions. The union of bit-shift speed (power of 2) and 7-bit safe ASCII characters (max 94 values) is: binary, base4, octal, hexadecimal, base32, and base64.
For human readability, especially verbal communication, hexadecimal or base32 are advantageous in that they are more dense than decimal, can be generated via bit-shifting vs more complex processor instructions, but you needn't also communicate the character's case (unlike Base64).
When you see a Base64 string, you can be pretty certain that it's the standard version. With Base32, it's not obvious which variant was used.
Many languages don't provide a stdlib Base32 implementation (Ruby doesn't), but Base64 is pretty much always included. Maybe this influenced my perception of the lack of a universal standard.
Anyway, I should work on that section to communicate my point better.
Base64 is very close to the Schelling point of Base62 i.e. [A-Za-z0-9], requiring only a couple more additional decisions to be made: which two extra characters to add.
Unfortunately the original Base64 inexplicably got this wrong and chose + and / instead of the more sensible choice of - and _
"Hello, world!" = `SGVsbG8sIHdvcmxkIQ` (base64, base64url), `BG4JgP4wg65RjQalY6E` (Xxencode), or `G4JgP4wg65RjQalY6E` (b64). A legitimate reason for choosing B64 over Base64 would be: it maintains ASCII sort-order.
Any language that has to deal with HTTP (or MIME) has to encode/decode Base64 in order to support some headers (eg Basic auth) and features (binary data from a form submission). There is no similar HTTP need for Base32, so perhaps it's less surprising it's not in the standard library?
Base36: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
Good encoding for binary data in textual contexts. Such as where you have parameter inputs or database fields that are constrained and only accept certain characters. The lack of spaces means that it can be used on the command-line easily. Example use: IRC channel names.
Base64: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
Same as above but it adds lower-case alphabet characters. This is important because as you restrict the number of characters allowed in a byte: the length of the string goes up massively. With more characters the coding is more efficient. Example use: YouTube video ids.
Base92: "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~!@#$%^&*()_+{}\"<>?`-=[];',./|"
Base92 is every character you can make on a standard key-board (I've replaced space with pipe here.) It includes many characters that have special meanings on the command-line or may be used as delimiters in text-based protocols. So while this offers a more 'efficient' encoding scheme for binary data it may break in some contexts. It's best where the input allows for typical formatting. Example use: forum / chat messages.
BaseN encoding schemes are interesting because they allow you to use standard text-fields in many systems to store binary data. The most well-known here is base64 which allows browsers to embed whole files as text and store them directly in the HTML. Some sites use these for optimization hacks.
As for base92, those symbols might all be easy to enter on your keyboard, but on international layouts the process can be quite involved indeed.
I prefer base36 for this reason. Want a compact random string? Math.random().toString(36). Watch out to prefix it with a char for settings that disallow leading digits through! (variable identifiers, css class names, etc.)
[1] https://en.wikipedia.org/wiki/Base64#Variants_summary_table
This is only 62 characters!
Better IMO is base 32 with U (obscenity), 0/O (ambiguity), and I (ambiguity) removed.
I've always heard that the reason in another ambiguity (u/v) which makes more sense to me.
- "Golden ratio base is a non-integer positional numeral system" (2023) https://news.ycombinator.com/item?id=37969716
Number systems > Classification: https://en.wikipedia.org/wiki/Number#Classification ; N natural numbers, Z[±] integers, Q rational/s, R Reals, C complex numbers (with complex conjugate exponents), Infinity or Infinities, ; C ⊆ R ⊆ Q ⊆ Z ⊆ N
***
i^4x ~= e^iπx
e^(x*yi*zπ)
e^(x*yi*zπ) * e^(a*bi*cπ)
sign * e^(x*yi*zπ) * e^(a*bi*cπ)
sign * e^(x*yi*zπ)
+ almost as efficient as base64 + no special characters + no padding characters
> u8 divmod 58 can be reduced to a u8->u16 multiply, a right shift, and three conditional subtractions; that's not great, but on a modern CPU it's a afterthought compared to the quadratic loop over the input size.
Same topic from 2018: https://news.ycombinator.com/item?id=18409344
No special characters... I mean it's true, but there's not many places I'm worried about inability to mix in some - and _.
Base58 also avoids a couple confusable characters, but that only matters when copying by hand, and if I'm copying by hand I'd rather use base32.