I have done some more investigation into this on my machine. The following java
class:
public class Default {
public static void main(String[] args) {
System.out.println("Encoding: " +
System.getProperty("file.encoding"));
System.out.println(java.net.URLEncoder.encode(args[0]));
}
}
Yields:
>java -Dfile.encoding=UTF-8 Default �
Encoding: UTF-8
%C3%BF
>java Default �
Encoding: Cp1252
%FF
... which would indicate that somewhere in JMeter the default encoding is being
set up for UTF-8
John
-----Original Message-----
From: Michael Stover [mailto:[EMAIL PROTECTED]
Sent: 21 April 2005 16:29
To: [email protected]
Subject: Re: Encoding of variables on an HTTP Post gives strange results
It's possible this is a case where the UrlEncode.encode() method needs a
locale passed to it to work correctly - which is a new method in jdk1.4
only, whereas JMeter tries to be jdk1.3 compatible.
I'm not sure which locale you're in - are you using the default locale
for your region or is your computer set up with a different locale
setting?
-Mike
On Thu, 2005-04-21 at 16:11 +0100, sebb wrote:
> Which version of JMeter? JVM? OS?
>
> Does the same behaviour occur with GET parameters?
>
> It might perhaps be a problem with the default platform encoding which
> could lead Jmeter to think the input was different.
> Just a thought.
>
> I may have time to investigate this tonight.
>
> S.
> On 4/21/05, Sweet-Escott, John <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > I have a jmeter variable that contains the string A� (that is a capital A
> > (ASCII 65) followed by y umlaut (ASCII 255)... in case this gets mangled by
> > email).
> >
> > When I use this variable in the HTTP sampler as a POST variable with
> > encoding enabled it is encoded as A%C3%BF (that is A followed by A tilde
> > (ASCII 195) followed by upside down question mark (ASCII 191)) in the
> > request. This does not seem right.
> >
> > If I do not encode, it is sent as y umlaut (which actually seems to
> > work...). However I do need the encoding when the variable contains the
> > value A% (which is encoded correctly as A%25.
> >
> > Any thoughts... could this be a problem with handling ASCII values > 127?
> >
> > Regards
> > John
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
