>or should someone (JMeter or XStream?) encapsulate this in CDATA so it isn't parsed by a parser? This wont work as far as I know. These characters arent allowed anywhere in an xml document. If you need to store binary data into an XML document you either encode it (say base64 or something) or you store it separately and have a link in your xml document to that location (or dont use XML use some other format) regards deepak
On Fri, Aug 7, 2009 at 2:15 AM, Pieter Ennes <[email protected]> wrote: > Hi, > > On 04-08-09 08:14, Pieter Ennes wrote: > >> Hello sebb, >> >> On 04-08-09 00:37, sebb wrote: >> >>> On 04/08/2009, Pieter Ennes<[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I have some weird binary data POSTed in a HTTP request, resulting in >>>> this >>>> XML in the .jmx: >>>> >>>> <stringProp >>>> name="Argument.value">30172 [...] >>>> >>>> Many XML parsers fail on this with a message: >>>> >>>> xmlParseCharRef: invalid xmlChar value 65535 >>>> >>>> If I understand XML 1.0 [1] correctly, then these are indeed outside >>>> of the >>>> allowed range. My question is: How can this POST data be stored in >>>> the .jmx >>>> so that xml parsers can read it? >>>> >>> >>> JMeter does not convert the data directly, that is done by XStream. >>> >> >> Ok, I'll check into that... thanks. >> > > I've been reading some bits and pieces about this and one of the > observations I'm having from the XStream guys now[1][2] is that XStream > itself does not have a notion of encoding, therefore making the client app > is responsible for it. > > I'm not quite sure what this effectively means in this case though. Should > JMeter override the Writer class[1] to invent its own encoding for these > characters? Or should someone (JMeter or XStream?) encapsulate this in CDATA > so it isn't parsed by a parser? > > Maybe someone with more experience can give a hint where/how to nail this. > > [1] http://xstream.codehaus.org/faq.html#XML_write_UTF8 > [2] http://thread.gmane.org/gmane.comp.java.xstream.user/3727/focus=3731 > > -- > - Pieter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
