Name: clC74495 Date: 06/11/98
When you run a class which takes 8-bit arguments via "java",
the arguments are passed correctly, but if you run it via
"jre", the arguments are corrupted when they are given to
the class.
Here's a test program:
% cat EchoCmd.java
class EchoCmd {
static String HexString(String s) {
String hexstr = "";
for (int i = 0; i < s.length(); i++) {
hexstr += Integer.toString((short)s.charAt(i),16) + " ";
}
return hexstr;
}
public static void main(String[] arg) {
for (int i = 0; i < arg.length; i++) {
System.out.println("arg[" + i + "]=" + arg[i]);
System.out.println(" string = " + arg[i]);
System.out.println(" hex = " + HexString(arg[i]));
}
}
}
Here's the typical result (on Solaris):
% java EchoCmd abc
arg[0]=abc
string = abc
hex = 61 62 63
% java EchoCmd <aacute><b><ccedil>
# input is Latin-1 characters. I used above representation
since I cannot type them here.
arg[0]=<aacute><b><ccedil>
# input characters are echoed back correctly
string = <aacute><b><ccedil>
hex = e1 62 e7
% jre EchoCmd <aacute><b><ccedil>
arg[0]=b
# 8-bit characters are replaced with 0x80.
string = b
hex = 80 62 80
This problem seems to be platform independent. We see this
behavior on Solaris as well as on NT. We are using JDK1.1.6.
We put rt.jar, i18n.jar into the CLASSPATH, but we could not
get the expected result. Putting -green / -native to the
command line does not make any difference.
Could there be any work around for this problem?
Thanks.
(Review ID: 33342)
======================================================================
- duplicates
-
JDK-4097707 (1.1) jre fails to receive platform dependent encoded string from command line
-
- Closed
-