<%@page contentType="text/html;charset=GB2312"%> -----------> <%@page contentType="text/html"%> then use constr: String(string1.getBytes("GB2312"),"ISO-8859-1"); or : String(string1.getBytes("ISO-8859-1"),"GB2312");
to lci21:根据你的解决方案知道你是个很好学的朋友，收集了不少资料，自己也做了不少测试，也得到了满意的答案；同时也能看出来你的这些测试是在你自己的pc机通过tomcat或其他什么软件环境做的。其实大多人都知道乱码问题几乎都可以用编码来解决；但我觉得这是治标不治本的做法。（其实这样的方法也极其简单，就是那几个编码转来转去罢了）所以我觉得要解决乱码问题的根本不是在每一行代码里去编码，而是在理解某些原理后想办法从程序运行的环境入手。希望有人支持我的观点。
我支持你！ Java 语言默认的编码方式是UNICODE 而我们用的都是GB2312的
to ls:把下面这一篇文章好好读读，希望对你又说帮助：Java 编程技术中汉字问题的分析及解决
在基于 Java 语言的编程中，我们经常碰到汉字的处理及显示的问题。一大堆看不懂的乱码肯定不是我们愿意看到的显示效果，怎样才能够让那些汉字正确显示呢？Java 语言默认的编码方式是UNICODE ，而我们中国人通常使用的文件和数据库都是基于 GB2312 或者 BIG5 等方式编码的，怎样才能够恰当地选择汉字编码方式并正确地处理汉字的编码呢？本文将从汉字编码的常识入手，结合 Java 编程实例，分析以上两个问题并提出解决它们的方案。 现在 Java 编程语言已经广泛应用于互联网世界，早在 Sun 公司开发 Java 语言的时候，就已经考虑到对非英文字符的支持了。Sun 公司公布的 Java 运行环境（JRE）本身就分英文版和国际版，但只有国际版才支持非英文字符。不过在 Java 编程语言的应用中，对中文字符的支持并非如同 Java Soft 的标准规范中所宣称的那样完美，因为中文字符集不只一个，而且不同的操作系统对中文字符的支持也不尽相同，所以会有许多和汉字编码处理有关的问题在我们进行应用开发中困扰着我们。有很多关于这些问题的解答，但都比较琐碎，并不能够满足大家迫切解决问题的愿望，关于 Java 中文问题的系统研究并不多，本文从汉字编码常识出发，分析 Java 中文问题，希望对大家解决这个问题有所帮助。 汉字编码的常识 我们知道，英文字符一般是以一个字节来表示的，最常用的编码方法是 ASCII 。但一个字节最多只能区分256个字符，而汉字成千上万，所以现在都以双字节来表示汉字，为了能够与英文字符分开，每个字节的最高位一定为1，这样双字节最多可以表示64K格字符。我们经常碰到的编码方式有 GB2312、BIG5、UNICODE 等。关于具体编码方式的详细资料，有兴趣的读者可以查阅相关资料。我肤浅谈一下和我们关系密切的 GB2312 和 UNICODE。GB2312 码，中华人民共和国国家标准汉字信息交换用编码，是一个由中华人民共和国国家标准总局发布的关于简化汉字的编码，通行于中国大陆地区及新加坡，简称国标码。两个字节中，第一个字节（高字节）的值为区号值加32（20H），第二个字节（低字节）的值为位号值加32（20H），用这两个值来表示一个汉字的编码。UNICODE 码是微软提出的解决多国字符问题的多字节等长编码，它对英文字符采取前面加“0”字节的策略实现等长兼容。如 “A” 的 ASCII 码为0x41，UNICODE 就为0x00，0x41。利用特殊的工具各种编码之间可以互相转换。 Java 中文问题的初步认识 我们基于 Java 编程语言进行应用开发时，不可避免地要处理中文。Java 编程语言默认的编码方式是 UNICODE，而我们通常使用的数据库及文件都是基于 GB2312 编码的，我们经常碰到这样的情况：浏览基于 JSP 技术的网站看到的是乱码，文件打开后看到的也是乱码，被 Java 修改过的数据库的内容在别的场合应用时无法继续正确地提供信息。 String sEnglish = “apple”; String sChinese = “苹果”; String s = “苹果 apple ”; sEnglish 的长度是5，sChinese的长度是4，而 s 默认的长度是14。对于 sEnglish来说， Java 中的各个类都支持得非常好，肯定能够正确显示。但对于 sChinese 和 s 来说，虽然 Java Soft 声明 Java 的基本类已经考虑到对多国字符的支持（默认 UNICODE 编码），但是如果操作系统的默认编码不是 UNICODE ，而是国标码等。从 Java 源代码到得到正确的结果，要经过 “Java 源代码-> Java 字节码-> ;虚拟机->操作系统->显示设备”的过程。在上述过程中的每一步骤，我们都必须正确地处理汉字的编码，才能够使最终的显示结果正确。 “ Java 源代码-> Java 字节码”，标准的 Java 编译器 javac 使用的字符集是系统默认的字符集，比如在中文 Windows 操作系统上就是 GBK ,而在 Linux 操作系统上就是ISO-8859-1，所以大家会发现在 Linux 操作系统上编译的类中源文件中的中文字符都出了问题，解决的办法就是在编译的时候添加 encoding 参数，这样才能够与平台无关。用法是 javac –encoding GBK。 “ Java 字节码->虚拟机->操作系统”， Java 运行环境 （JRE） 分英文版和国际版，但只有国际版才支持非英文字符。 Java 开发工具包 （JDK） 肯定支持多国字符，但并非所有的计算机用户都安装了 JDK 。很多操作系统及应用软件为了能够更好的支持 Java ，都内嵌了 JRE 的国际版本，为自己支持多国字符提供了方便。 “操作系统->显示设备”，对于汉字来说，操作系统必须支持并能够显示它。英文操作系统如果不搭配特殊的应用软件的话，是肯定不能够显示中文的。 还有一个问题，就是在 Java 编程过程中，对中文字符进行正确的编码转换。例如，向网页输出中文字符串的时候，不论你是用 out.println(string); // string 是含中文的字符串 还是用 ，都必须作 UNICODE 到 GBK 的转换，或者手动，或者自动。在 JSP 1.0中，可以定义输出字符集，从而实现内码的自动转换。用法是 但是在一些 JSP 版本中并没有提供对输出字符集的支持，（例如 JSP 0.92），这就需要手动编码输出了，方法非常多。最常用的方法是 String s1 = request.getParameter(“keyword”); String s2 = new String(s1.getBytes(“ISO-8859-1”),”GBK”); getBytes 方法用于将中文字符以“ISO-8859-1”编码方式转化成字节数组，而“GBK” 是目标编码方式。我们从以ISO-8859-1方式编码的数据库中读出中文字符串 s1 ，经过上述转换过程，在支持 GBK 字符集的操作系统和应用软件中就能够正确显示中文字符串 s2 。 Java 中文问题的表层分析及处理 背景 开发环境 JDK1.15 Vcafe2.0 JPadPro 服务器端 NT IIS Sybase System Jconnect（JDBC） 客户端 IE5.0 Pwin98 .CLASS 文件存放在服务器端，由客户端的浏览器运行 APPLET ， APPLET 只起调入 FRAME 类等主程序的作用。界面包括 Textfield ，TextArea，List，Choice 等。 I. 取中文 用 JDBC 执行 SELECT 语句从服务器端读取数据（中文）后，将数据用 APPEND 方法加到 TextArea（TA） ，不能正确显示。但加到 List 中时，大部分汉字却可正确显示。 将数据按“ISO-8859-1” 编码方式转化为字节数组，再按系统缺省编码方式 （Default Character Encoding） 转化为 STRING ，即可在 TA 和 List 中正确显示。 程序段如下： dbstr2 = results.getString(1); //After reading the result from DB server，converting it to string. dbbyte1 = dbstr2.getBytes(“iso-8859-1”); dbstr1 = new String(dbbyte1); 在转换字符串时不采用系统默认编码方式，而直接采用“ GBK” 或者 “GB2312” ,在 A 和 B 两种情况下，从数据库取数据都没有问题。 II. 写中文到数据库 处理方式与“取中文”相逆，先将 SQL 语句按系统缺省编码方式转化为字节数组，再按“ISO-8859-1”编码方式转化为 STRING ，最后送去执行，则中文信息可正确写入数据库。 程序段如下： sqlstmt = tf_input.getText(); //Before sending statement to DB server，converting it to sql statement. dbbyte1 = sqlstmt.getBytes(); sqlstmt = newString(dbbyte1,”iso-8859-1”); _stmt = _con.createStatement(); _stmt.executeUpdate(sqlstmt); …… 问题：如果客户机上存在 CLASSPATH 指向 JDK 的 CLASSES.ZIP 时（称为 A 情况），上述程序代码可正确执行。但是如果客户机只有浏览器，而没有 JDK 和 CLASSPATH 时（称为 B 情况），则汉字无法正确转换。 我们的分析： 1.经过测试，在 A 情况下，程序运行时系统的缺省编码方式为 GBK 或者 GB2312 。在 B 情况下，程序启动时浏览器的 JAVA 控制台中出现如下错误信息： Can't find resource for sun.awt.windows.awtLocalization_zh_CN 然后系统的缺省编码方式为“8859-1”。 2.如果在转换字符串时不采用系统缺省编码方式，而是直接采用 “GBK” 或“GB2312”，则在 A 情况下程序仍然可正常运行，在 B 情况下，系统出现错误： UnsupportedEncodingException。 3.在客户机上，把 JDK 的 CLASSES.ZIP 解压后，放在另一个目录中， CLASSPATH 只包含该目录。然后一边逐步删除该目录中的 .CLASS 文件，另一边运行测试程序，最后发现在一千多个 CLASS 文件中，只有一个是必不可少的，该文件是： sun.io.CharToByteDoubleByte.class。 将该文件拷到服务器端和其它的类放在一起，并在程序的开头 IMPORT 它，在 B 情况下程序仍然无法正常运行。 4.在 A 情况下，如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ，则程序运行时测得默认编码方式为“8859-1”，否则为 “GBK” 或 “GB2312” 。 如果 JDK 的版本为1.2以上的话，在 B 情况下遇到的问题得到了很好的解决，测试的步骤同上，有兴趣的读者可以尝试一下。 Java 中文问题的根源分析及解决 在简体中文 MS Windows 98 + JDK 1.3 下，可以用 System.getProperties() 得到 Java 运行环境的一些基本属性，类 PoorChinese 可以帮助我们得到这些属性。 类 PoorChinese 的源代码： public class PoorChinese { public static void main(String[] args) { System.getProperties().list(System.out); } } 执行 java PoorChinese 后，我们会得到: 系统变量 file.encoding 的值为 GBK ，user.language 的值为 zh ， user.region 的值为 CN ，这些系统变量的值决定了系统默认的编码方式是 GBK 。 在上述系统中，下面的代码将 GB2312 文件转换成 Big5 文件，它们能够帮助我们理解 Java 中汉字编码的转化: import java.io.*; import java.util.*; public class gb2big5 { static int iCharNum=0; public static void main(String[] args) { System.out.println("Input GB2312 file, output Big5 file."); if (args.length!=2) { System.err.println("Usage: jview gb2big5 gbfile big5file"); System.exit(1); } String inputString = readInput(args[0]); writeOutput(inputString,args[1]); System.out.println("Number of Characters in file: "+iCharNum+"."); } static void writeOutput(String str, String strOutFile) { try { FileOutputStream fos = new FileOutputStream(strOutFile); Writer out = new OutputStreamWriter(fos, "Big5"); out.write(str); out.close(); } catch (IOException e) { e.printStackTrace(); e.printStackTrace(); } } static String readInput(String strInFile) { StringBuffer buffer = new StringBuffer(); try { FileInputStream fis = new FileInputStream(strInFile); InputStreamReader isr = new InputStreamReader(fis, "GB2312"); Reader in = new BufferedReader(isr); int ch; while ((ch = in.read()) > -1) { iCharNum += 1; buffer.append((char)ch); } in.close(); return buffer.toString(); } catch (IOException e) { e.printStackTrace(); return null; } } } 编码转化的过程如下： ByteToCharGB2312 CharToByteBig5 GB2312------------------>Unicode------------->Big5 执行 java gb2big5 gb.txt big5.txt ，如果 gb.txt 的内容是“今天星期三”，则得到的文件 big5.txt 中的字符能够正确显示；而如果 gb.txt 的内容是“情人节快乐”，则得到的文件 big5.txt 中对应于“节”和“乐”的字符都是符号“？”（0x3F），可见 sun.io.ByteToCharGB2312 和 sun.io.CharToByteBig5 这两个基本类并没有编好。 正如上例一样， Java 的基本类也可能存在问题。由于国际化的工作并不是在国内完成的，所以在这些基本类发布之前，没有经过严格的测试，所以对中文字符的支持并不像 Java Soft 所声称的那样完美。前不久，我的一位技术上的朋友发信给我说，他终于找到了 Java Servlet 中文问题的根源。两周以来，他一直为 Java Servlet 的中文问题所困扰，因为每面对一个含有中文字符的字符串都必须进行强制转换才能够得到正确的结果（这好象是大家公认的唯一的解决办法）。后来，他确实不想如此继续安分下去了，因为这样的事情确实不应该是高级程序员所要做的工作，他就找出 Servlet 解码的源代码进行分析，因为他怀疑问题就出在解码这部分。经过四个小时的奋斗，他终于找到了问题的根源所在。原来他的怀疑是正确的， Servlet 的解码部分完全没有考虑双字节，直接把 %XX 当作一个字符。（原来 Java Soft 也会犯这幺低级的错误！） 如果你对这个问题有兴趣或者遇到了同样的烦恼的话，你可以按照他的步骤对 Servlet.jar 进行修改： 找到源代码 HttpUtils 中的 static private String parseName ，在返回前将 sb（StringBuffer） 复制成 byte bs[] ，然后 return new String(bs,”GB2312”)。作上述修改后就需要自己解码了： HashTable form=HttpUtils .parseQueryString(request.getQueryString())或者 form=HttpUtils.parsePostData(……) 千万别忘了编译后放到 Servlet.jar 里面。 五、 关于 Java 中文问题的总结 Java 编程语言成长于网络世界，这就要求 Java 对多国字符有很好的支持。 Java 编程语言适应了计算的网络化的需求，为它能够在网络世界迅速成长奠定了坚实的基础。 Java 的缔造者 （Java Soft） 已经考虑到 Java 编程语言对多国字符的支持，只是现在的解决方案有很多缺陷在里面，需要我们付诸一些补偿性的措施。而世界标准化组织也在努力把人类所有的文字统一在一种编码之中，其中一种方案是 ISO10646 ，它用四个字节来表示一个字符。当然，在这种方案未被采用之前，还是希望 Java Soft 能够严格地测试它的产品，为用户带来更多的方便。 附一个用于从数据库和网络中取出中文乱码的处理函数，入参是有问题的字符串，出参是问题已经解决了的字符串。 String parseChinese(String in) { String s = null; byte temp []; if (in == null) { System.out.println("Warn:Chinese null founded!"); return new String(""); } try { temp=in.getBytes("iso-8859-1"); temp=in.getBytes("iso-8859-1"); s = new String(temp); } { System.out.println("Warn:Chinese null founded!"); return new String(""); } try { temp=in.getBytes("iso-8859-1"); s = new String(temp); } catch(UnsupportedEncodingException e) { System.out.println (e.toString()); } return s; }
to ls: 我再说两句自己的观点： 我觉得先在这个时代技术发展非常快，我们不可能对各个方面都去自己一点一点的分析，然后去寻找解决方案（除非不得已），因为我们毕竟不是做理论研究的，我们是作应用开发的。虽然，我们知其所以然会更好，也许我们的时间不允许，如果说，让你做一项开发，你中间遇到了一些问题，网上已经有很多现成的解决方法，我们何必要自己在耗时费力的再去分析，去寻求答案呢。如果是这样的话，也许等我们找到答案，这个项目早就应该结束了。我觉得，等我们时间充足时，再知其所以然也不迟！
to lci21: 谢谢你的指点； 不过有两点我也要说明一下。 一，BBS是大家在一起讨论的地方，我觉得就是应该有更多的自己的想法和心得； 二，我们不要为了回答问题而回答问题。回答别人的问题不是到某个地方去抄一段放在那里就可以了，应该有自己的某些观点；因为这些资料到网上谁都能找上一大堆，如果没有自己的观点是很难让人信服这些资料的，因为感觉连你自己都没去理解这些东西，别人为什么要相信呢？
to lci21: 对不起，我这段时间一直是心情不好。我是不是显得很幼稚，其实我已经工作4年多了（都怪我不求上进，到现在还跟刚毕业时水平差不多），前两年做的是c、c++的东西；中间做的是电脑买卖（落难）；java只做了两年不到。刚开始的时候我也喜欢到bbs上去炫耀自己的看到过的东东，因为觉得这样可以给同行们带来帮助，但等做完几个项目（惭愧，到现在才做三个项目）后才发现，实际遇到的问题并非所有都如资料所说的那样解决，并不是说他们错了，只是是否真的实用，比如这个乱码问题（我们的项目都日本人的，这个问题更严重），我们当时碰到了，也去找过资料，但大多数都是如你所说的那样，‘编码’；我们也试过了，确实可行，但它确实不实用呀。其实真正的解决办法是修改（系统、应用程序、数据库）服务器的环境参数设置，但很少有人注意到这一点。比如还有，用户从本地假冒一个http的请求，如何来阻止呢（比如咱们现在用的bbs,地址栏不是有http://www.csdn.net/expert/index.asp?room=28字样吗？我们现在可以随便把28改为其它数字如27，那我们怎么知道这27是通过手工输入的还是正常途径得到的呢？显然用session实现是不现实的），象这些如果不从实际项目中摸索是很难知道的。
那我先说一句吧：
<%@page contentType="text/html;charset=GB2312"%>是提示服务器，下面内容的编码是基于gb2312的，所以如果你服务器有能力就按gb2312来处理吧。
而<meta http-equiv="Content-Type" content="text/html; charset=gb2312">提示浏览器（客户端），下面的内容是基于gb2312的，如果你可以就以gb2312来显示。
如果这两个语句中只有一句或没有的话那么应该服务器和浏览器应该按什么来处理啦？(今天没心情说)
如果大家明白这两句话后，对编码问题的理解是不是可以更进一步？
还有有哪个项目里面每一个参数处理都进行编码，为什么解决问题不从根源找起呢？
----------->
<%@page contentType="text/html"%>
then use constr:
String(string1.getBytes("GB2312"),"ISO-8859-1");
or :
String(string1.getBytes("ISO-8859-1"),"GB2312");
Java 语言默认的编码方式是UNICODE
而我们用的都是GB2312的
在基于 Java 语言的编程中，我们经常碰到汉字的处理及显示的问题。一大堆看不懂的乱码肯定不是我们愿意看到的显示效果，怎样才能够让那些汉字正确显示呢？Java 语言默认的编码方式是UNICODE ，而我们中国人通常使用的文件和数据库都是基于 GB2312 或者 BIG5 等方式编码的，怎样才能够恰当地选择汉字编码方式并正确地处理汉字的编码呢？本文将从汉字编码的常识入手，结合 Java 编程实例，分析以上两个问题并提出解决它们的方案。 现在 Java 编程语言已经广泛应用于互联网世界，早在 Sun 公司开发 Java 语言的时候，就已经考虑到对非英文字符的支持了。Sun 公司公布的 Java 运行环境（JRE）本身就分英文版和国际版，但只有国际版才支持非英文字符。不过在 Java 编程语言的应用中，对中文字符的支持并非如同 Java Soft 的标准规范中所宣称的那样完美，因为中文字符集不只一个，而且不同的操作系统对中文字符的支持也不尽相同，所以会有许多和汉字编码处理有关的问题在我们进行应用开发中困扰着我们。有很多关于这些问题的解答，但都比较琐碎，并不能够满足大家迫切解决问题的愿望，关于 Java 中文问题的系统研究并不多，本文从汉字编码常识出发，分析 Java 中文问题，希望对大家解决这个问题有所帮助。 汉字编码的常识 我们知道，英文字符一般是以一个字节来表示的，最常用的编码方法是 ASCII 。但一个字节最多只能区分256个字符，而汉字成千上万，所以现在都以双字节来表示汉字，为了能够与英文字符分开，每个字节的最高位一定为1，这样双字节最多可以表示64K格字符。我们经常碰到的编码方式有 GB2312、BIG5、UNICODE 等。关于具体编码方式的详细资料，有兴趣的读者可以查阅相关资料。我肤浅谈一下和我们关系密切的 GB2312 和 UNICODE。GB2312 码，中华人民共和国国家标准汉字信息交换用编码，是一个由中华人民共和国国家标准总局发布的关于简化汉字的编码，通行于中国大陆地区及新加坡，简称国标码。两个字节中，第一个字节（高字节）的值为区号值加32（20H），第二个字节（低字节）的值为位号值加32（20H），用这两个值来表示一个汉字的编码。UNICODE 码是微软提出的解决多国字符问题的多字节等长编码，它对英文字符采取前面加“0”字节的策略实现等长兼容。如 “A” 的 ASCII 码为0x41，UNICODE 就为0x00，0x41。利用特殊的工具各种编码之间可以互相转换。 Java 中文问题的初步认识 我们基于 Java 编程语言进行应用开发时，不可避免地要处理中文。Java 编程语言默认的编码方式是 UNICODE，而我们通常使用的数据库及文件都是基于 GB2312 编码的，我们经常碰到这样的情况：浏览基于 JSP 技术的网站看到的是乱码，文件打开后看到的也是乱码，被 Java 修改过的数据库的内容在别的场合应用时无法继续正确地提供信息。 String sEnglish = “apple”; String sChinese = “苹果”; String s = “苹果 apple ”; sEnglish 的长度是5，sChinese的长度是4，而 s 默认的长度是14。对于 sEnglish来说， Java 中的各个类都支持得非常好，肯定能够正确显示。但对于 sChinese 和 s 来说，虽然 Java Soft 声明 Java 的基本类已经考虑到对多国字符的支持（默认 UNICODE 编码），但是如果操作系统的默认编码不是 UNICODE ，而是国标码等。从 Java 源代码到得到正确的结果，要经过 “Java 源代码-> Java 字节码-> ;虚拟机->操作系统->显示设备”的过程。在上述过程中的每一步骤，我们都必须正确地处理汉字的编码，才能够使最终的显示结果正确。 “ Java 源代码-> Java 字节码”，标准的 Java 编译器 javac 使用的字符集是系统默认的字符集，比如在中文 Windows 操作系统上就是 GBK ,而在 Linux 操作系统上就是ISO-8859-1，所以大家会发现在 Linux 操作系统上编译的类中源文件中的中文字符都出了问题，解决的办法就是在编译的时候添加 encoding 参数，这样才能够与平台无关。用法是 javac –encoding GBK。 “ Java 字节码->虚拟机->操作系统”， Java 运行环境 （JRE） 分英文版和国际版，但只有国际版才支持非英文字符。 Java 开发工具包 （JDK） 肯定支持多国字符，但并非所有的计算机用户都安装了 JDK 。很多操作系统及应用软件为了能够更好的支持 Java ，都内嵌了 JRE 的国际版本，为自己支持多国字符提供了方便。 “操作系统->显示设备”，对于汉字来说，操作系统必须支持并能够显示它。英文操作系统如果不搭配特殊的应用软件的话，是肯定不能够显示中文的。 还有一个问题，就是在 Java 编程过程中，对中文字符进行正确的编码转换。例如，向网页输出中文字符串的时候，不论你是用 out.println(string); // string 是含中文的字符串 还是用 ，都必须作 UNICODE 到 GBK 的转换，或者手动，或者自动。在 JSP 1.0中，可以定义输出字符集，从而实现内码的自动转换。用法是
但是在一些 JSP 版本中并没有提供对输出字符集的支持，（例如 JSP 0.92），这就需要手动编码输出了，方法非常多。最常用的方法是 String s1 = request.getParameter(“keyword”); String s2 = new String(s1.getBytes(“ISO-8859-1”),”GBK”); getBytes 方法用于将中文字符以“ISO-8859-1”编码方式转化成字节数组，而“GBK” 是目标编码方式。我们从以ISO-8859-1方式编码的数据库中读出中文字符串 s1 ，经过上述转换过程，在支持 GBK 字符集的操作系统和应用软件中就能够正确显示中文字符串 s2 。 Java 中文问题的表层分析及处理 背景 开发环境
JDK1.15
Vcafe2.0
JPadPro 服务器端
NT IIS
Sybase System
Jconnect（JDBC） 客户端
IE5.0
Pwin98
.CLASS 文件存放在服务器端，由客户端的浏览器运行 APPLET ， APPLET 只起调入 FRAME 类等主程序的作用。界面包括 Textfield ，TextArea，List，Choice 等。 I. 取中文 用 JDBC 执行 SELECT 语句从服务器端读取数据（中文）后，将数据用 APPEND 方法加到 TextArea（TA） ，不能正确显示。但加到 List 中时，大部分汉字却可正确显示。 将数据按“ISO-8859-1” 编码方式转化为字节数组，再按系统缺省编码方式 （Default Character Encoding） 转化为 STRING ，即可在 TA 和 List 中正确显示。 程序段如下： dbstr2 = results.getString(1); //After reading the result from DB server，converting it to string. dbbyte1 = dbstr2.getBytes(“iso-8859-1”); dbstr1 = new String(dbbyte1); 在转换字符串时不采用系统默认编码方式，而直接采用“ GBK” 或者 “GB2312” ,在 A 和 B 两种情况下，从数据库取数据都没有问题。 II. 写中文到数据库 处理方式与“取中文”相逆，先将 SQL 语句按系统缺省编码方式转化为字节数组，再按“ISO-8859-1”编码方式转化为 STRING ，最后送去执行，则中文信息可正确写入数据库。 程序段如下： sqlstmt = tf_input.getText(); //Before sending statement to DB server，converting it to sql statement. dbbyte1 = sqlstmt.getBytes(); sqlstmt = newString(dbbyte1,”iso-8859-1”); _stmt = _con.createStatement(); _stmt.executeUpdate(sqlstmt); …… 问题：如果客户机上存在 CLASSPATH 指向 JDK 的 CLASSES.ZIP 时（称为 A 情况），上述程序代码可正确执行。但是如果客户机只有浏览器，而没有 JDK 和 CLASSPATH 时（称为 B 情况），则汉字无法正确转换。 我们的分析： 1.经过测试，在 A 情况下，程序运行时系统的缺省编码方式为 GBK 或者 GB2312 。在 B 情况下，程序启动时浏览器的 JAVA 控制台中出现如下错误信息： Can't find resource for sun.awt.windows.awtLocalization_zh_CN 然后系统的缺省编码方式为“8859-1”。 2.如果在转换字符串时不采用系统缺省编码方式，而是直接采用 “GBK” 或“GB2312”，则在 A 情况下程序仍然可正常运行，在 B 情况下，系统出现错误： UnsupportedEncodingException。 3.在客户机上，把 JDK 的 CLASSES.ZIP 解压后，放在另一个目录中， CLASSPATH 只包含该目录。然后一边逐步删除该目录中的 .CLASS 文件，另一边运行测试程序，最后发现在一千多个 CLASS 文件中，只有一个是必不可少的，该文件是： sun.io.CharToByteDoubleByte.class。 将该文件拷到服务器端和其它的类放在一起，并在程序的开头 IMPORT 它，在 B 情况下程序仍然无法正常运行。 4.在 A 情况下，如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ，则程序运行时测得默认编码方式为“8859-1”，否则为 “GBK” 或 “GB2312” 。 如果 JDK 的版本为1.2以上的话，在 B 情况下遇到的问题得到了很好的解决，测试的步骤同上，有兴趣的读者可以尝试一下。 Java 中文问题的根源分析及解决 在简体中文 MS Windows 98 + JDK 1.3 下，可以用 System.getProperties() 得到 Java 运行环境的一些基本属性，类 PoorChinese 可以帮助我们得到这些属性。 类 PoorChinese 的源代码： public class PoorChinese { public static void main(String[] args) { System.getProperties().list(System.out); } } 执行 java PoorChinese 后，我们会得到: 系统变量 file.encoding 的值为 GBK ，user.language 的值为 zh ， user.region 的值为 CN ，这些系统变量的值决定了系统默认的编码方式是 GBK 。 在上述系统中，下面的代码将 GB2312 文件转换成 Big5 文件，它们能够帮助我们理解 Java 中汉字编码的转化:
import java.io.*; import java.util.*;
public class gb2big5 {
static int iCharNum=0;
public static void main(String[] args) { System.out.println("Input GB2312 file, output Big5 file."); if (args.length!=2) { System.err.println("Usage: jview gb2big5 gbfile big5file"); System.exit(1); } String inputString = readInput(args[0]); writeOutput(inputString,args[1]); System.out.println("Number of Characters in file: "+iCharNum+"."); }
static void writeOutput(String str, String strOutFile) { try { FileOutputStream fos = new FileOutputStream(strOutFile); Writer out = new OutputStreamWriter(fos, "Big5"); out.write(str); out.close(); } catch (IOException e) { e.printStackTrace(); e.printStackTrace(); } }
static String readInput(String strInFile) { StringBuffer buffer = new StringBuffer(); try { FileInputStream fis = new FileInputStream(strInFile); InputStreamReader isr = new InputStreamReader(fis, "GB2312"); Reader in = new BufferedReader(isr); int ch; while ((ch = in.read()) > -1) { iCharNum += 1; buffer.append((char)ch); } in.close(); return buffer.toString(); } catch (IOException e) { e.printStackTrace(); return null; } } }
编码转化的过程如下： ByteToCharGB2312 CharToByteBig5 GB2312------------------>Unicode------------->Big5 执行 java gb2big5 gb.txt big5.txt ，如果 gb.txt 的内容是“今天星期三”，则得到的文件 big5.txt 中的字符能够正确显示；而如果 gb.txt 的内容是“情人节快乐”，则得到的文件 big5.txt 中对应于“节”和“乐”的字符都是符号“？”（0x3F），可见 sun.io.ByteToCharGB2312 和 sun.io.CharToByteBig5 这两个基本类并没有编好。 正如上例一样， Java 的基本类也可能存在问题。由于国际化的工作并不是在国内完成的，所以在这些基本类发布之前，没有经过严格的测试，所以对中文字符的支持并不像 Java Soft 所声称的那样完美。前不久，我的一位技术上的朋友发信给我说，他终于找到了 Java Servlet 中文问题的根源。两周以来，他一直为 Java Servlet 的中文问题所困扰，因为每面对一个含有中文字符的字符串都必须进行强制转换才能够得到正确的结果（这好象是大家公认的唯一的解决办法）。后来，他确实不想如此继续安分下去了，因为这样的事情确实不应该是高级程序员所要做的工作，他就找出 Servlet 解码的源代码进行分析，因为他怀疑问题就出在解码这部分。经过四个小时的奋斗，他终于找到了问题的根源所在。原来他的怀疑是正确的， Servlet 的解码部分完全没有考虑双字节，直接把 %XX 当作一个字符。（原来 Java Soft 也会犯这幺低级的错误！） 如果你对这个问题有兴趣或者遇到了同样的烦恼的话，你可以按照他的步骤对 Servlet.jar 进行修改： 找到源代码 HttpUtils 中的 static private String parseName ，在返回前将 sb（StringBuffer） 复制成 byte bs[] ，然后 return new String(bs,”GB2312”)。作上述修改后就需要自己解码了： HashTable form=HttpUtils .parseQueryString(request.getQueryString())或者 form=HttpUtils.parsePostData(……) 千万别忘了编译后放到 Servlet.jar 里面。 五、 关于 Java 中文问题的总结 Java 编程语言成长于网络世界，这就要求 Java 对多国字符有很好的支持。 Java 编程语言适应了计算的网络化的需求，为它能够在网络世界迅速成长奠定了坚实的基础。 Java 的缔造者 （Java Soft） 已经考虑到 Java 编程语言对多国字符的支持，只是现在的解决方案有很多缺陷在里面，需要我们付诸一些补偿性的措施。而世界标准化组织也在努力把人类所有的文字统一在一种编码之中，其中一种方案是 ISO10646 ，它用四个字节来表示一个字符。当然，在这种方案未被采用之前，还是希望 Java Soft 能够严格地测试它的产品，为用户带来更多的方便。 附一个用于从数据库和网络中取出中文乱码的处理函数，入参是有问题的字符串，出参是问题已经解决了的字符串。 String parseChinese(String in) { String s = null; byte temp []; if (in == null) { System.out.println("Warn:Chinese null founded!"); return new String(""); } try { temp=in.getBytes("iso-8859-1"); temp=in.getBytes("iso-8859-1"); s = new String(temp); } { System.out.println("Warn:Chinese null founded!"); return new String(""); } try { temp=in.getBytes("iso-8859-1"); s = new String(temp); } catch(UnsupportedEncodingException e) { System.out.println (e.toString()); } return s; }
我再说两句自己的观点：
我觉得先在这个时代技术发展非常快，我们不可能对各个方面都去自己一点一点的分析，然后去寻找解决方案（除非不得已），因为我们毕竟不是做理论研究的，我们是作应用开发的。虽然，我们知其所以然会更好，也许我们的时间不允许，如果说，让你做一项开发，你中间遇到了一些问题，网上已经有很多现成的解决方法，我们何必要自己在耗时费力的再去分析，去寻求答案呢。如果是这样的话，也许等我们找到答案，这个项目早就应该结束了。我觉得，等我们时间充足时，再知其所以然也不迟！
谢谢你的指点；
不过有两点我也要说明一下。
一，BBS是大家在一起讨论的地方，我觉得就是应该有更多的自己的想法和心得；
二，我们不要为了回答问题而回答问题。回答别人的问题不是到某个地方去抄一段放在那里就可以了，应该有自己的某些观点；因为这些资料到网上谁都能找上一大堆，如果没有自己的观点是很难让人信服这些资料的，因为感觉连你自己都没去理解这些东西，别人为什么要相信呢？
看到你给我的留言，我觉得你是一位有思想，有进取心的朋友。看到你的生肖像，你是属鸡的吧？我觉得你应该比我小很多。你说的话很是令我惭愧，实际上，我也是刚做jsp不很久，从你在这儿的留言还有你在别处的回复，我觉得你的水平挺高，以后还要多多向你请教。我不会说话，言语不当之处，请见谅，sorry!另外，针对你说的，我说几句：
你所说的观点是什么？是指自己的开发心得吗？
我觉得自己的水平太差，语言表达能力也没人家的好，
所以，我想把更好的让大家来讨论，学习。
你觉得这些资料很难理解吗？
如果是这样，你也说了，网上能找到一大堆，
你可以查查，把你觉得难理解的地方给大家
讲出来，不是很好？
你如果不相信这些资料，那你为什么不去
测试一下呢？
无论测试结果如何，把你的测试过程和结果
留给大家，我觉得这样会更有利于大家的学习。
谢谢！
对不起，我这段时间一直是心情不好。我是不是显得很幼稚，其实我已经工作4年多了（都怪我不求上进，到现在还跟刚毕业时水平差不多），前两年做的是c、c++的东西；中间做的是电脑买卖（落难）；java只做了两年不到。刚开始的时候我也喜欢到bbs上去炫耀自己的看到过的东东，因为觉得这样可以给同行们带来帮助，但等做完几个项目（惭愧，到现在才做三个项目）后才发现，实际遇到的问题并非所有都如资料所说的那样解决，并不是说他们错了，只是是否真的实用，比如这个乱码问题（我们的项目都日本人的，这个问题更严重），我们当时碰到了，也去找过资料，但大多数都是如你所说的那样，‘编码’；我们也试过了，确实可行，但它确实不实用呀。其实真正的解决办法是修改（系统、应用程序、数据库）服务器的环境参数设置，但很少有人注意到这一点。比如还有，用户从本地假冒一个http的请求，如何来阻止呢（比如咱们现在用的bbs,地址栏不是有http://www.csdn.net/expert/index.asp?room=28字样吗？我们现在可以随便把28改为其它数字如27，那我们怎么知道这27是通过手工输入的还是正常途径得到的呢？显然用session实现是不现实的），象这些如果不从实际项目中摸索是很难知道的。
if(request.getHeader("referer")==null){
//假的；
}当然这只是初级的，或者说它是有问题的；request.getHeader("referer")得到的是请求该程序的url地址；但它是有条件的，自己慢慢研究吧；怎么解决也慢慢研究吧