1 Jun
2000
1 Jun
'00
8:14 p.m.
On Jun 2, 0:48, Tony Duell wrote:
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 :-))...
> {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. 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