常见的编码
- iso8859-1.gb2312,gbk,utf-8
编码
- 响应编码
- 当使用response.getWriter()来向客户端发送字符数据时,如果没有设置编码 方式,那么默认实用的是iso8859-1
- 在使用response.getWriter()发送之前可以使用response.setCharaceterEncoding()设置字符的发送时编码 的方式,但是这个时候客户端不一定使用的是我们发送时设置的编码方式,还是会乱码
- 在使用response.getWriter()发送字符数据之前使用response.setHeader(“Context-type”,”text/html;charset=”utf-8”)来设置响应头,通知浏览器使用这种方式解码,使用这种方式,服务器端默认使用了 这种编码方式进行发送字符数据,不许要再次设置,也就是说,设置了setHeader(“Content-Type”,”text/html;charset=utf-8”)那么就不需要设置setCharacterEncoding()了,语句顶两句
- 通过设置响应头的编码方式 的快捷方式,setContentType(“text/html;charset=utf-8)这种方式相比最后一种方式,减少了响应头 的名字的设置。
- 请求编码
- 客户端发送给服务器的请求参数是什么编码
- 服务器默认使用iso来解码
- 请求编码的方式处理分为两种get和post
- post请求编码处理
- 设置resquest.setCharacterEncoding(“utf-8”)设置
- 对于POST方式,它采用的编码也是由页面来决定的即ContentType(“text/html; charset=GBK”)。当我通过点击页面的submit按钮来提交表单时,浏览器首先会根据ontentType的charset编码格式来对POST表单的参数进行编码然后提交给服务器,在服务器端同样也是用contentType中设置的字符集来进行解码(这里与get方式就不同了),这就是通过POST表单提交的参数一般而言都不会出现乱码问题。当然这个字符集编码我们是可以自己设定的:request.setCharacterEncoding(charset)设置编码,然后通过
- get请求编码的处理
- 默认通过浏览器地址栏提交参数和表单的get方式提交参数都是使用的iso8859-1进行编码的,针对get方式 请求有两种解决方法
- 在配置文件中server.xml中的http/1.1添加URIEncoding=”UTF-8” ,这样默认的地址栏参数会使用utf-8编码
- 另一种,由于浏览器默认的是使用的是iso8859-1编码的,所以进行反向编码可以正确拿到,如下图:
- 默认通过浏览器地址栏提交参数和表单的get方式提交参数都是使用的iso8859-1进行编码的,针对get方式 请求有两种解决方法
- post请求编码处理
- URL编码
- 表单的类型:Content-type: application/x-www-form-urlencoded 就是把中文转换成%后跟着两位16进制的形式
- 在客户端可服务器之间传递中文时需要把它转换成网络适合的方式
- 他不是字符编码
- 他是用来在客户端和服务器端之间传递参数的一个方式
- URL编码先指定一种字符编码,把字符串解码后,得到byte[],转成16进制,前面在添加一个%号
- URL编码:URLEncoder.encode(username,”utf-8”)
- URL解码:URL.Decoder.decode(uesrname,”utf-8”)
路径
- 服务器端路径一般不用加项目名,但是客户端路径需要添加项目名
- web.xml中的路径,是Servlet路径
- 转发和包含路径,服务器端路径
- 以/开头,相对当前项目路径
- 不以/开头 ,相对当前Servlet路径
- 重定向路径(客户端路径)
- 以/开头,相对当前主机,必须加项目名
- 页面中超链接和表单路径
- 与重定向相同,都是客户端路径,需要添加项目名
- Servletcontext获取资源路径
- 相对当前项目目录
- classloader获取资源路径
- 不以/开头:相对于classes路径
- 以/开头,报错找不到资源
- class获取资源路径
- 以/开头的相对classes目录
- 不以/开头的相对当前类的.class文件所在目录