1. 响应编码
服务器发给客户端
- 当使用response.getWriter()来向客户端发送字符数据时,如果在之前没有设置编码,那么服务器默认使用iso(TomCat 8版本后默认编码方法改为UTF-8),因为iso不支持中文,一定造成乱码。
- 在使用response.getWriter()之前可以使用response.setCharaceterEncoding()来设置字符流的编码为gbk或utf-8,当然我们通常会选择utf-8。这样使用response.getWriter()发送的字符就是使用utf-8编码的。但还是会出现乱码!因为浏览器并不知道服务器发送过来的是什么编码的数据!这时浏览器会使用gbk来解码,所以还会造成乱码!
- 在使用response.getWriter()之前可以使用response.setHeader(“Content-type”,“text/html;charset=utf-8”)来设置响应头,通知浏览器服务器这边使用的是utf-8编码,而且在调用setHeader()后,还会自动执行setCharacterEncding()方法。这样浏览器会使用utf-8解码,所以就不会乱码了!
- setHeader(“Content-Type”, “text/html;charset=utf-8”)的快捷方法是:setContentType("text/html;charset=utf-8)。
response 中的 setContentType(String ct) 方法可以设置即将发送给客户端的响应的 content type,content type 中可以包含对响应编码的设定,比如"text/html;charset=UTF-8"。同调用 request 的 setCharacterEncoding 一样,它也必须在获得输出流之前调用。另外该方法setContentType("text/html;charset=utf-8) 等价于下面两句:
response.setCharacterEncoding(“UTF-8”);//设置响应编码
response.setHeader(“Content-Type”,“text/html;charset=UTF-8”);//通知浏览器如何解码
2. 请求编码
客户端发给服务器
忽略图中的1234
- 客户端发送给服务器的请求参数是什么编码:
客户端首先要打开一个页面,然后在页面中提交表单或点击超链接!在请求这个页面时(就比如输入网址),服务器响应的编码是什么,那么客户端发送请求时的编码就是什么。 - 服务器端默认使用什么编码来解码参数:
服务器端默认使用ISO-8859-1来解码!所以这一定会出现乱码的!因为iso不支持中文!
TomCat 8版本后默认编码方法改为UTF-8,如果版本在8及以后就不用改了 - 请求编码处理分为两种:GET和POST
GET请求参数不在请求体中,而POST请求参数在请求体中,所以它们的处理方式是不同的! - GET请求编码处理:
(1).
String username = request.getParameter("username");
byte[] b = name.getBytes("iso-8859-1");
name = new String(b, "utf-8");
反编码再编回来,我们用这个方法
(2).
在server.xml中配置URIEncoding=“UTF-8”
在server.xml中配置后GET请求都默认使用UTF-8,但是没有可移植性
(3).
String name = request.getParameter("username");
如果TomCat 版本在8之后,就不用做任何修改,直接getParameter
5. POST请求编码处理:
/*
* 1. 在获取参数之前,需要先调用request.setCharacterEncoding("utf-8");
* 2. 使用getParameter()来获取参数
*/
req.setCharacterEncoding("utf-8");
String username = req.getParameter("username");
System.out.println(username);
request 中的 setCharacterEncoding(String enc) 方法可以设定针对请求体(post 提交的数据即在请求体中)的解码方式,通过它设置与请求体一致的编码是 post body 中的数据不乱码的关键。不过需要注意的是该方法必须在读取请求参数或者获得输入流之前调用,一般写在比较靠前的过滤器中。
3.URL编码
表单的类型:Content-Type: application/x-www-form-urlencoded,就是把中文转换成%后面跟随两位的16进制。
如图:
为什么要用它:在客户端和服务器之间传递中文时需要把它转换成网络适合的方式。
需要我们自己动手给数据转换成URL编码的只有GET超链接,因为表单发送数据会默认使用URL编码,也就是说,不用我们自己来编码。
String name = "张三";
String s = URLEncoder.encode(name, "UTF-8");
System.out.println(s);
//%E5%BC%A0%E4%B8%89
s = URLDecoder.decode(s, "utf-8");
System.out.println(s);
//张三
- 它不是字符编码!
- 它是用来在客户端与服务器之间传递参数用的一种方式!
- URL编码需要先指定一种字符编码,把字符串解码后,得到byte[],然后把小于0的字节+256,再转换成16进制。前面再添加一个%。
- POST请求默认就使用URL编码!tomcat会自动使用URL解码!
- URL编码:String username = URLEncoder.encode(username, “utf-8”);
- URL解码:String username = URLDecoder.decode(username, “utf-8”);
最后我们需要把链接中的中文参数,使用url来编码!
4.对应乱码成因解析
- "??"乱码分析:
ISO-8859-1 仅能编码非英文字符,所以非英文字符被其编码时会被转换为 0x3F(即?的 ASCII 编码,也是 UTF-8 编码),这时编码已经真被转成不可逆的乱码了。之后无论用兼容 ASCII 的哪种编码方案解码还原出的字符串都是"?"。
结果:所以出现?时基本可以猜测是客户端错误按 ISO-8859-1 进行了编码。
- "²âÊÔ"乱码分析:
ISO-8859-1 仅能表示非英文字符,所以使用其解码时会严格按一个字节一个字节地进行解析(这种操作其实对编码没构成破坏,还可以重新用 ISO-8859-1 获取字节流后再用正确的编码方式解码得到正确的字符串)。
结果:所以乱码字符均是来自 ISO-8859-1 中字符集中的字符时基本可以猜测是服务端错误按 ISO-8859-1 进行了解码。
- "����"乱码分析:
用 UTF-8 解码经 GB18030 编码的字节流时发现四个字节均为 UTF-8 非法字节流,所以直接转化为了�。
5.解决乱码因素
6.路径
- web.xml中路径,(叫它Servlet路径!)
> 要么以“*”开关,要么为“/”开头 - 转发和包含路径
> 以“/”开头:相对当前项目路径,例如:http://localhost:8080/项目名/
举例:request.getRequestdispacher("/BServlet").for…() 就是 http://localhost:8080/项目名/BServlet
> 不以“/”开头:相对当前Servlet路径。
request.getRequestdispacher("/BServlet").for…();,假如当前Servlet是:
http://localhost:8080/项目名/servlet/AServlet,
这个就是http://localhost:8080/项目名/servlet/BServlet - 重定向路径(客户端路径,必须加项目名)
> 以“/”开头:相对当前主机,例如:http://localhost:8080/,所以需要自己手动添加项目名。
例如:response.sendRedirect("/day10_1/Bservlet"); - 页面中超链接和表单路径
> 与重定向相同,都是客户端路径!需要添加项目名
> <form action="/day10_1/AServlet">
> <a href="/day10_/AServlet">
> <a href=“AServlet”>,如果不以“/”开头,那么就是相对当前页面所在路径。如果是http://localhost:8080/day10_1/html/form.html。 <a href=“AServlet”>即:http://localhost:8080/day10_1/html/ASevlet
> 建立使用以“/”开头的路径,即绝对路径! - ServletContext获取资源路径
> 相对当前项目目录,即当然index.jsp所在目录(WebRoot里面) - ClassLoader(类加载器)获取资源路径
> 不能以“/”开头,相对classes目录 - Class获取资源路径
> 以“/”开头相对classes目录
> 不以“/”开头相对当前.class文件所在目录。