Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why did base64 win against uuencode?

retrocomputing.stackexchange.com

Post reply on HN
Print view View original

31–40 of 110 posts

Re: Why did base64 win against uuencode?

#31

Post by Vt71fcAqt7 »

jjeaff wrote: post #29
ekidd wrote: post #24

One reason that uuencode lost out to Base64 was that uuencode used spaces in its encoding. It was fairly common for Internet protocols in those days to mess with whitespace, so it was often necessary to patch up corrupted uuencode files by hand. Base64, on the other hand, was carefully designed to survive everything from whitespace corruption to being passed through non-ASCII character sets. And then it became widely…

and yet, Internet protocols (http, at least) don't play well with equal signs which are part of base64, sometimes. That little issue has caused lots of intermittent bugs for me over the years, either from forgetting to urlencode it or not urldecoding it at the right time.

And now we can have whitespace in url queries but we are still using %20 everywhere because "that's standard"...

Re: Why did base64 win against uuencode?

#32

Post by CydeWeys »

Vt71fcAqt7 wrote: post #31
jjeaff wrote: post #29

Earlier quoted context omitted.

and yet, Internet protocols (http, at least) don't play well with equal signs which are part of base64, sometimes. That little issue has caused lots of intermittent bugs for me over the years, either from forgetting to urlencode it or not urldecoding it at the right time.

And now we can have whitespace in url queries but we are still using %20 everywhere because "that's standard"...

Try copy-pasting a link that has actual whitespace in its URL queries and see if it gets linkified correctly. Just because you can doesn't mean you should! A space is like the one delimiter that is applicable for separating out URLs from the context of a larger blob of text.

Re: Why did base64 win against uuencode?

#33

Post by thaumasiotes »

Vt71fcAqt7 wrote: post #31
jjeaff wrote: post #29

Earlier quoted context omitted.

and yet, Internet protocols (http, at least) don't play well with equal signs which are part of base64, sometimes. That little issue has caused lots of intermittent bugs for me over the years, either from forgetting to urlencode it or not urldecoding it at the right time.

And now we can have whitespace in url queries but we are still using %20 everywhere because "that's standard"...

Browsers will often display %20 as a space, but that's not the same thing as spaces being legal within URLs.

Re: Why did base64 win against uuencode?

#34

Post by JoshTriplett »

jjeaff wrote: post #29
ekidd wrote: post #24

One reason that uuencode lost out to Base64 was that uuencode used spaces in its encoding. It was fairly common for Internet protocols in those days to mess with whitespace, so it was often necessary to patch up corrupted uuencode files by hand. Base64, on the other hand, was carefully designed to survive everything from whitespace corruption to being passed through non-ASCII character sets. And then it became widely…

and yet, Internet protocols (http, at least) don't play well with equal signs which are part of base64, sometimes. That little issue has caused lots of intermittent bugs for me over the years, either from forgetting to urlencode it or not urldecoding it at the right time.

Ditto the obnoxious "quoted-printable" mail encoding, which turns every = into =3D.

Still more robust than uuencode though.

Re: Why did base64 win against uuencode?

#35

Post by Vt71fcAqt7 »

thaumasiotes wrote: post #33
Vt71fcAqt7 wrote: post #31

Earlier quoted context omitted.

And now we can have whitespace in url queries but we are still using %20 everywhere because "that's standard"...

Browsers will often display %20 as a space, but that's not the same thing as spaces being legal within URLs.

You are right. Seems firefox displays %20 as whitespace and converts whitespace to %20 when you use it. Chrome displays it as %20 but still converts whitespace to %20 if you try to use it.

Re: Why did base64 win against uuencode?

#36

Post by DaiPlusPlus »

demondemidi wrote: post #30
DaiPlusPlus wrote: post #25

Earlier quoted context omitted.

Spare a thought for us Windows users - we went from our pristine and oddly beautiful home directories in Windows 7, where everything was neatly squared-away to either AppData\Roaming or AppData\Local - to our post-Electron, lazily-ported software world where my home directory now has no-less than twenty Unix-style dot-directories littering my %USERPROFILE% Incidentally, the worst offender is Microsoft themselves: it…

Pristine? You mean the same home directory that contains the 80 character NTUSER files? ;)

Or the back-compat symlinks for NetHood, Start, Recent, SendTo, ah yes. I had a post-install VBScript that cleaned those out.

My current sad-thing I’m unhappy about is how the “My Documents” folder ended up being a second AppData folder, with lots of software storing settings, templates, project files, etc in that dir instead of AppData.

Windows absolutely needs application-silos to protect users from lazy apps. I hate to say it, but Apple was 100% right to make iPhone OS a file-system-free OS - we can’t do that on desktop, but gosh-darn-it, why is software so terrible? :(

Re: Why did base64 win against uuencode?

#37

Post by candiddevmike »

ekidd wrote: post #24

One reason that uuencode lost out to Base64 was that uuencode used spaces in its encoding. It was fairly common for Internet protocols in those days to mess with whitespace, so it was often necessary to patch up corrupted uuencode files by hand. Base64, on the other hand, was carefully designed to survive everything from whitespace corruption to being passed through non-ASCII character sets. And then it became widely…

...only for base64 to become fragmented into standard or URL due to character choice, and padded or not padded as a "cool trick to save some bytes".

Re: Why did base64 win against uuencode?

#38

Post by Aardwolf »

A thing I wonder: why is using = padding required in the most common base64 variant?

It's redundant since this info can be fully inferred from the length of the stream.

Even for concatenations it is not necessary to require it, since you must still know the length of each sub stream (and = does not always appear so is not a separator).

There's no way that using the = instead of per-byte length-checking gains any speed, since to prevent reading out of bounds you must check the per byte length anyway, you can't trust input to be a multiple of 4 length.

It could only make sense if it's somehow required to read 4 bytes at once, and you can't possibly read less, but what platform is such?

Re: Why did base64 win against uuencode?

#39

Post by remram »

Aardwolf wrote: post #38

A thing I wonder: why is using = padding required in the most common base64 variant? It's redundant since this info can be fully inferred from the length of the stream. Even for concatenations it is not necessary to require it, since you must still know the length of each sub stream (and = does not always appear so is not a separator). There's no way that using the = instead of per-byte length-checking gains any spee…

> Even for concatenations it is not necessary to require it, since you must still know the length of each sub stream

I'm not sure I understand this part. You can decode aGVsbG8=IHdvcmxk, what do you need to know?

Re: Why did base64 win against uuencode?

#40

Post by u801e »

mjevans wrote: post #18
ggm wrote: post #15

Having lived through the transition, I can say personally it comes down to "packaging" -if MIME had adopted UUENCODE format, I probably would have used it but as materials emerged to me which depended on base64 decode, it became compelling to use it. Once it was ubiquitously available in e.g ssl, it became trivial to decode a base64 encoded thing, no matter what. Not all systems had a functioning uudecode all the tim…

After a given point usenet was nearly 8-bit clean, and thus https://en.wikipedia.org/wiki/YEnc was also developed to convolve all the octets (I + 42 (decimal)) and escape the results that happened to still match reserved characters (CR, LF, 0x0, = (yEnc escape)) - it seems that if the result character was among that set, then = was output and new output determined by O = (I+64) % 256 instead.

It's too bad yenc didn't take the place of base64 for email.
Post reply on HN