TOMCAT的WEBAPP汉化的项目,开始使用了反编译的方法在原来的字符串处理上加入
String newStr = new String(str.getBytes("ISO-8859-1"),"GBK");
来解决,JAVA将汉字的双字节作为单独的两个字节处理的问题。但显然不是一个好的方法。
后来发现Eclipse可以使用UTF-8的编码方式来处理多语言界面问题。(当然它帮助的搜索结果有时还是乱码)。于是将资源中的中文字符串文件都用UTF-8作了转换(jdk的 native2ascii.exe),变成/uhhhh/uhhhh;
谁知还是不行,因为系统还用XML的PARSER来实现资源,所以将/uhhhh变成XML的转义符表示的方式:
终于一切都OK了,以为万事大吉;谁知机器一重启,原来的中文都变成了“??”经过确认,机器启动时,JVM没有识别出正确的LOCALE,只好自己指定了,经过试验,file.encoding是可以作为设置参数的,在JAVASERVICE的启动参数中加入-Dfile.encoding=GBK;(如果直接改注册表,除了添一个参数外,还要把参数的计数加1);所有JVM系统参数均可以通过-D来设置。
可能是因为系统是英文的Windows2000的缘故,才有这个问题。
String newStr = new String(str.getBytes("ISO-8859-1"),"GBK");
来解决,JAVA将汉字的双字节作为单独的两个字节处理的问题。但显然不是一个好的方法。
后来发现Eclipse可以使用UTF-8的编码方式来处理多语言界面问题。(当然它帮助的搜索结果有时还是乱码)。于是将资源中的中文字符串文件都用UTF-8作了转换(jdk的 native2ascii.exe),变成/uhhhh/uhhhh;
谁知还是不行,因为系统还用XML的PARSER来实现资源,所以将/uhhhh变成XML的转义符表示的方式:
一个字符引用引用 ISO/IEC 10646 字符集中的一个字符。例如不能用输入设备直接输入的字符。 字符引用 [66] CharRef ::= '&#' [0-9]+ ';' | '&#x' [0-9a-fA-F]+ ';' [WFC: 合法字符]
所以每个汉字都变为&#xhhhh;终于一切都OK了,以为万事大吉;谁知机器一重启,原来的中文都变成了“??”经过确认,机器启动时,JVM没有识别出正确的LOCALE,只好自己指定了,经过试验,file.encoding是可以作为设置参数的,在JAVASERVICE的启动参数中加入-Dfile.encoding=GBK;(如果直接改注册表,除了添一个参数外,还要把参数的计数加1);所有JVM系统参数均可以通过-D来设置。
可能是因为系统是英文的Windows2000的缘故,才有这个问题。