On 07/08/2009, 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
JMeter does in fact intercept Strings before passing them to the default PrettyPrintWriter. However it does not change the strings (except to convert null to the empty string). JMeter handles the charset encoding by creating the OutputStreamWriter with the charset. As far as JMeter is concerned, there is no need to change anything because the current code works. It's not clear how to fix this without breaking compatibility with existing JMX and JTL files. > -- > - Pieter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [email protected] > For additional commands, e-mail: > [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
