On 8/20/2010 11:45 AM, Ralph Versteegen wrote:
On 21 August 2010 02:24, Mike Caron<[email protected]> wrote:
On 8/20/2010 9:58 AM, Ralph Versteegen wrote:
Currently reload2xml can't properly export binary data stored in
strings in reload files. It would be nice to be able to hand edit xml
and convert back. What's the preferred way to write binary?&#nnn;
escape codes, or that Base64 stuff? (Is that actually part of the xml
standard?)
Strictly speaking, we only really need to escape characters below 32.
Everything else should be okay to write out.
Follow-up question: what about bytes above 127? Is there a chance of
confusing xml parsers into guessing UTF8 encoding? I suppose it
doesn't matter too much, since we can force libxml2 to read with ASCII
encoding (but it would be nice to know that we have to do so).
The best way to handle this, actually, would be to add the XML header,
which allows you to specify the encoding. In our case, it should look
something like:
<?xml version="1.0" encoding="iso-8859-1"?>
In light of that, I would prefer the&#nnnn; syntax, since it means that no
one has to do any extra work to process the resulting XML file. If you used
Base64 (which has nothing to do with XML), you'd have to mark it as such in
order to distinguish it from a regular string that just so happens to look
like Base64.
OK, cool. I'll add that then soonish (unless you jumped on the chance to do so).
No, go ahead.
I had thought there was some semi-standard for base64 strings in xml:
http://www.xml.com/pub/a/98/07/binary/binary.html
That article just explores different ways of embedding binary data.
There's no standard for this sort of thing. Base64 would be the closest
thing to a "proper" solution, being used in different applications
already (eg, embedded resources in HTML). The drawback is a flat 33%
size increase, compared to the raw data.
In comparison, the "entity" solution would be a 600% increase for
encoded bytes, and 0% for anything else. (plus, no special handling
required for parsers)
The MIME idea proposed in that article is interesting, but even more
complicated than Base64, and not really suited for our purposes.
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
