There is also base64URL , where the encoding uses different ascii characters that are url safe. I have seen some devs use BASE64URL but call it just base64, and that can lead to some problems for unaware.
If you want to eliminate ambiguity for human readers, you can drop to Base58 but in almost all cases, if you are BaseXX-encoding something, it’s long enough that copy-pasting is the norm, so it doesn’t usually matter.
No, typically the extra characters used are “-“ and “_”. That’s what the table in the IETF link shows.
This isn't a major issue, which means there's no easy answer and it generally comes down to preference if this is a requirement or not.
UXTerm*charClass: 33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48
FWIW, browser only selects either `foo` or `bar_baz`, but not the whole `foo-bar_baz`.
Well, you're in luck: tilde and dot aren't part of base64url
This isn't a major issue, which means there's no easy answer and it generally comes down to preference if this is a requirement or not.
Base32 is sufficient in most cases and can avoid some incidental swear words.
If you want density go for Z85, which is a 4 -> 5 byte chunked encoding and therefore much more efficient on a pipelined CPU.
Since a base64 string with padding is always guaranteed to be a multiple of four characters long, if you get a string that is not a multiple of four in length, you can figure out how much padding it should have had, which tells you how to handle the last three bytes of decoding.
Which makes it a little confusing why base64 needs == padding in the first place.