On Jun 2, 0:48, Tony Duell wrote:
> > {Apple
][<00>soft<00>trks:<40><00>rpm:<15><255><00>{trk:<00><00>logical<00>
> >
length:<12><34><00>sectors:<10>{sector:<00><00>{sync{bytes:<16><00>value:<255><00>}{header:GCR<00>trk:<00><00>sec:<00><00>physsec:<00><00>head:<00><00>size:<00><01><00>}{data:<
> > ---256 binary bytes---- >crc:<xx><xx><00>}}sector: [repeat as reqd]
> > }}{track: [repeat as reqd] }}
>
> Actually, that seems to give you the worst of all worlds....
>
> The 'tags' are in ascii, so they're long, hard to search for, etc. And
> yet the data is in binary, so the file is not printable. You can't cat it
> to the screen to read the header information.
No, but you can easily see it in any sensible editor (my definition of
"sensible" has always included the ability to show binary or at least
control characters :-))...
> I must admit that I find files containing printable text information
> mixed up with binary data to be _very_ annoying unless there's a good
> reason for doing it.
>
> If you must use some kind of markup language, at least encode the data as
> strings of hex digits, or base-64 encoding or something like that.
I don't have any objection to that, in fact I'm inclined to agree, but I
felt others don't want to take up more space than necessary. If encoded,
I'd go for base64. It's the most efficient of the common schemes (hex,
uuencoded, base64), has none of the ambiguities of uuencode (there are some
very broken uu..code implementations around, because it's not fully
specified), and if anyone does want to read it manually, a decoder is only
a few lines of <language of choice>.
On the other hand, hex has some advantages: easy to read, very easy to
{en,de}code, and it would be more appropriate, perhaps, for binary values
in tags (assuming the values weren't just written in ASCII in the first
place).
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
Received on Fri Jun 02 2000 - 03:14:56 BST