This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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:
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:
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():
Background to this problem is, that we are doing some webservice calls via axis, that use utf8 coded string.
Probably at the HTTP Connector level, you need to set the "URIEncoding" attribute: Connector config doc. From what i see in your logs, you are using JBoss 4.2.x. So the server.xml will be in JBOSS_HOME/server/< servername>/deploy/jboss-web.deployer
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.
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.
Joined: Dec 07, 2009
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.
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.