Let's develop an open-source media archive standard

From: der Mouse <mouse_at_Rodents.Montreal.QC.CA>
Date: Wed Aug 11 17:09:21 2004

> I like the idea of Base64, because it's something that can still be
> readily decoded manually by a human (converting between number bases
> is easy once you understand the concept).

I'd hardly say "readily". Hex I can read by eye; base64 I would use a
program for, even if it's a five-minute one-off hack. (I can write a
rudimentary base64 unpacker in fifteen minutes; I know because I once
did. Fifteen minutes would be unlikely to be enough time for me to
decode more than a few tens of bytes, without computer assist.)

> I'm not knowledgeable as to how the uuencode format is encoded.

It's conceptually almost identical to base64: it's a base-64
representation, representing three octets of binary data as four
encoded characters. The major differences are probably that uuencode
has a length field on each encoded line and uses a different set of 64
characters.

"man 5 uuencode" on your friendly neighbourhood NetBSD box should
explain it - I'll be happy to send the manpage (nroff input or
formatted output, as desired) to anyone who wants a copy.

If it's a choice between base64 and uuencode, I'd say go with base64 -
it's more resistant to mangling by non-ASCII systems. If you're
willing to commit to ASCII, btoa might be better - it uses base 85,
expanding by 4:5 rather than the 3:4 expansion produced by base64 or
uuencode.

However, the only reason I can see to use base64 instead of hex is a
desire to expand by only 3:4 instead of 1:2, and in my opinion that
verges on penny-wise and pound-foolish given the fundamental goals of
this archive format. As Sellam writes,

> Given the current trends of hard drives, image filesize is not an
> issue. Human readability is the prime concern.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
 X Against HTML mouse_at_rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received on Wed Aug 11 2004 - 17:09:21 BST