On 21 August 2010 04:43, Mike Caron <[email protected]> wrote: > 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.
Well, I know next to nothing about XML, what's the idiomatic way to do that? Add a special attribute to nodes containing base64-encoded data, like <foo base="64">assdfasdf234</foo> ? >>>> 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 > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
