Why did base64 win against uuencode?
Base64’s dominance over uuencode is traced to reliability and portability requirements in early email and network systems: its 64‑character alphabet was chosen to survive translation across ASCII, EBCDIC, and whitespace-mangling gateways, something uuencode and formats like BinHex often failed at. Commenters dig into the historical constraints behind ASCII’s seemingly odd layout, tradeoffs around backward compatibility and performance, and related encoding variants (yEnc, URL-safe base64, quoted-printable), highlighting how real-world protocol quirks and standardization shaped today’s binary‑to‑text encodings.
Why Base64 “Won” Over uuencode
Base64 was designed for MIME email with strict portability needs.
- Its alphabet is a subset of characters represented identically in all ISO 646 variants and all EBCDIC variants.
- uuencode’s alphabet includes characters not reliably mappable across EBCDIC and other non-ASCII environments, causing corruption in real deployments.
- Spaces and other fragile characters in uuencode were often mangled by mail systems that normalized or altered whitespace.
Base64 provides consistent overhead (~33%), while uuencode adds per-line overhead that makes it less efficient overall (effective efficiency can drop to ~60–70%).
Once MIME and SSL/TLS standardized on Base64, it became the default everywhere; practical availability and tooling then reinforced its dominance.
ASCII Design, Backwards Compatibility, and Performance Debates
Several comments explain ASCII’s layout as a product of historical constraints:
- Bitwise properties (e.g., case conversion via a single bit, Control key behavior).
- Need to support 6‑bit devices and mechanical terminals.
- EBCDIC’s odd layout is similarly tied to punch-card technology.
One participant criticizes “backwards compatibility” and ASCII’s layout as harming long‑term efficiency (e.g., extra instructions for int→hex, alphabet checks, and lack of bit-paired punctuation).
Others strongly dispute this:
- Argue the performance concerns are overstated on modern CPUs and largely irrelevant in real workloads.
- Point out that parsers and lexers don’t benefit much from hypothetical “paired punctuation” encodings.
- Note that changing ASCII would have been practically impossible once deployed.
There is also criticism of Unicode for complicating the formerly simple 1‑byte→1‑character mapping, though it’s acknowledged as necessary for real-world languages.
Base64 Design Details and Variants
Discussion of padding (
=):- Some argue it’s unnecessary because the length of the Base64 string encodes how many bytes are missing; padding is said to be a legacy or taste issue.
- Others note padding helps preserve fragment boundaries when concatenating separately encoded chunks; without it, boundaries become ambiguous.
Variants of Base64 (URL/filename-safe, unpadded) are mentioned, but interoperability issues arise when encoders/decoders disagree on alphabet and padding rules.
Other Encodings and Historical Context
- yEnc, BinHex, BinSCII, MacBinary, StuffIt, and XXBUG are discussed as alternative binary-to-text encodings tied to specific platforms (Usenet, classic Mac, MS‑DOS).
- Classic Mac resource/data forks and metadata motivated BinHex and similar wrappers.
- Commenters also note the survival of ascii85 and various nostalgic experiences with early web downloads, Kermit, and file transfer tooling.