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

41–50 of 110 posts

Re: Why did base64 win against uuencode?

#41

Post by Aardwolf »

remram wrote: post #39
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?

The = does not appear if the base64 data is a multiple of 4 length. So you wouldn't know if aGVsbG8I is one or two streams. The = is not a separator, only padding to make the base64 stream a multiple of 4 length for some reason.

I only mentioned the concatenation because Wikipedia claims this use case requires padding while in reality it doesn't.

Re: Why did base64 win against uuencode?

#42

Post by lifthrasiir »

Aardwolf wrote: post #41
remram wrote: post #39

Earlier quoted context omitted.

> 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?

The = does not appear if the base64 data is a multiple of 4 length. So you wouldn't know if aGVsbG8I is one or two streams. The = is not a separator, only padding to make the base64 stream a multiple of 4 length for some reason. I only mentioned the concatenation because Wikipedia claims this use case requires padding while in reality it doesn't.

Base64 doesn't have a concept of "stream". Conceptually base64-encoded string with padding is a concatenation of fragments that are always 4 bytes long but can encode one to three bytes. Concatenating two base64-encoded strings with padding therefore don't destroy fragment structures and can be decoded into a byte sequence that is a concatenation of two original input sequences. Without padding, fragments can be also 2 or 3 bytes and short fragments are not distinguishable from long fragments, so the concatenation will destroy fragment structures.

Re: Why did base64 win against uuencode?

#43

Post by remram »

Aardwolf wrote: post #41
remram wrote: post #39

Earlier quoted context omitted.

> 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?

The = does not appear if the base64 data is a multiple of 4 length. So you wouldn't know if aGVsbG8I is one or two streams. The = is not a separator, only padding to make the base64 stream a multiple of 4 length for some reason. I only mentioned the concatenation because Wikipedia claims this use case requires padding while in reality it doesn't.

It would decode correctly but you wouldn't know the boundary, if that matters. I see, thanks.

Re: Why did base64 win against uuencode?

#44

Post by Aardwolf »

lifthrasiir wrote: post #42
Aardwolf wrote: post #41

Earlier quoted context omitted.

The = does not appear if the base64 data is a multiple of 4 length. So you wouldn't know if aGVsbG8I is one or two streams. The = is not a separator, only padding to make the base64 stream a multiple of 4 length for some reason. I only mentioned the concatenation because Wikipedia claims this use case requires padding while in reality it doesn't.

Base64 doesn't have a concept of "stream". Conceptually base64-encoded string with padding is a concatenation of fragments that are always 4 bytes long but can encode one to three bytes. Concatenating two base64-encoded strings with padding therefore don't destroy fragment structures and can be decoded into a byte sequence that is a concatenation of two original input sequences. Without padding, fragments can be also…

Oh I see, so it's for concatenating multiple base64 fragments of the same single piece of data? But where is this used? Never seen that. Javascript's base64 decoder gives an error for ='s in the middle (but I just found out the Linux base64 -d command supports it!)

Re: Why did base64 win against uuencode?

#46

Post by bobbylarrybobby »

JoshTriplett wrote: post #34
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.

Ditto the obnoxious "quoted-printable" mail encoding, which turns every = into =3D. Still more robust than uuencode though.

It's basically the same as URL encoding, they just picked = instead of %

Re: Why did base64 win against uuencode?

#47

Post by vbezhenar »

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…

IMO padding is not necessary and just a relic of old implementations.

Re: Why did base64 win against uuencode?

#48

Post by Aardwolf »

vbezhenar wrote: post #47
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…

IMO padding is not necessary and just a relic of old implementations.

I think so too. It feels similar to how many specifications from the 90s use big endian 4-byte integers for many things (like png, riff, jpeg, ...) despite little endian CPU's being most common since the 80s already, and those specifications seemingly assuming that you would want to decode those 4-byte values with fread without any bounds checking or endianness dependency.

Re: Why did base64 win against uuencode?

#49

Post by vbezhenar »

tornato7 wrote: post #16
DaiPlusPlus wrote: post #6

On a related note, I'm getting flashbacks to being on the web in the late-1990s, back when "Downloads!" was a reason to visit a particular website; and noticing that Windows users like myself could just download-and-run an .exe file, while the same downloads for Mactintosh users would be a BinHex file that'd also be much larger than the Windows equivalent - and this wasn't over FTP or Telnet, but an in-browser HTTP d…

Funny because today I find the install process for Mac much simpler. Most installs are "drag this .app file to your Applications folder", meanwhile on Windows you download an installer that downloads another installer that does who-knows-what to your system and leaves ambiguously-named files and registry modifications all over the place.

There are plenty of portable windows applications (distributed as a zipped directory) and there are plenty of pkg macOS installers.

I don't really understand why macOS users like this "simple" installation, because when you "uninstall" the app, it leaves all the trash in your system without a chance to clean up. And implying that macOS application somehow will not do "who-knows-what" to your system is just wrong. Docker Desktop is "simple", yet the first thing it does after launch is installing "who-knows-what".

Re: Why did base64 win against uuencode?

#50

Post by jcranmer »

u801e wrote: post #40
mjevans wrote: post #18

Earlier quoted context omitted.

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.

yEnc was rejected by the MIME standardization group for two main reasons, one good and one bad. The good reason was that it has some encoding pathologies, although these could have been fixed in the standardization process. The bad reason was "it's too hard to add a new Content-Transfer-Encoding because you have to change all the user agents", which given that by that time all the clients were changing to support yEnc it was quite clear that uptake would likely of a new addition would have been fairly rapid.
Post reply on HN