base64 encoding that doesn't use “+/=” (plus or equals) characters?

Question

I need to encode a string of about 1000 characters that can be any byte value (00-FF). I don\'t want to use Hex because it\'s not dense enough. the problem with base64 as

Answer 1

Sure. Why not write your own Base64 encoder/decoder, but replace those chars in your algorithm. Sure, it will not be able to be decoded with a normal decoder, but if that's not an issue, then whyt worry about it. But, you better have at least 3 other chars that ARE useable in your app to represent the +/ and ='s...

Answer 2

If it's just those particular characters that bother you, and you can find some other characters to use instead, then how about implementing your own custom base64 module? It's not all that difficult.

Answer 3

As Ciaran says, base64 isn't terribly hard to implement - but you may want to have a look for existing libraries which allow you to specify a custom set of characters to use. I'm pretty sure there are plenty out there, but you haven't specified which platform you need this for.

Basically, you just need 65 ASCII characters which are acceptable - preferably in addition to line breaks.

Answer 4

Base58Check is an option. It is starting to become something of a de facto standard in cryptocurrency addresses.

Basic improvements over Base64:

• Only alphanumeric characters [0-9a-zA-Z]
• No look-alike characters: 0OIl / 0OIl
• No punctuation to trigger word wrap or line break in documents and emails
• Can also select entire value with a single double click due to no punctuation.

The Bitcoin Address Utility is an implementation example; geared for Bitcoins.

_{Note: A novel de facto standard may not be adequate for your needs. It is unclear if the Base58Check encoding method will formalise across current protocols.}

Answer 5

You could use Base32 instead. Less dense than Base64, but eliminates unwanted characters completely.

Answer 6

Pick your replacements. Consider some other variants: base64 Variant table from Wikipedia.

While base64 encoder/decoders are trivial, replacement subsitution can be done in a simple pre/post processing step of an existing base64 encode/decode functions (inside wrappers) -- no need to re-invent the wheel (entirely). Or, better yet, as Mr. Skeet points out, find an existing library with enough flexibility.

If you have no alternative suitable "funny" characters to choose from (perhaps all the other characters are invalid leaving only the 62 alphanumeric characters to choose from), you can always use an escape character for a very slight (~3/64?) increase in size. For instance, 0 (A) would be encoded as "AA", 62 (+) would be encoded as "AB" and 63 (/) would be encoded as "AC". This too could be done as a pre/post step if you don't want to write your own encoder/decoder from the ground-up. The disadvantage with this approach is that the ratio of output characters to input bytes is not fixed.