(J2ee应用中文乱码问题解决方案.docVIP

J2ee国际化应用utf-8解决方案笔记 到现在为止, 陆续接触了几个项目, 这几次都使用了不同的编码, 感觉在国际化时, 中文问题上屡屡碰到问题, 每次都需要费点时间, 现在抽点时间总结一下, 也为同事以及以后的项目提供一些参考。(utf-8是unicode的一种编码表现形式, 他能很好的兼容单字节编码格式) 项目名称 前台jsp编码, 显示 Class类 数据库 Webuniverse UTF-8, GB2312, GBK混合使用 Unicode ISO-8859-1 BookManagement GB2312 Unicode IOS-8859-1 Workflow UTF-8 Unicode UTF-8 字符集 首先简要介绍一下字符集的概念, 这部分是从网上整理而来: 单字节字符集 ASCII码，它以8bit字节为单位存储，0-31及127为控制符，32-126为可见字符， 128-255的ASCII码则没有定义。 为美国所使用。 ISO-8859-1是ASCII扩展到0-255的范围形成的。为西欧所扩展。 双字节字符集 GB2312第一个字节大于127，则使用两个字节来组成一个汉字。若小于127, 仍用一个字节来表示ASCII码定义的字符。 GBK 保持与GB2312兼容, 并含繁体中文字，日文字符和朝鲜字符。GBK是现阶段Windows及其他一些中文操作系统的缺省字符集。 BIG5(台湾) SJIS(日本) 这两种编码与GB2312类似, 但扩展ASCII码的那部分编码方式是不一样的。 多字节字符集 Unicode 定义了31位的字符集, 现在基本上只使用了16位子集。U+0000 到 U+007F 与 ASCII 是一致的， U+0000 到 U+00FF 与 ISO 8859-1也是一致的。但每个字符都用16bit来保存。 UTF-8是Unicode的一种表达方式, 它即兼容了单字节字符集, 又以一种组码方式实现了所有的字符集。另外单字节字符不可能成为多字节字符的一部分。 中文字符乱码的原因 要注意编码的地方 下面是我实践加理解整理出来的东西, 也可能会有严重错误, 希望大家不啻指教。 jsp页面 JSP编码格式 保存jsp页面的时候, 我们可以指定各种格式, 比如GBK, utf8等等。 读取和编译时, %@ page contentType=text/html;charset=UTF-8% 用来指定容器是以什么格式读取这个jsp页面的。不指定的话, 容器会获取操作系统的file.encoding, 比如中文操作系统为GBK, 存成Unicode格式。然后容器会把它编译成Unicode编码的class类。 页面显示格式 head meta http-equiv=Content-Type content=text/html; charset=gb2312 /head 它表示强制浏览器编码设为gb2312。这个设定对网页交互很有关系, 你设定了什么编码, 之后你提交的请求就会按照这种编码格式来编码发送。比如, post一个用户名: name=松然 utf-8下会发送: name=%E6%9D%BE%E7%84%B6 GB2312下发送: name=%CB%C9%C8%BB Tomcat默认总是使用ISO-8859-1, 这就是说你用GBK编码的中文传到tomcat中, 在servlet里默认输出System.out.println()总会得到乱码。 容器参数接收 如上面所提的, 参数的传递方式跟页面显示编码的设定有关。那服务器端又是如何处理参数的呢? 若不指定容器接受参数时采用的编码格式，则WEB容器会默认采用ISO-8859-1编码格式来接受传入的值并在JVM中转化为UNICODE格式的保存在WEB容器的内存中。 容器参数输出 若不指定容器接受参数时采用的编码格式，则WEB容器会默认采用ISO-8859-1编码格式来输出内容到客户端浏览器上。 编码解决方式 乱码的根本原因就是前后编码方式不一致, 所以乱码问题总共两种解决方式,: 不同编码交接处进行转码 统一使用同一种编码 下面会着重讨论这两种方式的实际应用。 不同编码方式 由于现下流行的一些服务器, 或数据库基本上是西方国家生产的, 所以他们默认支持ISO-8859-1就不显得奇怪了, 甚至有些还不支持UTF-8, 比如Mysql4.0 以前版本就支持不好, Mysql4.1在linux下也配置UTF-8我现在的解决方式是需要重新编译源文件。Tomcat, Mysql, SQLServer等程序默认都是ISO-8859-1。所以我们以后开发其他项目时需要注意一下。 这种方式下, 只要搞清楚