J2EE开发中的java字符编码问题经验总结

在J2EE程序开发过程中，经常遇到字符的编码问题。这一问题困扰我已经很久了。今天有时间把相关的知识整理一下，一方面是个总结，另一方面也为朋友们提供一个帮助。

    JAVA中有char、byte、String这几个概念。char 指的是一个UNICODE字符，为16位的整数。byte 是字节，字符串在网络传输或存储前需要转换为byte数组。在从网络接收或从存储设备读取后需要将byte数组转换成String。String是字符串，可以看成是由char组成的数组。String 和 char 为内存形式，byte是网络传输或存储的序列化形式。

1、 Jsp页面的编码问题

一个标准的jsp页面的头标示一般如下：

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>

    在JSP标准的语法中，如果pageEncoding属性存在，那么JSP页面的字符编码方式就由pageEncoding决定，否则就由contentType属性中的charset决定，如果charset也不存在，JSP页面的字符编码方式就采用默认的ISO-8859-1。 ContentType属性指定了MIME类型和JSP页面回应时的字符编码方式。MIME类型的默认值是“text/html”; 字符编码方式的默认值是“ISO-8859-1”. MIME类型和字符编码方式由分号隔开。

pageEncoding是jsp文件本身的编码

contentType的charset是指服务器发送给客户端时的内容编码

JSP要经过两次的“编码”，第一阶段会用pageEncoding，第二阶段会用utf-8至utf-8，第三阶段就是由Tomcat出来的网页， 用的是contentType。

第一阶段是jsp编译成.java，它会根据pageEncoding的设定读取jsp，结果是由指定的编码方案翻译成统一的UTF-8 JAVA源码（即.java），如果pageEncoding设定错了，或没有设定，出来的就是中文乱码。

第二阶段是由JAVAC的JAVA源码至java byteCode的编译，不论JSP编写时候用的是什么编码方案，经过这个阶段的结果全部是UTF-8的encoding的java源码。

JAVAC用UTF-8的encoding读取java源码，编译成UTF-8 encoding的二进制码（即.class），这是JVM对常数字串在二进制码（java encoding）内表达的规范。

第三阶段是Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码，输出的结果，也就是在客户端见到的，这时隐藏在阶段一和阶段二的参数contentType就发挥了功效

jsp文件不像.java，.java在被编译器读入的时候默认采用的是操作系统所设定的locale所对应的编码，比如中国大陆就是GBK，台湾就是BIG5或者MS950。但是jsp文件不是这样，它没有这个默认转码过程，但是指定了pageEncoding就可以实现正确转码了。

举个例子:

<%@ page contentType="text/html;charset=utf-8" %> 

大都会打印出乱码，因为我输入的“中国”是gbk的，但是服务器是否正确抓到“中国”不得而知。

但是如果更改为

<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%> 

这样就服务器一定会是正确抓到“中国”了。

2、 服务器端参数的编码问题

服务器端向response流里写数据前可以调用response.setContentType()，设定正确的编码类型，其作用等效于jsp中设置的 contentType属性值。

在服务器端接收参数时，由Request.getParameter() 得到的参数，编码方式都是ISO8859_1。所以如果在浏览器输入框内输入一个汉字“英”，在服务器端就得到一个ISO8859_1编码的（0x00,0xD3,0x00,0xA2）。所以通常在接收参数时转码：

String parameter = response.getParameter(“name”);   
 
parameter = new String(parameter.getBytes(“ISO8859_1”),“UTf-8”);  
 
String wrongStr = response.getParameter(“name”);
 
String correctStr = new String(wrongStr.getBytes(“ISO8859_1”),”GB2312”);

在最新的SERVLET规范里面，也可以在获取参数之前执行如下代码：

request.setCharacterEncoding(“GB2312”);  

3、 数据库存储的编码问题

(1)  数据库使用UTF-8

如果String中是UNICODE字符，写入读出时不需要转码

(2)  数据库使用ISO8859_1

如果String中是UNICODE字符，写入读出时需要转码

写入：

String newStr = new String(oldStr.getByte(“UTf-8”), “ISO8859_1”);  
 
String newStr = new String(oldStr.getByte(“GB2312”), ISO8859_1”);

读出：

String newStr = new String(oldStr.getByte(“ISO8859_1”),” UTf-8”); 

4、 文件读取的编码问题

（1）   从外部资源读取数据

这跟外部资源采取的编码方式有关，我们需要使用外部资源采用的字符集来读取外部数据：

InputStream is = new FileInputStream("res/input.data");   
 
InputStreamReader streamReader = new InputStreamReader(is, "UTF-8"); 

但是我们经常写的程序是这样的：

InputStream is = new FileInputStream("res/input.data");   
 
InputStreamReader streamReader = new InputStreamReader(is);  

这种情况下InputStreamReader采用什么编码方式读取外部资源呢？这时候采用的编码方式是JVM的默认字符集，这个默认字符集在虚拟机启动时决定，通常根据语言环境和底层操作系统的 charset 来确定。可以通过以下方式得到JVM的默认字符集：

 
Charset.defaultCharset(); 

需要注意的是：大多数情况下 windows系统的默认字符集是IOS8859-1；linux系统的默认字符集是可以自行设定的。

5、 需要强调的几个方法

1.  getBytes(charset)

这是java字符串处理的 一个标准函数，其作用是将字符串所表示的字符按照charset编码，并以字节方式表示。注意字符串在java内存中总是按unicode编码存储的。比 如"中文"，正常情况下（即没有错误的时候）存储为"4e2d 6587"，如果charset为"gbk"，则被编码为"d6d0 cec4"，然后返回字节"d6 d0 ce c4"。如果charset为"utf8"则最后是"e4 b8 ad e6 96 87"。如果是"iso8859-1"， 则由于无法编码，最后返回 "3f 3f"（两个问号）。

2.  new String(charset)

这是java字符串处 理的另一个标准函数，和上一个函数的作用相反，将字节数组按照charset编码进行组合识别，最后转换为unicode存储。参考上述getBytes 的例子，"gbk" 和"utf8"都可以得出正确的结果"4e2d 6587"，但iso8859-1最后变成了"003f 003f"（两个问号）。

因为utf8可以用来表示/编码所有字符，所以new String( str.getBytes( "utf8" ), "utf8" ) === str，即完全可逆。

3.  setCharacterEncoding()

该函数用来设置http请求或者相应的编码。

对于request，是指提交内容的编码，指定后可以通过getParameter() 则直接获得正确的字符串，如果不指定，则默认使用iso8859-1编码，需要进一步处理。值得注意的是在执行 setCharacterEncoding()之前，不能执行任何getParameter()。而且，该指定只对POST方法有效，对GET方法无效。分析原因，应该是在执行第一个getParameter()的时候，java将会按照编码分 析所有的提交内容，而后续的getParameter()不再进行分析，所以setCharacterEncoding()无效。而对于GET方法提交表 单是，提交的内容在URL中，一开始就已经按照编码分析所有的提交内容，setCharacterEncoding()自然就无效。

对于response，则是指定输出内容的编码，同时，该设置会传递给浏览器，告诉浏览器输出内容所采用的编码。