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. >> 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
