响应中的编码转换问题总结

        Web服务器在向客户断发送消息时，采用PrintWriter（或JspWriter，最后还是调用PrintWriter输出）进行输出，java程序中的字符文本在内存中是以Unicode编码的形式存在，那么在PrintWriter输出文本字符时，需要先将它们转换成其他某种字符编码的字节数组后，再把这些字节数组内容写入到Servlet引擎提供的缓冲区中，再由Servlet引擎将缓冲区中的内容输出到客户端。 

在Web服务器将unicode码形式的文本字符转换成其他某种字符编码的字节数组的时候，采用的方法有三个：

1） HttpServletResponse.setCharacterEncoding(“编码”); //Servlet API 2.4规范中新增方法

2） HttpServletResponse.setContentType();

如：response.setContentType(“text/html;charset=gb2312”);

该方法有两个作用，一个是Servlet输出的MIME类型，即如上的“text/html”，另一个就是指定这里的PrintWriter对象输出文本时采用的字符集编码方式。

3） HttpServletResponse.setLocale();

如：response.setLocale(new java.util.Locale(“zh”, “CN”));

并且在web.xml中映射其对应的字符集编码方式

<locale-encoding-mapping-list>

<locale-encoding-mapping>

<locale>zh_CN</locale>

<encoding>UTF-8</encoding>

</locale-encoding-mapping>

</locale-encoding-mapping-list>

以上三种设置方式的优先级依次下降， setCharacterEncoding()的优先级别最高，而第一个setCharacterEncoding()和第三个setLocale()两个方法对PrintWriter对象输出文本时采用的字符集编码方式设定时，不会显示在响应头文件的Content-Type头字段中，而第二个方法setContentType()将直接改变Content-Type头字段。

       这三种方法都将改变浏览器中显示编码方式的设置，因此，当浏览器显示Web服务器传递过来的字符文本内容时，采用的是以上三种方法中设置的字符集编码方式显示，就能够正常显示。

       浏览器在发送文本字符给Web服务器的时候，采用的是显示时候的编码方式，因此浏览器在发送文本字符给Web服务器时候的URL编码方式和以上三种方法中设置的字符集编码方式相同。

 

       对于静态HTML页面的访问又可以采用什么方法来实现这个功能呢？

      

       为此HTML语言中专门定义了个<meta>标签，<meta>标签中有个http-equiv属性用来在HTML文档中模拟HTTP响应消息头，当浏览器读到HTMl文档中具有http-equiv属性的<meta>标签时，它会用处理WEB服务器发送响应消息头一样的方式来处理。这样，静态HTML中就实现了HTTP响应消息头的功能了。

       如：<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

       它的作用等同于: response.setContentType(“text/html;charset=UTF-8”)。

 

       在浏览器显示Web服务器端发送的消息时候，怎么会出现乱码现象呢？

1)      在servlet源代码中文本字符的unicide编码是该文本字符正确的unicode编码的时候，当在服务器端没有采用以上三种方式对输出文本的字符集编码进行设置时，PrintWriter对象将采用默认的编码的ISO8859-1字符集编码进行Unicode字符串到字节数组的转换，由于IS08859-1字符集中根本没有包括中文字符，Unicode编码的中文字符将被转换成无效的字符编码后输出给客户端，而客户端显示的时候将采用上次设置的字符集编码显示，于是不管怎么设置都将为乱码。

2)      在servlet源代码中文本字符的unicide编码是该文本字符正确的unicode编码的时候，当在服务器端有采用以上三种方式对输出文本的字符集编码进行设置时，由于客户端手动改变显示编码集和如上设置的编码集不同时，将显示乱码。