我与TOMCAT不得不说的二三事-- 新商务、新生活从无忧电子商务开始--www.51ec.org

您现在的位置：无忧电子商务网 >> 信息学院 >> 程序开发 >> js >> 正文

我与TOMCAT不得不说的二三事

作者：作者：未… 信息学院来源：网络收集点击数：更新时间：2006-8-27 我要参与讨论

集，如美国的扩展 ASCII码, 中国的 GB2312-80，日本的 JIS 等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为 SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了 LANG, Codepage 等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为 Locale 信息。处理的底层字符集变成了几乎包含了所有字形的 Unicode。

现在大部分具有国际化特征的软件核心字符处理都是以 Unicode 为基础的，在软件运行时根据当时的 Locale/Lang/Codepage 设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现 Unicode 和本地字符集的相互转换，甚或以 Unicode 为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。

Java 语言内部是用 Unicode 表示字符的，遵守 Unicode V2.0。Java 程序无论是从/往文件系统以字符流读/写文件，还是往 URL 连接写 HTML 信息，或从 URL 连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，Unicode 和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。

其实解决 JAVA 程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需要了解现有的汉字编码和编码转换。相信这样的东西大家都见过了

new String(request.getParameter("test").getBytes("iso-8859-1"),"GBK")

但这样的代码相信不是一个解决的办法，这样会增加程序的复杂度，写数据库，提交表单，URL中传中文参数，到处都是中文问题！作为一个连走路都要算计最短距离的懒人，当然不愿天天叨念着new String(request.getParameter("test").getBytes("iso-8859-1"),"GBK")，然汉战战兢兢的处理各种字符转换的问题，我跋山涉水，翻山越岭，终于找到了完美的解决方式，在TOMCAT中只需要简单的配置，引入2个文件就可以轻松搞定。

前提条件，每个页面使用

<%@ page contentType="text/html; charset=GBK" language="java" import="java.sql.*" errorPage="" %>

地球人都知道的东西。

步骤1：添加过滤器

在TOMCAT中找到这2个文件RequestDumperFilter.java，SetCharacterEncodingFilter.java，他们位于D:\Tomcat5.0.27\webapps\jsp-examples\WEB-INF\classes\filters，加到你的工程文件里去，编译他们。

步骤2：配置WEB.XML

在web.xml里加入这一段

……

<filter-name>Set Character Encoding</filter-name>

<filter-class>filters.SetCharacterEncodingFilter</filter-class>

<init-param>

<param-name>encoding</param-name>

<param-value>GBK</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>Set Character Encoding</filter-name>