java中文问题 faint!就是你的问题，看你给的分太少了，帮你加点，你竟然还//kick 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 用Stirng strOut = new String(strIn.getBytes(("ISO8859_1"),"GBK"); 试试。 用Stirng strOut = new String(strIn.getBytes(("ISO8859_1"),"GBK");也不行 直接用Stirng strOut=strIn试试! 你要确认strIn的编码,有许多种可能:utf-8,utf-16,gb2312,iso-8859-1等等.如果确定了,就用String strOut = new String(strIn.getBytes("strIN的编码"),"你要输出字符串的编码"); 直接用Stirng strOut=strIn 这个方法我试过，在JSP上可以显示出中文，可在Applet上就是不认。String strOut = new String(strIn.getBytes("strIN的编码"),"你要输出字符串的编码") ； 这种方法 用gb2312,iso-8859-1这两种码都试过，不行的。这是在往sql 表里插入和取出出现的问题。 你strIn是从哪取来的啊?!如果是数据库看看数据库采用什么编码!如果是HTML,JSP传过来的,用Stirng strOut = new String(strIn.getBytes(("ISO8859_1"),"GBK"); 应该可以解决的,当然你的WEBSERVER要使用ISO_88591编码! 如果是从SQL SERVER取的记录值呢？ 运行jsp后产生的页面,用查看源码的方式核对一下,是否一定是中文?如果是,说明数据库中是中文如果不是,说明数据库中根本就不是中文另外一种方法,直接用System.out.println(strIn) 来打印出来,看看是否可行 String strOut = new String(strIn.getBytes("strIN的编码"),"你要输出字符串的编码"); 放在Applet中执行 WEBSERVER 是tomcat4.01,是ISO8859_1编码吗？strIn是从Applet的TextField取来的，然后往数据库插入的。 你的系统平台是中文win2000,数据库是中文Sql server 2000,数据库支持中文! 在jsp下可以显示中文的，可在applet下就显示不出来，而且往库里插入的时候不行，用profiler 跟踪是，就是显示乱码。 java的中文问题，和编译平台，运行平台，和Jdbc是否自动转换，数据库中如何存储都有关系。如果jsp的话，还有一个web server是否支持的问题。 我贴，不知道有没有一点启发？■Solaris下Servlet编程的中文问题及解决办法在使用Java开发Internet上的一个应用系统时，发现在Windows下调试完全正常的Servlet，上传到Solaris 服 务器上，运行却出现故障——返回的网页不能显示中文，应为中文的信息全为乱码；用中文信息做关键 字，不能正确检索数据库。后来采用加入检查代码等方法探知故障原因如下：显示乱码主要是因为通过类 HttpServletResponse提供的方法setContentType 无法改变返回给客户的数据的 编码方式，正确的编码方式应为GB2312或者GBK，而事实上为缺省的ISO8859-1。无法检索中文信息则是因 为，客户提交的中文信息经浏览器编码到达服务器后，Servlet无法将其正确解码。举例说明显示乱码解决方法Servlet 一般通常做法如下：public class ZldTestServlet extends HttpServlet { public void doGet (HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{//在使用 Writer向浏览器返回数据前，设置 content-type header ，在这里设置相应的字符集gb2312 response.setContentType("text/html;charset=gb2312"); PrintWriter out = response.getWriter(); //*// 正式返回数据out.println("〈html〉〈head〉〈title〉Servlet test〈/title〉〈/head〉" );out.println("这是一个测试页！"); out.println("〈/body〉〈/html〉");out.close(); }...} 解决页面显示乱码问题，需将*处代码换成如下内容：PrintWriter out = new PrintWriter(new OutputStreamWriter(response.getOutputStream(),"gb2312")); Solaris中文信息检索问题的解决浏览器利用表单向服务器提交信息时，一般采用x-www-form-urlencoded 的MIME格式对数据进行编码。如 果使用get方法，参数名称和参数值经编码后附加在URL后，在Java中称作查询串（query string）。在Servlet程序中，如果采用ServletRequest的方法getParameter取得参数值，在Solaris环境下，对汉字却不能正 确解码。因而无法正确检索数据库。在Java 1.2的包——java.net中提供了URLEncode和URLDecode类。类URLEncode提供了按x-www-form- urlencoded格式对给定串进行转换的方法。类URLEncode则提供了逆方法。在编写某网上114查询的Servlet时，采用先取得查询串，再利用类URLDecode解码，再从解码后的串中取得 参数，很好地解决了Solrais环境下，中文信息检索的问题。源代码就不在这里给出了，如果需要请和笔者联 系。 hanson_yi()这位老兄说的好像是JSP页不能显示中文的解决方法。可是她在applet上出现乱码，而在jsp上象这样处理一下不出现乱码了。applet和库之间使用远程调用连接的。 看一看chinacode.org上的一篇贴字:中文显示原理研究预备知识： 1.字节和unicode Java内核是unicode的，就连class文件也是，但是很多媒体，包括文件/流的保存方式 是使用字节流的。 因此Java要对这些字节流经行转化。char是unicode的，而byte是字节. Java中byte/char互转的函数在sun.io的包中间有。其中ByteToCharConverter类是中调度， 可以用来告诉你，你用的Convertor。其中两个很常用的静态函数是 public static ByteToCharConverter getDefault() ; public static ByteToCharConverter getConverter(String encoding); 如果你不指定converter，则系统会自动使用当前的Encoding,GB平台上用GBK,EN平台上用 8859_1 我们来就一个简单的例子： "你"的gb码是：0xC4E3 ,unicode是0x4F60 你用: --encoding="gb2312"; --byte b[]={(byte)'\u00c4',(byte)'\u00E3'}; --convertor=ByteToCharConverter.getConverter(encoding); --char [] c=converter.convertAll(b); --for(int i=0;i0xC4,0x00E3->0xE3，因此0xC4,0xE3被放进了 --文件 ---- 1.对于JSP正文的解释： --Tomcat首先看一下你的叶面中有没有" 你好 http://localhost/test/test.jsp?value=你 结果:你好你 但这种方法局限性较大，比如对上传的文章分段，这样的做法是死定的，最好的 解决方案是用这种方案： 你好 必读好文,但解决方案不敢恭维 -------------------------------------------------------------------------------- 1.网页传参数不提倡用get方法,而且用户可以调整是否用utf-8发送 2.建议jsp中最好不要用,实际上加不加这句都有实现中文正常显示的方案,我认为不加方便些,至少不用写这些代码,如下的配置我认为可以使中文正常显示: a.所有的javabean用iso8859-1编译 b.jsp文件中不要写以上charset=gb2312的语句(写了反而错) 在tomcat情况下注意以上2点就行---了,等等,对于其他有可能不行的jsp服务器,加上以下 c.服务器上的*作系统语言设为英文(像没有装类似bluepoint中文系统的linux一般本来就是英文) 就行---了 谁要是还不对,请报告.... Re：必读好文,但解决方案不敢恭维 -------------------------------------------------------------------------------- Tomcat的参数问题无论是GET或是POST方式都是用8859_1编码的。这个可以看Tomcat Servlet实现的源代码: a) 对于POST方法 javax.servlet.http.HttpUtils的parsePostData方法： (对于POST的Form数据) String postedBody = new String(postedBytes, 0, len, "8859_1");)这里是没有问题的因为中文都会用%来说明。但是parseName这个函数，却没有把是中文的东西整合起来，他只是简单的拼凑，因此可以认定他是使用8859_1的编码规则 sb.append((char) Integer.parseInt(s.substring(i+1, i+3), 16)); ---- i += 2; -- b) 对于GET方法 org.apache.tomcat.service.http.HttpRequestAdapter -- line=new String(buf, 0, count, Constants.CharacterEncoding.Default); ----Constants.CharacterEncoding.Default=8859_1 这段代码不好跟踪，千万不要被一些假象迷惑住。HttpRequestAdapter是从RequestImpl中派生的。但是，实际上用8080端口的Server并没有直接用到RequestImpl，而是用了HttpRequestAdapter来获得queryString 对于加不加encoding，我保留我的意见，因为如果要解决上传文件分页问题，必须要用他来编码。而且编码能保证在一些Beans当中的传递性。 看来我要在这里说明一下了 -------------------------------------------------------------------------------- Tomcat仅仅是一个对jsp1.1,servlet2.2的一个标准的实现,我们不应该要求这个免费软件在细致末节上和性能上都面面俱到,它主要考虑的英文用户,这也是为什么不作特殊转换我们的汉字用url方法传递有问题的原因,我们大部分浏览器ie其高级设置中始终以utf-8发送url的选项缺省是选上的,如果说这是tomcat的bug也是可以的,另外Tomcat不管当前的*作系统是什么语言,好像都按iso8859去编译jsp,我觉得也有点欠妥,但是不管怎么说,新标准的实现和热门的软件在语言的支持方面永远都是先考虑英文 我的方案什么说要好一些呢 1.还是那句话,英文国家的软件永远都是先考虑英文,java虚拟机的规范中要求虚拟机内部必须实现iso8859,unicode,UTF-8三种,其他的不作要求,我们用的jdk中的虚拟机就是这样,嵌入式的就更不用说了,也就是说其他的ENCODE都很可能不是java虚拟机内部直接支持的,我们的中文自然也不在其列,需要外部的包支持转换,sun jdk应该在i18n.jar中,用iso8859速度最快,不需要其它调用和交换什么的,更没有读包的io*作 2.至少少写了代码,没有额外*作,简洁的风格谁不喜欢 3.所写的jsp页面国际性化好,我才写了一个jsp+javabeans的聊天室软件(没有用到servlet,jsp真的确实很好),同样的程序美国人用他们的浏览器进入就是英文界面,中文进入就是中文界面,如果加上charset=gb2312至少很麻烦 4.限定了gb2312,如果用户要用GBK,怎么办,不加更好,不管什么的字符集,只要我当前浏览器设定的是,我就能显示出来 总结:无论从速度上,开发效率上,和可扩展性上考虑,我的方案都比你的好,另外,我找不到你的方案比我的好的地方. [已被 webmaster 编辑过, 在 2001-01-21 11:23]2001-01-21 11:20 IP: 查看 javafan初级会员注册时间: 2001年4月发帖数量: 3 如下的配置我认为可以使中文正常显示: a.所有的javabean用iso8859-1编译 b.jsp文件中不要写以上charset=gb2312的语句(写了反而错) 我用的是tomcat,根据上面配置，基本显示正常。 但是从数据库中取出的中文数据不能正常显示。 我用的数据库是sybase的。 而我用iso8859-1编译javabean,在jsp文件中写上charset=gb2312. 在javabean中所有String都用native2unicode编码, 在jsp中都用unicode2native解码,可以在自己机子上正常显示. 我用的是中文win2k. 不知道在其他平台上能否正常显示??? 问题可能出在任何一个环节：Sql Server<--->Jdbc<--->javabean<--->..network....<--->applet在每一个环节测试编码方式iso-8859-1/GBK/gb2312/utf8...，应该能发现问题在那个环节。 在jsp文件的最头加上<%@ page contentType="text/html;charset=gb2312" %> 我说明一下，在JSP中可以显示中文，在Applet中显示乱码，Applet和数据库之间是用远程调用连接的 byte bs[];String ss = new String(bs); 中文问题分析 java的javac和java这两个命令在编译和运行java程序时是会去检测系统字符集的,然后会按照系统字符集来对字符进行转换。例如：当我们在西文系统中运行javac 命令时，它所选用的encode的字符集就是ISO8859_1，也就是说，它在编译的时候会将所有的ISO8859_1的字符串转换成为Unicode，此时如果程序中有其他字符集的字符串，譬如GBK的中文字串，则不做任何转换，仍然按照GBK的字符读入，而当它在西文平台下用java运行时，又会将Unicode转换成ISO8859_1输出，并将GBK的字符正常输出。因此，在西文环境下，中文可以正常的输出。如果在中文系统中运行javac 命令，则所有的GBK字符串会转换成Unicode，而所有的ISO8859_1的字符串会保留，同样在输出的时候也将Unicode转换成GBK字符集，因此也可以正常显示。什么时候会出现中文乱码问题呢？1： 在JDBC Driver里，有些Driver会对将插入数据库的和从数据库中读出的中文自动地转换成Unicode，而有些不会，如果Driver做过转换而系统又再做一次，就会出现问题，也就是常见的??，这时，我们需要的就是在不同的平台下根据不同的情况去将数据库做的不需要的转换抵消。举一个简单例子：系统是西文平台，数据库的Driver做过GBK到Unicode的转换，这时候，我们程序中的中文字串在javac后仍然是GBK码，而从数据库中读进的中文已经做过转换，也就是变成了Unicode码，当我们用java去运行时就会将中文的Unicode转换成ISO8859_1,自然要出错。这时，我们就需要自己将从数据库中读出的数据做一个Unicode到GBK的转换，因此就可以正常输出了。2：在我们通过html页面向jsp或servlet发送字符串的时候同样会出现类似的问题。规律是：如果系统是西文语言环境，那么我们输入的中文可以正常输出。如果系统是中文语言环境，那么中文被做过处理。3：与上述两种情况不同的是.jsp页面中的中文字符问题，jsp和servlet最大的不同点在于jsp是只支持8位字符集的，这使得在没有任何设置的情况下jsp中直接写入的中文是不能正常显示的。必须要设置系统的编译环境，并且在显示中文的页面中加入contentType的设置才可以。由于中文情况复杂，所以在我们进行业务操作的时候一个中文信息很可能会被系统给转换很多次，从而导致信息失去应有的含义。所以我们在整个应用中遵守的原则是：不管我接受到的实际数据如何，我所输出的结果一定是正确的。例如：客户从一个页面中输入个人信息（中文）并且提交给下一个确认页面，然后再进行确认。这个过程经历了两次数据传输，当我们使用request.getParameter()获得前一页面的数据的时候，很有可能这个数据被系统转换过，但无论系统转换与否，我们都需要保证本页面的输出是正确的。 试试这个方法public String cnStr(String invar){ String rs = null; byte[] temp; if(invar =="") { System.out.println(""); return invar; } try { temp = invar.getBytes("ISO-8859-1"); rs = new String(temp); } catch(Exception e) { System.out.println(""); return invar; } return rs; } String originalStr="录入的字符串";byte[] tempStr=originalStr.getBytes("ISO8859_1");String newStr=new String(tempStr); 正则表达式匹配中文问题 jtextarea的替代品能定义颜色的 JAVA如何访问MYSQL的存储过程 JAVA调用水晶报表 一个delphi转java的简单枚举问题 一个应用程序里怎么样得到当前应用程序的路径？ 急！！！！！如何用 Java 从 Oracle 中读出所有的表名 是用Java 寻求大家的意见 两种初始化写法，哪种更好？ 现在的可视化的JAVA编译器那些用的比较多？ 有谁知道哪里有生成RTF文档的Java组件啊，小弟急用，分不够可在加 SOS..Java中矢量图绘制方法
也不行
如果确定了,就用String strOut = new String(strIn.getBytes("strIN的编码"),"你要输出字符串的编码");
如果是数据库看看数据库采用什么编码!
如果是HTML,JSP传过来的,用Stirng strOut = new String(strIn.getBytes(("ISO8859_1"),"GBK"); 应该可以解决的,当然你的WEBSERVER要使用ISO_88591编码!
如果是,说明数据库中是中文
如果不是,说明数据库中根本就不是中文
另外一种方法,直接用System.out.println(strIn) 来打印出来,看看是否可行
在使用Java开发Internet上的一个应用系统时，发现在Windows下调试完全正常的Servlet，上传到Solaris 服 务器上，运行却出现故障——返回的网页不能显示中文，应为中文的信息全为乱码；用中文信息做关键 字，不能正确检索数据库。后来采用加入检查代码等方法探知故障原因如下：显示乱码主要是因为通过类 HttpServletResponse提供的方法setContentType 无法改变返回给客户的数据的 编码方式，正确的编码方式应为GB2312或者GBK，而事实上为缺省的ISO8859-1。无法检索中文信息则是因 为，客户提交的中文信息经浏览器编码到达服务器后，Servlet无法将其正确解码。举例说明显示乱码解决方法
Servlet 一般通常做法如下：public class ZldTestServlet extends HttpServlet { public void doGet (HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{//在使用 Writer向浏览器返回数据前，设置 content-type header ，在这里设置相应的字符集gb2312 response.setContentType("text/html;charset=gb2312"); PrintWriter out = response.getWriter(); //*// 正式返回数据out.println("〈html〉〈head〉〈title〉Servlet test〈/title〉〈/head〉" );out.println("这是一个测试页！"); out.println("〈/body〉〈/html〉");out.close(); }...} 解决页面显示乱码问题，需将*处代码换成如下内容：PrintWriter out = new PrintWriter(new OutputStreamWriter(response.getOutputStream(),"gb2312")); Solaris中文信息检索问题的解决
浏览器利用表单向服务器提交信息时，一般采用x-www-form-urlencoded 的MIME格式对数据进行编码。如 果使用get方法，参数名称和参数值经编码后附加在URL后，在Java中称作查询串（query string）。在Servlet程序中，如果采用ServletRequest的方法getParameter取得参数值，在Solaris环境下，对汉字却不能正 确解码。因而无法正确检索数据库。在Java 1.2的包——java.net中提供了URLEncode和URLDecode类。类URLEncode提供了按x-www-form- urlencoded格式对给定串进行转换的方法。类URLEncode则提供了逆方法。在编写某网上114查询的Servlet时，采用先取得查询串，再利用类URLDecode解码，再从解码后的串中取得 参数，很好地解决了Solrais环境下，中文信息检索的问题。源代码就不在这里给出了，如果需要请和笔者联 系。
1.字节和unicode
Java内核是unicode的，就连class文件也是，但是很多媒体，包括文件/流的保存方式
是使用字节流的。 因此Java要对这些字节流经行转化。char是unicode的，而byte是字节.
Java中byte/char互转的函数在sun.io的包中间有。其中ByteToCharConverter类是中调度，
可以用来告诉你，你用的Convertor。其中两个很常用的静态函数是
public static ByteToCharConverter getDefault() ;
public static ByteToCharConverter getConverter(String encoding);
如果你不指定converter，则系统会自动使用当前的Encoding,GB平台上用GBK,EN平台上用
8859_1
我们来就一个简单的例子：
"你"的gb码是：0xC4E3 ,unicode是0x4F60
你用:
--encoding="gb2312";
--byte b[]={(byte)'\u00c4',(byte)'\u00E3'};
--convertor=ByteToCharConverter.getConverter(encoding);
--char [] c=converter.convertAll(b);
--for(int i=0;i0xC4,0x00E3->0xE3，因此0xC4,0xE3被放进了
--文件
----
1.对于JSP正文的解释：
--Tomcat首先看一下你的叶面中有没有"
你好
http://localhost/test/test.jsp?value=你 结果:你好你 但这种方法局限性较大，比如对上传的文章分段，这样的做法是死定的，最好的
解决方案是用这种方案：
你好 必读好文,但解决方案不敢恭维
-------------------------------------------------------------------------------- 1.网页传参数不提倡用get方法,而且用户可以调整是否用utf-8发送
2.建议jsp中最好不要用,实际上加不加这句都有实现中文正常显示的方案,我认为不加方便些,至少不用写这些代码,如下的配置我认为可以使中文正常显示:
a.所有的javabean用iso8859-1编译
b.jsp文件中不要写以上charset=gb2312的语句(写了反而错) 在tomcat情况下注意以上2点就行---了,等等,对于其他有可能不行的jsp服务器,加上以下
c.服务器上的*作系统语言设为英文(像没有装类似bluepoint中文系统的linux一般本来就是英文)
就行---了 谁要是还不对,请报告....
Re：必读好文,但解决方案不敢恭维
-------------------------------------------------------------------------------- Tomcat的参数问题无论是GET或是POST方式都是用8859_1编码的。这个可以看Tomcat Servlet实现的源代码:
a) 对于POST方法
javax.servlet.http.HttpUtils的parsePostData方法： (对于POST的Form数据)
String postedBody = new String(postedBytes, 0, len, "8859_1");)这里是没有问题的因为中文都会用%来说明。但是parseName这个函数，却没有把是中文的东西整合起来，他只是简单的拼凑，因此可以认定他是使用8859_1的编码规则
sb.append((char) Integer.parseInt(s.substring(i+1, i+3), 16));
---- i += 2;
--
b) 对于GET方法
org.apache.tomcat.service.http.HttpRequestAdapter
-- line=new String(buf, 0, count,
Constants.CharacterEncoding.Default);
----Constants.CharacterEncoding.Default=8859_1
这段代码不好跟踪，千万不要被一些假象迷惑住。HttpRequestAdapter是从RequestImpl中派生的。但是，实际上用8080端口的Server并没有直接用到RequestImpl，而是用了HttpRequestAdapter来获得queryString 对于加不加encoding，我保留我的意见，因为如果要解决上传文件分页问题，必须要用他来编码。而且编码能保证在一些Beans当中的传递性。 看来我要在这里说明一下了
-------------------------------------------------------------------------------- Tomcat仅仅是一个对jsp1.1,servlet2.2的一个标准的实现,我们不应该要求这个免费软件在细致末节上和性能上都面面俱到,它主要考虑的英文用户,这也是为什么不作特殊转换我们的汉字用url方法传递有问题的原因,我们大部分浏览器ie其高级设置中始终以utf-8发送url的选项缺省是选上的,如果说这是tomcat的bug也是可以的,另外Tomcat不管当前的*作系统是什么语言,好像都按iso8859去编译jsp,我觉得也有点欠妥,但是不管怎么说,新标准的实现和热门的软件在语言的支持方面永远都是先考虑英文 我的方案什么说要好一些呢
1.还是那句话,英文国家的软件永远都是先考虑英文,java虚拟机的规范中要求虚拟机内部必须实现iso8859,unicode,UTF-8三种,其他的不作要求,我们用的jdk中的虚拟机就是这样,嵌入式的就更不用说了,也就是说其他的ENCODE都很可能不是java虚拟机内部直接支持的,我们的中文自然也不在其列,需要外部的包支持转换,sun jdk应该在i18n.jar中,用iso8859速度最快,不需要其它调用和交换什么的,更没有读包的io*作
2.至少少写了代码,没有额外*作,简洁的风格谁不喜欢
3.所写的jsp页面国际性化好,我才写了一个jsp+javabeans的聊天室软件(没有用到servlet,jsp真的确实很好),同样的程序美国人用他们的浏览器进入就是英文界面,中文进入就是中文界面,如果加上charset=gb2312至少很麻烦
4.限定了gb2312,如果用户要用GBK,怎么办,不加更好,不管什么的字符集,只要我当前浏览器设定的是,我就能显示出来 总结:无论从速度上,开发效率上,和可扩展性上考虑,我的方案都比你的好,另外,我找不到你的方案比我的好的地方.
[已被 webmaster 编辑过, 在 2001-01-21 11:23]2001-01-21 11:20 IP: 查看 javafan
初级会员注册时间: 2001年4月
发帖数量: 3 如下的配置我认为可以使中文正常显示:
a.所有的javabean用iso8859-1编译
b.jsp文件中不要写以上charset=gb2312的语句(写了反而错) 我用的是tomcat,根据上面配置，基本显示正常。
但是从数据库中取出的中文数据不能正常显示。
我用的数据库是sybase的。 而我用iso8859-1编译javabean,在jsp文件中写上charset=gb2312.
在javabean中所有String都用native2unicode编码,
在jsp中都用unicode2native解码,可以在自己机子上正常显示.
我用的是中文win2k.
不知道在其他平台上能否正常显示???
Sql Server<--->Jdbc<--->javabean<--->..network....<--->applet
在每一个环节测试编码方式iso-8859-1/GBK/gb2312/utf8...，应该能
发现问题在那个环节。
<%@ page contentType="text/html;charset=gb2312" %>
String ss = new String(bs);
java的javac和java这两个命令在编译和运行java程序时是会去检测系统字符集的,然后会按照系统字符集来对字符进行转换。例如：当我们在西文系统中运行javac 命令时，它所选用的encode的字符集就是ISO8859_1，也就是说，它在编译的时候会将所有的ISO8859_1的字符串转换成为Unicode，此时如果程序中有其他字符集的字符串，譬如GBK的中文字串，则不做任何转换，仍然按照GBK的字符读入，而当它在西文平台下用java运行时，又会将Unicode转换成ISO8859_1输出，并将GBK的字符正常输出。因此，在西文环境下，中文可以正常的输出。如果在中文系统中运行javac 命令，则所有的GBK字符串会转换成Unicode，而所有的ISO8859_1的字符串会保留，同样在输出的时候也将Unicode转换成GBK字符集，因此也可以正常显示。什么时候会出现中文乱码问题呢？1： 在JDBC Driver里，有些Driver会对将插入数据库的和从数据库中读出的中文自动地转换成Unicode，而有些不会，如果Driver做过转换而系统又再做一次，就会出现问题，也就是常见的??，这时，我们需要的就是在不同的平台下根据不同的情况去将数据库做的不需要的转换抵消。举一个简单例子：系统是西文平台，数据库的Driver做过GBK到Unicode的转换，这时候，我们程序中的中文字串在javac后仍然是GBK码，而从数据库中读进的中文已经做过转换，也就是变成了Unicode码，当我们用java去运行时就会将中文的Unicode转换成ISO8859_1,自然要出错。这时，我们就需要自己将从数据库中读出的数据做一个Unicode到GBK的转换，因此就可以正常输出了。2：在我们通过html页面向jsp或servlet发送字符串的时候同样会出现类似的问题。规律是：如果系统是西文语言环境，那么我们输入的中文可以正常输出。如果系统是中文语言环境，那么中文被做过处理。3：与上述两种情况不同的是.jsp页面中的中文字符问题，jsp和servlet最大的不同点在于
jsp是只支持8位字符集的，这使得在没有任何设置的情况下jsp中直接写入的中文是不能正常显示的。必须要设置系统的编译环境，并且在显示中文的页面中加入contentType的设置才可以。由于中文情况复杂，所以在我们进行业务操作的时候一个中文信息很可能会被系统给转
换很多次，从而导致信息失去应有的含义。所以我们在整个应用中遵守的原则是：不
管我接受到的实际数据如何，我所输出的结果一定是正确的。例如：客户从一个页面中输入个人信息（中文）并且提交给下一个确认页面，然后再进行确认。这个过程经历了两次数据传输，当我们使用request.getParameter()获得前一页面的数据的时候，很有可能这个数据被系统转换过，但无论系统转换与否，我们都需要保证本页面的输出是正确的。
public String cnStr(String invar)
{
String rs = null;
byte[] temp;
if(invar =="")
{
System.out.println("");
return invar;
}
try
{
temp = invar.getBytes("ISO-8859-1");
rs = new String(temp);
}
catch(Exception e)
{
System.out.println("");
return invar;
}
return rs;
}
byte[] tempStr=originalStr.getBytes("ISO8859_1");
String newStr=new String(tempStr);