9-1,所以大家会发现在 Linux 操作系统上编译的类中源文件中的中文字符都出了 问题, 解决的办法就是在编译的时候添加 encoding 参数, 这样才能够与平台无关。 用法是
javac ?Cencoding GBK。
“ Java 字节码->虚拟机->操作系统”, Java 运行环境 (JRE) 分英文版和国际版,但 只有国际版才支持非英文字符。 Java 开发工具包 (JDK) 肯定支持多国字符,但并非所 有的
计算机用户都安装了 JDK 。很多操作系统及应用软件为了能够更好的支持 Java ,都 内嵌了 JRE 的国际版本,为自己支持多国字符提供了方便。
“操作系统->显示设备”,对于汉字来说,操作系统必须支持并能够显示它。英文操作
系统 如果不搭配特殊的应用
软件的话,是肯定不能够显示中文的。
还有一个问题,就是在 Java 编程过程中,对中文字符进行正确的编码转换。例如,向网页 输出中文字符串的时候,不论你是用
out.println(string);还是用
<%=string%>,都必须作 UNICODE 到 GBK 的转换,或者手动,或者自动。在 JSP 1.0中, 可以定义输出字符集,从而实现内码的自动转换。用法是
<%@page contentType=”text/html;charset=gb2312” %>
但是在一些
JSP 版本中并没有提供对输出字符集的支持,(例如 JSP 0.92),这就需要手 动编码输出了,方法非常多。最
常用的方法是
String s1 = request.getParameter(“key
word”);
String s2 = new String(s1.getBytes(“ISO-8859-1”),”GBK”);
getBytes 方法用于将中文字符以“ISO-8859-1”编码方式转化成字节数组,而“GBK” 是 目标编码方式。我们从以ISO-8859-1方式编码的数据库中读出中文字符串 s1 ,经过上述 转换过程, 在支持 GBK 字符集的操作系统和应用软件中就能够正确显示中文字符串 s2 。
Java 中文
问题的表层分析及处理
.CLASS 文件存放在服务器端,由客户端的浏览器运行 APPLET , APPLET 只起调入 FRAME 类等主程序的作用。界面包括 Textfield ,TextArea,List,Choice 等。 I.用 JDBC 执行 SELECT 语句从服务器端读取数据(中文)后,将数据用 APPEND 方法加到 TextArea(TA) ,不能正确显示。但加到 List 中时,大部分汉字却可正确显示。 将数据按“ISO-8859-1”
编码方式转化为字节数组,再按系统缺省编码方式 (Default Character Encoding) 转化为 STRING ,即可在 TA 和 List 中正确显示。 程序段如下:
在转换字符串时不采用系统默认编码方式,而直接采用“ GBK” 或者 “GB2312” ,在 A 和
B 两种情况下,从数据库取数据都没有问题。
II.处理方式与“取中文”相逆,先将 SQL 语句按系统缺省编码方式转化为字节数组,再按“ISO-8859-1”编码方式转化为 STRING ,最后送去执行,则中文信息可正确写入数据库。
程序段如下:
问题:如果客户机上存在 CLASSPATH 指向 JDK 的 CLASSES.ZIP 时(称为 A 情况),上述程序代码可正确执行。但是如果客户机只有浏览器,而没有 JDK 和 CLASSPATH
时(称为 B
情况),则汉字无法正确转换。
我们的分析:
1.经过测试,在 A 情况下,程序运行时系统的缺省编码方式为 GBK 或者 GB2312 。在 B 情况下,程序启动时浏览器的 JAVA 控制台中出现如下错误信息:
然后系统的缺省编码方式为“8859-1”。
2.如果在转换字符串时不采用系统缺省编码方式,而是直接采用 “GBK” 或“GB2312”,则在 A 情况下
程序仍然可正常运行,在 B 情况下,系统出现错误:
3. 在客户机上,把 JDK 的 CLASSES.ZIP 解压后,放在另一个目录中, CLASSPATH 只包含该目录。然后一边逐步删除该目录中的 .CLASS 文件,另一边运行测试程序,最后发现在一千多个 CLASS 文件中,只有一个是必不可少的,该文件是:
将该文件拷到服务器端和其它的类放在一起,并在程序的开头 IMPORT 它,在 B 情况下程序仍然无法正常运行。
4.在 A 情况下,如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ,