Java Web中的编码问题（二）

Java Web中的编码问题（二）

 

5.HTTP Header的编解码

    对Header中的项进行解码也是在调用request.getHeader时进行的。如果请求的Header项没有解码则调用MessageBytes的toString方法，这个方法对从byte到char的转化使用的默认编码，而我们也不能设置Header的其他解码格式，所以如果你设置的Header中有非ASCII字符，解码中肯定会有乱码。

    我们在添加Header时也是同样的道理，不要在Header中传递非ASCII字符，如果一定要传递，可以先将这些字符用org.apache.cataline.util.URLEncoder编码，再添加到Header中，这样在从浏览器到服务器的传递过程中就不会丢失信息了，我们要访问这些项时再按照相应的字符集解码即可。

6.POST表单的编解码

    POST表单的参数传递方式与QueryString不同，它是通过HTTP的BODY传递到服务端的。当我们在页面上单击提交按钮时浏览器首先将根据ContentType的Charset编码格式对在表单中填入的参数进行编码，然后提交到服务端，在服务端同样也是用ContextType中的字符集进行解码的。所以通过POST表单提交的参数一般不会出现问题，而且这个字符集编码是我们自己设置的，可以通过request.setCharacterEncoding(charset)来设置。

    注意，你一定要在第一次调用request.getParameter方法之前就设置request.setCharacterEncoding(charset)，否则你的POST表单提交上来的数据也可能出现乱码。

    一个奇怪的现象，就是在Tomcat在解析Parameter参数集合之前会获取header的content-type请求头，并且检查这个content-type中的charset值。在默认情况下浏览器在提交form表单时，提交的content-type是不会含有charset信息的。

    所以如果没有设置request.setCharacterEncoding(charset)，那么表单提交的数据将会按照系统的默认编码方式解析。

    另外，针对multipart/form-data类型的参数，也就是上传的文件编码，同样也是使用ContentType定义的字符集编码。