[
Lists Home |
Date Index |
Thread Index
]
On Thu, Mar 20, 2003 at 11:01:26AM -0800, Paul Prescod wrote:
<snip />
><?text/rtf version="1.5" encoding="ASCII"
> DocURI="http://www.biblioscape.com/rtf15_spec.htm";?>
>\rtf\....
>
><?application/zip version="1.0" encoding="ASCII" dataEncoding="binary"
>
>DocURI="http://www.pkware.com/products/enterprise/white_papers/appnote.html";?>
<snipMore />
I don't quite understand how this is to work.
The algorithm describing how one can understand the xml declaration *before*
the encoding is known (decoding both the character encoding and the fact
that this is XML at the same time) depends upon the magic-ness (as in
/etc/magic) of the string "<xml", which must appear at position 0, unless it
is preceded by one of 0xFEFF 0xFFEE.
The ability to figure out the encoding is dependent upon the restriction of
the identifier to a known set. XML parsers are, then, simply *verifying*
that this is XML as they discover the encoding, not solving for two
variables at once.
It seems to me that if you don't have a magic sequence, you have a much more
difficult problem; you can't figure out whether this: <?kzy irefvba="1.0"
rapbqvat="ebg13" ?> is XML or the "kzy" media type unless you already know
the encoding; you can't learn the encoding unless you know what the media
type is (so you can figure out that it's been rotated, in this case).
You might be able to make something out of the existence of the "/" in the
media type, but I have some doubts, because the length of the type
designation is variable. You might be able to specify that the media types
have to be ASCII, but that's awkward for the EBCDIC crowd, and quite
possibly for others as well (quite a few encodings *do* use ASCII as the
bottom 7 bits, after all, so perhaps it would be okay, as long as we don't
mind marginalizing (further) the ones that *don't*).
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
Do you ever feel like putting your fist through a window just so you
can feel something?
- References:
- Opinions
- From: Paul Prescod <paul@prescod.net>
|
