剖析JSP和Servlet对中文的处理（2） (1)

奇怪了！为什么把设成GB2312和ISO8859-1是一个样的，都能正确显示？因为表4、表5中的第2步和第5步互逆，是相互“抵消”的。只不过当指定为ISO8859-1时，要增加第8步操作，殊为不便。
　　通过表6再看看不指定时的情况。
　　表6 未指定Jsp－charset时的变化过程
　　　
　　从Servlet源文件到浏览器
　　前提：Servlet源文件为Java文件，格式是GB2312，且含有“中文”这两个汉字。
　　如果＝GB2312，则=GB2312（见表7）。
　　表7 Compile-Charset=Servlet-charset=GB2312时的变化过程
　　　
　　如果＝ISO8859-1，则=ISO8859-1（见表8）。
　　表8　Compile-charset=Servlet-charset=ISO8859-1时的变化过程
　　　
　　注意：如果不指定Compile-charset或Servlet-charset，其默认值均为ISO8859-1。
　　
　　当Compile-charset=Servlet-charset时，第2步和第4步能互逆，“抵消”，显示结果均能正确。读者可试着写一下Compile-charset≠Servlet-charset时的情况，肯定是不正确的。
　　
　　当输出对象是数据库时
　　
　　输出到数据库时，原理与输出到浏览器也是一样的。我们只以Servlet为例，JSP的情况请读者自行推导（见表9）。
　　假设有一个Servlet，它接收来自客户端（IE，简体中文）的汉字字符串，然后把它写入到字符集为ISO8859-1的数据库中，然后再从数据库中取出这个字符串，显示到客户端。
　　前提：客户端的字符集是GB2312，数据库的字符集是ISO8859-1。解释一下，表中第4、第5步和第15、第16步表示要由编程者来作转换。第4、5两步其实就是一句话：“new String(source.getBytes("ISO8859-1"), DBCharset)”。第15、16两步也是一句话：“new String(source.getBytes(DBCharset), ClientCharset)”。亲爱的读者，你在这样编写代码时，是否想过为什么要这么做呢？
　　字节流
　　　
　　　
　　　
　　结论及结束语
　　行文至此，已可告一段落了。以下给出一个结论，作为结尾。
　　1.在JSP文件中，要指定contentType。其中，charset的值要与客户端浏览器所用的字符集一样；对于其中的字符串常量，不需做任何处理；对于字符串变量，要求能根据ContentType中指定的字符集还原成客户端能识别的字节流，通俗地说，就是“字符串变量是基于字符集的”。
　　2.在Servlet中，必须用HttpServletResponse. setContentType()设置charset，且设置成与客户端字符集一致；对于其中的字符串常量，需要在Javac编译时指定encoding，这个encoding必须与编写源文件平台的字符集一样。一般说来都是GB2312或GBK；对于字符串变量，与JSP一样。必须“是基于字符集的”。
　　
　　终点又回到了起点，对于编程者而言，几乎是什么影响都没有。因为我们早就被告之要这么做了。
　　案例分析
　　案例：某用户在英文Windows上，安装了外挂的中文平台，操作系统的字符集是“西欧字符”，对应着ISO8859-1字符集，外挂的中文平台是基于Big5码的。当操作者在浏览器（默认编码是ISO8859-1）中输入汉字时，这个汉字用Big5编码（在页面上无法正确显示）。然后，浏览器把数据提交给服务器端。