On 8/20/2010 12:41 PM, Ralph Versteegen wrote:
On 21 August 2010 03:58, Mike Caron<[email protected]> wrote:
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.
Change of plan required.
' "�" is not permitted, however, as the null character is one of
the control characters excluded from XML, even when using a numeric
character reference.[14] An alternative encoding mechanism such as
Base64 is needed to represent such characters. ' - Wikipedia
And I just confirmed libxml2 spits.
Damn. I guess that kind of makes sense, though.
Maybe... emit a <null/> element instead? Ugh.
Or, Base64 it. Sigh.
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
