Rainer Rettweiler

Greenhorn
+ Follow
since Dec 07, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rainer Rettweiler

Paul Clapham wrote:I would rather ask why your code needs to convert characters to bytes in the first place. Or if there's some reason, I would ask why you are forced to use the system's default character set.



My code does not have to convert strings into bytes. I just put this few test lines of code to show where I guess the problem lies.

The webservice call we do is:

public java.lang.String sendSMS(java.lang.String phoneNumber, java.lang.String message) throws java.rmi.RemoteException;

We use a web service client generated with the eclipse wizard, using axis1, selecting bottom-up-java-bean-web-service-client. All classes concerning web service are generated with this wizard. The call takes a string "message". This string needs to contain greek characters. I see no possibility to explicitly set the encoding here.

When I debug the HTTP request made by sendSMS, I see that the greek characters are defekt already in this HTTP request. This is no problem on the web service host side. My HTTP request is already wrong. To me it looks like somewhere in the request generation the default encoding is used, but the wrong one. Therefore my test with String.getBytes().

But this is only the case on my unix server. The same binaries run perfekt on my PC. Same jboss, same jdk, same application ear.
14 years ago

Probably at the HTTP Connector level, you need to set the "URIEncoding" attribute



Thank you very much Jaikiran for your reponse!

But isn't this parameter only concerning URL encodig, but not content encoding of HTTP requests? Nevertheless, I tried it, but the results keep the same. Same output of my test coding (of corse) and also same results with the greek characters in the webservice calls. The receiver of the ws calls just gets a string with bytes 63,63 instead of -50,-69.

14 years ago
Hi.

I have a wired problem within my jboss environment.

See the following test coding:



Explanation:

Line-1: The greek character lambda is encoded in the String utf8lambda. The encoding used is explicitly given by parameter. This line of code is not dependend from any encoding properties of the envirorment.
Line-2: Prints out the name of the default character set. This is the character set used for String encoding by default, it comes from envirorment properties. It is set via java runtime parameter "-Dfile.encoding=UTF8".
Line-3: Prints out the bytes of the encoded lambda String. The method String.getBytes() without parameter should use "the plattform's default character set".
Line-4: Prints out the bytes of the encoded lambda String. The method String.getBytes(String charsetName) uses this given character set to decode the string.

The expected output of this would be:

UTF-8
bytes: -50,-69
bytes: -50,-69

Line 3 and 4 result in the same output, because the in both cases the default character set is used for decoding.
I get this output as I run this in a stand-alone java app on my unix server.

But as I run this in the jboss on on the same unix server, I get:

UTF-8
bytes: 63,63
bytes: -50,-69

The method String.getBytes() without parameter seems not to use the default character set, but mayby US-ASCII instead. Why? What can I do make my java behave as expected here?

Background to this problem is, that we are doing some webservice calls via axis, that use utf8 coded string. Special characters are scrambled, e.g. greek characters result in a small square (63). This does always happen, if String.getBytes() uses the wrong encoding. There seems to be a direct relation.

Any hints are welcome - this is very urgent - thanks a lot!

Attached you find the system properties of my environment, get with System.getProperties():


14 years ago