6 ms·

I feel like base64 is "good enough" and well supported pretty much everywhere that I'm skeptical of trying to convert to a new slightly better format.

tosh 6y ago
one of the main annoyances w/ base64 is when you want to it in the context of URLs https://en.wikipedia.org/wiki/Base64#URL_applications https://en.wikipedia.org/wiki/Base64#URL_applications > Using standard Base64 in URL requires encoding of '+', '/' and '=' characters into special percent-encoded hexadecimal sequences ('+' becomes '%2B', '/' becomes '%2F' and '=' becomes '%3D'), which makes the string unnecessarily longer.
- tracker1 6y ago
  for URIs, would use base64url. Replaces '+' with '-' and '/' with '_' while omitting the '=' padding.
- jillesvangurp 6y ago
  Apache commons codec has a base 64 encoder that has a url friendly mode where it substitutes those characters. I've used that a few times to work around issues like this.
  - brabel 6y ago
    URL-safe base64 is part of the spec: https://tools.ietf.org/html/rfc4648#section-5 https://tools.ietf.org/html/rfc4648#section-5 If you're using Java, it's right in the standard library: `Base64.getUrlEncoder().withoutPadding().encode(value)`
xerxesaa 6y ago
This is not the purpose of base58. The main use case for base58 is to avoid human error in similar looking characters ("l" vs I" or "0" vs "O"). As an example, this is used in Bitcoin addresses to ensure you don't accidentally type the wrong characters if copying an address by hand.
- mleonhard 6y ago
  Yet it leaves in several easily confused character pairs: 5S, and 8B.
CivBase 6y ago
I recently wrote a base64 encoder/decoder at work. Luckily, I did not need to make it compatible with other base64 encoders/decoders because, as the article points out... > Base64 has eleven encoding variations that lead to confusion among developers on which variety of Base64 to use. Each variation has its own niche (URL safe characters, filename safe characters, checksum support, etc). I see Base58 as basically just another variation of Base64 with its own niche (human friendly characters). There's no need for existing apps to "convert". If their current Base64 implementation is good enough, they'll stick with it. Base58 is just another variation to consider when developing something new.
CydeWeys 6y ago
Base58 has existed for over a decade now, so I wouldn't exactly call it a "new" format at this point. And I've been using it for almost that long, so it's old hat to me.

tosh 6y ago

one of the main annoyances w/ base64 is when you want to it in the context of URLs https://en.wikipedia.org/wiki/Base64#URL_applications https://en.wikipedia.org/wiki/Base64#URL_applications > Using standard Base64 in URL requires encoding of '+', '/' and '=' characters into special percent-encoded hexadecimal sequences ('+' becomes '%2B', '/' becomes '%2F' and '=' becomes '%3D'), which makes the string unnecessarily longer.

tracker1 6y ago
for URIs, would use base64url. Replaces '+' with '-' and '/' with '_' while omitting the '=' padding.
jillesvangurp 6y ago
Apache commons codec has a base 64 encoder that has a url friendly mode where it substitutes those characters. I've used that a few times to work around issues like this.
- brabel 6y ago
  URL-safe base64 is part of the spec: https://tools.ietf.org/html/rfc4648#section-5 https://tools.ietf.org/html/rfc4648#section-5 If you're using Java, it's right in the standard library: `Base64.getUrlEncoder().withoutPadding().encode(value)`

xerxesaa 6y ago

This is not the purpose of base58. The main use case for base58 is to avoid human error in similar looking characters ("l" vs I" or "0" vs "O"). As an example, this is used in Bitcoin addresses to ensure you don't accidentally type the wrong characters if copying an address by hand.

mleonhard 6y ago
Yet it leaves in several easily confused character pairs: 5S, and 8B.

CivBase 6y ago

I recently wrote a base64 encoder/decoder at work. Luckily, I did not need to make it compatible with other base64 encoders/decoders because, as the article points out... > Base64 has eleven encoding variations that lead to confusion among developers on which variety of Base64 to use. Each variation has its own niche (URL safe characters, filename safe characters, checksum support, etc). I see Base58 as basically just another variation of Base64 with its own niche (human friendly characters). There's no need for existing apps to "convert". If their current Base64 implementation is good enough, they'll stick with it. Base58 is just another variation to consider when developing something new.

CydeWeys 6y ago

Base58 has existed for over a decade now, so I wouldn't exactly call it a "new" format at this point. And I've been using it for almost that long, so it's old hat to me.