总结的一下JSP.TOMCAT编码问题

jsp中的乱码问题 

 

java的.class文件和.java文件都是unicode(应该都是modified utf-8,这个没求证过),.java文件的编译是由编译器完成的,它的编码独立于操作系统

  1、首先说读取数据，web服务器接收请求时，接受到的是字节序列，转化为字符时就需要知道此字符序列的编码，才能正确转化。对于tomcat来讲，如果未指定则默认使用iso8859-1，而通常中文平台的编码是gb2312，所以就会产生乱玛。 

  2、 <%@  page  contentType="text/html;  charset=GBK"  %>  
  这句的意思是设置http响应头，提示浏览器使用的字符编码，同时设置http响应(response)的字符编码。 

  3、对于tomcat的get请求，编码的处理是在server.xml的connctor的URIEncoding中指定的，如果不指定，默认编码为ISO-8859-1

 

  4.无论是post还是get都是按页面的编码进行提交，即pageEncoding。如果pageEncoding属性存在，那么JSP页面的字符编码方式就由pageEncoding决定，否则就由contentType属性中的charset决定；如果charset也不存在，JSP页面的字符编码方式就采用默认的ISO-8859-1。后台处理完成后以charset设定的编码方式返回给JSP页面。未设定时，pageEncoding和charset默认都是ISO-8859-1。

 
  5.在程序里获取的参数就是以pageEncoding方式编码的内容。

  6.提交表单时不会进行URLEncoder.encode()或URLDecoder.decode()，对get方式提交的数据,浏览器会自动对其进行编码，默认是按UTF-8编码格式.所以尽量用post方式提交,一是避免这种乱码,二是数据不会在地址栏上暴露出来.。另外,URLEncoder.encode()和URLDecoder.decode()是互为可逆的两个方法。

  7.如果设置了过滤器，只能对post方式提交的数据自动转码；如果在server.xml中设置了URIEncoding，只能对get方式提交数据自动转码。如果这两项都没有设置，需要时可以手动进行转码。 

  8.s = new String(s.getBytes("GBK"), "UTF-8");之后，用s = new String(s.getBytes("UTF-8"), "GBK")转回会出问题。GBK和UTF-8之间的确不是随意转换的,或者说有些转换是不可逆的,这个时候需要考虑的是选用其它编码,或者所有编码方式统一起来

 

utf-8是unicode字符集外部交互的实现方式之一,unicode是字符集.
utf-8就是Unicode字符集转换格式:8 Bit Universal Character Set/Unicode Transformation Format).(或者8Bit放后面? 这个我不确定)
java采用的是modified UTF-8(与UTF-8不同)作为内部文本编码,I/O采用标准UTF-8,对象序列化支持非标准UTF-8.但是字符编码是统一的unicode字符集并且基于JVM和操作系统无关.
页面无论采用utf-8还是utf-16,都能和java直接交互无须转码,因为UTF-x虽然实现不同,但是都基于unicode字符集.

unicode,gbk,gb2312,big5,SJIS都是字符集,不过由于最全面的字符集unicode同其他字符集交互(目前unicode最常用的USC-2,也就是2字节编码)在控制符方面可能会引入严重的错误,比如"号,所以unicode字符集和其他字符集交互,需要通过utf-x的新编码方式来保证准确性.
也就是说某个数据以unicode字符集格式存在,但是为了和其他字符集交互,它实际的保存形式是以utf-x的方式存在的.