7 ms·

I hate base64. If you have to embed binary data within human-readable text, then you’re either A: doing something horribly wrong B: or forced to use a monkey-

I hate base64. If you have to embed binary data within human-readable text, then you’re either A: doing something horribly wrong B: or forced to use a monkey-patched legacy standard Otherwise just use hexadecimal digits. At least it will be somewhat readable. I know, I know... Base64 encodes 3 bytes on 4 characters, while hex encodes 2 bytes on 4. Big fucking deal. It will almost surely be gzipped down the line, and if you’re storing amounts of data where this would count, then see point “A” above. I hope one day we will laugh at the mere idea of base64 encoding like how we do with EBCDIC or Windows-12XX codepages.

vvanders 9y ago
Not everything goes over the web and is gzipped. I've been working on a project lately with 1200bps radio links that are making REST calls on the other end and 2 vs 3 bytes makes a massive difference.
- tzahola 9y ago
  And why don’t you just send it in binary? REST doesn’t mean you have to use JSON for the HTTP body.
  - vvanders 9y ago
    Yeah, that would be ideal. Some of the protocols we talk over(APRS) are ASCII only(which is a bit of point B from above). Transmissions are also signed at the radio so that they can be authenticated down the line which means that you can't easily change the payload envelope once it leaves the radio. Our main goal is adoption and talking base64 means that lots of APIs that would take an intermediate server to do the translation aren't needed. This lowers to barrier to use and means we have a larger surface area of use cases.
  - sd8dgf8ds8g8dsg 9y ago
    It sounds like her use case is badly suited for raw binary transmission due to the high possibility of data loss, much like the internet used to be when base64 was originally introduced.
_wmd 9y ago
Base64 has been around forever, and hex has significantly lower information density than it - consistently more than 30% smaller. As for doing something horribly wrong, I dunno, ensuring literally billions of moms and pops can exchange baby pictures by e-mail, for the first time in human history, and doing so since the time when we were using 33.6kbit modems, that seems like a resounding success.† † Yes, if e-mail had not paid such close attention to compatibility, and just ripped up every old standard on every chance it got (i.e. pretty much like any technology invented since the commoditization of the web), interoperability would never have happened. Legacy crap is fundamentally a part of that success, and Base64 is fundamentally a part of making those hacks practical for the technology we had at the time†† †† To head off an obvious counterargument: yes, there are contemporary examples of why this strategy is still important (it's, so far, the only one that has ever worked in the decentralized environment of the Internet), and is very likely to come in useful in future, time and time again
- tzahola 9y ago
  Most of the modern Web is unusable without a highly optimized JIT-compiling JS interpreter. Are you sure about the importance of interoperability & compatibility?
  - _wmd 9y ago
    I'm not sure why you believe that is a counterexample - it is anything but. That interpreter can still run code written against the original DOM APIs in the original syntax, as defined 22 years ago - around time the <noscript> tag appeared in HTML! Of course if mom and pop were using UUCP and an ADM-3A to fetch their mail, they couldn't view the images -- but all the infrastructure that allowed them to read mail at all could be repurposed without change, possibly including their modem (thanks, RS-232, introduced 1960), if they bought a 80386 desktop with a VGA card These are all interoperability success stories! Meanwhile, I need 19 different IM apps on my phone to talk to 19 different people. That's what happens when you ignore interoperability
    - mschuster91 9y ago
Veedrac 9y ago
Base64 on the web is such an unbelievably terrible solution to such a trivial problem that it beggars belief. The idea that parsing CSS somehow blocks on decompressing string delimited, massively inefficient, nonlinearly encoded blobs of potentially incompressible data is insane. We've taken the most obvious latency path a normal user sees and somehow decided that mess was better than sending an ar file. (Not that this wasn't inevitable as soon as someone decided CSS should be a text format... sigh)
- bzbarsky 9y ago
  Why should parsing CSS block on decompressing base64, unless the CSS itself is a base64-encoded data: URI? If you're talking about data: background images in CSS, then all the CSS parser has to do is find the end of the url(). It doesn't have to do any base64 decoding or anything like that until the rule actually matches.
  - Veedrac 9y ago
    You have to gz-decompress it, which is a harder job, and the only reason you're doing that (at least for images) is to undo the inefficiency you just added.
    - bzbarsky 9y ago
      Ah, gz-decompress the stylesheet itself, ok. For what it's worth, in my profiles of pageloads in at least Firefox I haven't seen gz-decompression of stylesheets show up in any noticeable way, but I can believe that it could be a problem if you have a lot of data: images in the sheet...
foota 9y ago
I once came across a site with that was base 64 encoding GET params for an incredibly insecure http route. E.g., the request was something like http://example.com/bad/?v=YT0xMjMmYj00NTY= http://example.com/bad/?v=YT0xMjMmYj00NTY= which they would then decode on the server to a=123&b=456
deleted 9y ago
[deleted]

vvanders 9y ago

Not everything goes over the web and is gzipped. I've been working on a project lately with 1200bps radio links that are making REST calls on the other end and 2 vs 3 bytes makes a massive difference.

tzahola 9y ago
And why don’t you just send it in binary? REST doesn’t mean you have to use JSON for the HTTP body.
- vvanders 9y ago
  Yeah, that would be ideal. Some of the protocols we talk over(APRS) are ASCII only(which is a bit of point B from above). Transmissions are also signed at the radio so that they can be authenticated down the line which means that you can't easily change the payload envelope once it leaves the radio. Our main goal is adoption and talking base64 means that lots of APIs that would take an intermediate server to do the translation aren't needed. This lowers to barrier to use and means we have a larger surface area of use cases.
- sd8dgf8ds8g8dsg 9y ago
  It sounds like her use case is badly suited for raw binary transmission due to the high possibility of data loss, much like the internet used to be when base64 was originally introduced.

_wmd 9y ago

Base64 has been around forever, and hex has significantly lower information density than it - consistently more than 30% smaller. As for doing something horribly wrong, I dunno, ensuring literally billions of moms and pops can exchange baby pictures by e-mail, for the first time in human history, and doing so since the time when we were using 33.6kbit modems, that seems like a resounding success.† † Yes, if e-mail had not paid such close attention to compatibility, and just ripped up every old standard on every chance it got (i.e. pretty much like any technology invented since the commoditization of the web), interoperability would never have happened. Legacy crap is fundamentally a part of that success, and Base64 is fundamentally a part of making those hacks practical for the technology we had at the time†† †† To head off an obvious counterargument: yes, there are contemporary examples of why this strategy is still important (it's, so far, the only one that has ever worked in the decentralized environment of the Internet), and is very likely to come in useful in future, time and time again

tzahola 9y ago
Most of the modern Web is unusable without a highly optimized JIT-compiling JS interpreter. Are you sure about the importance of interoperability & compatibility?
- _wmd 9y ago
  I'm not sure why you believe that is a counterexample - it is anything but. That interpreter can still run code written against the original DOM APIs in the original syntax, as defined 22 years ago - around time the <noscript> tag appeared in HTML! Of course if mom and pop were using UUCP and an ADM-3A to fetch their mail, they couldn't view the images -- but all the infrastructure that allowed them to read mail at all could be repurposed without change, possibly including their modem (thanks, RS-232, introduced 1960), if they bought a 80386 desktop with a VGA card These are all interoperability success stories! Meanwhile, I need 19 different IM apps on my phone to talk to 19 different people. That's what happens when you ignore interoperability
  - mschuster91 9y ago

Veedrac 9y ago

Base64 on the web is such an unbelievably terrible solution to such a trivial problem that it beggars belief. The idea that parsing CSS somehow blocks on decompressing string delimited, massively inefficient, nonlinearly encoded blobs of potentially incompressible data is insane. We've taken the most obvious latency path a normal user sees and somehow decided that mess was better than sending an ar file. (Not that this wasn't inevitable as soon as someone decided CSS should be a text format... sigh)

bzbarsky 9y ago
Why should parsing CSS block on decompressing base64, unless the CSS itself is a base64-encoded data: URI? If you're talking about data: background images in CSS, then all the CSS parser has to do is find the end of the url(). It doesn't have to do any base64 decoding or anything like that until the rule actually matches.
- Veedrac 9y ago
  You have to gz-decompress it, which is a harder job, and the only reason you're doing that (at least for images) is to undo the inefficiency you just added.
  - bzbarsky 9y ago
    Ah, gz-decompress the stylesheet itself, ok. For what it's worth, in my profiles of pageloads in at least Firefox I haven't seen gz-decompression of stylesheets show up in any noticeable way, but I can believe that it could be a problem if you have a lot of data: images in the sheet...

foota 9y ago

I once came across a site with that was base 64 encoding GET params for an incredibly insecure http route. E.g., the request was something like http://example.com/bad/?v=YT0xMjMmYj00NTY= http://example.com/bad/?v=YT0xMjMmYj00NTY= which they would then decode on the server to a=123&b=456

deleted 9y ago

[deleted]