前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >JavaWeb(一)Servlet中乱码解决与转发和重定向的区别

JavaWeb(一)Servlet中乱码解决与转发和重定向的区别

作者头像
用户1195962
发布2018-01-18 16:11:59
1.4K0
发布2018-01-18 16:11:59
举报
文章被收录于专栏:LanceToBigDataLanceToBigData

前言

  前面其实已经把Servlet中所有的内容都介绍完了,这篇讲补充一点乱码和重定向与转发之间的区别!

一、request请求参数出现乱码问题

1.1、get请求

  1)乱码示例

  get请求的参数是在url后面提交过来的,也就是在请求行中。

  结果:

    Servlet_demo_0040是一个普通的Servlet,浏览器访问它时,使用get请求方式提交了一个username=小明的参数值,在doGet中获取该参数值,并且打印到控制台,发现出现乱码

  2)出现乱码原因

    前期知识:

      码表:是一种规则,用来让我们看得懂的语言转换为电脑能够认识的语言的一种规则,有很多中码表,IS0-8859-1,GBK,UTF-8,UTF-16等一系列码表,

         比如GBK,UTF-8,UTF-16都可以标识一个汉字,而如果要标识英文,就可以用IS0-8859-1等别的码表。

      编码:将我们看得懂的语言转换为电脑能够认识的语言。这个过程就是编码的作用。

      解码:将电脑认识的语言转换为我们能看得懂得语言。这个过程就是解码的作用

    这里只能够代表经过一次编码例子,有些程序中,会将一个汉字或者一个字母用不同的码表连续编码几次,那么第一次编码还是上面所说的作用,第二次编码的话,

    就是将电脑能够认识的语言转换为电脑能够认识的语言(转换规则不同),那么该解码过程,就必须要经过两次解码,也就是编码的逆过程,下面这个例子就很好的说明了这个问题:

    浏览器使用的是UTF-8码表,通过http协议传输,http协议只支持IS0-8859-1,到了服务器,默认也是使用的是IS0-8859-1的码表,看图:

    从上面的图中可以看出,就是三个过程,经历了两次编码,所以就需要进行两次解码:

      1)浏览器将"小明"使用UTF-8码表进行编码(因为小明这个是汉字,所以使用能标识中文的码表,这也是我们可以在浏览器上可以手动设置的,如果使用了不能标识中文的码表,那么就将会出现乱码,

        因为码表中找不到中文对应的计算机符号,就可能会用??等其他符号表示),编码后得到的为 1234 ,将其通过http协议传输。

      2)在http协议传输,只能用ISO-8859-1码表中所代表的符号,所以会将我们原先的1234再次进行一次编码,这次使用的是ISO-8859-1,得到的为 ???? ,然后传输到服务器。

      3)服务器获取到该数据是经过了两次编码后得到的数据,所以必须跟原先编码的过程逆过来解码,先是UTF-8编码,然后在ISO-8859-1编码,那么解码的过程,就必须是先ISO-8859-1解码,然后在用UTF-8解码,

        这样就能够得到正确的数据。????.getBytes("ISO-8859-1");//第一次解码,转换为电脑能够识别的语言, new String(1234,"UTF-8");//第二次解码,转换为我们认识的语言

  3)解决方法

    结果:

1.2、post请求

  post请求方式的参数是在请求体中,相对于get请求简单很多,没有经过http协议这一步的编码过程,所以只需要在服务器端,设置服务器解码的码表跟浏览器编码的码表是一样的就行了,

  在这里浏览器使用的是UTF-8码表编码,那么服务器端就设置解码所用码表也为UTF-8就OK了。

  设置服务器端使用UTF-8码表解码:

    request.setCharacterEncoding("UTF-8");  //命令Tomcat使用UTF-8码表解码,而不用默认的ISO-8859-1了。

  所以在很多时候,在doPost方法的第一句,就是这句代码,防止获取请求参数时乱码。

总结请求参数乱码问题:

  get请求和post请求方式的中文乱码问题处理方式不同

  get:请求参数在请求行中,涉及了http协议,手动解决乱码问题,知道出现乱码的根本原因,对症下药,其原理就是进行两次编码,两次解码的过程

    new String(xxx.getBytes("ISO-8859-1"),"UTF-8");

  post:请求参数在请求体中,使用servlet API解决乱码问题,其原理就是一次编码一次解码,命令tomcat使用特定的码表解码。

    request.setCharaterEncoding("UTF-8");

二、response响应回浏览器出现中文乱码

  首先介绍一下,response对象是如何向浏览器发送数据的。两种方法,一种getOutputStream,一种getWrite:  

    ServletOutputStream getOutputStream();  //获取输出字节流,提供write() 和 print() 两个输出方法。

    PrintWriter getWrite();  //获取输出字符流,提供write() 和 print()两个输出方法。

  print()方法底层都是使用write()方法的,相当于print()方法就是将write()方法进行了封装,使开发者更方便快捷的使用,想输出什么,就直接选择合适的print()方法,而不用考虑如何转换字节。  

2.1、ServeltOutputStream getOutputStream(); 

  结果:不能直接输出中文,直接输出中文会报异常    

  报异常的源码分析:

  解决方法:

    resp.getoutputStream().write("哈哈哈,我要输出到浏览器".getBytes("UTF-8"));

    将要输出的汉字先用UTF-8进行编码,而不用让tomcat来进行编码,这样如果浏览器用的是UTF-8码表进行解码的话,那么就会正确输出,如果浏览器用的不是UTF-8,那么还是会出现乱码,

    所以说这个关键要看浏览器用的什么码表,这个就不太好,这里还要注意一点,就是使用的是write(byte)方法,因为print()方法没有输出byte类型的方法。

    测试:因为我用的是谷歌浏览器它默认使用的是GB2312所以这里使用的是GB2312

2.2、PrintWriter getWrite();

  直接输出中文,不会报异常,但是肯定会报异常,因为用ISO-8859-1的码表不能标识中文,一开始就是错的,怎么解码编码读没用了。

  有三种方法来让其正确输出中文:

  1)使用Servlet API  response.setCharacterEncoding()

    response.setCharacterEncoding("UTF-8");  //让tomcat将我们要响应到浏览器的中文用UTF-8进行编码,而不使用默认的ISO-8859-1了,这个还是要取决于浏览器是不是用的UTF-8的码表,跟上面的一样有缺陷。

    测试:因为我用的是谷歌浏览器它默认使用的是GB2312所以这里使用的是GB2312

  2)通知tomcat和浏览器都使用同一张码表

    response.setHeader("content-type","text/html;charset=uft-8");  //手动设置响应内容,通知tomcat和浏览器使用utf-8来进行编码和解码。  

      charset=uft-8就相当于response.setCharacterEncoding("UTF-8");//通知tomcat使用utf-8进行编码

      response.setHeader("content-type","text/html;charset=uft-8");//合起来,就是既通知tomcat用utf-8编码,又通知浏览器用UTF-8进行解码。

    response.setContentType("text/html;charset=uft-8");  //使用Servlet API 来通知tomcat和强制浏览器使用UTF-8来进行编码解码,这个的底层代码就是上一行的代码,进行了简单的封装而己。

  3)通知tomcat,在使用html<meta>通知浏览器 (html源码),注意:<meta>建议浏览器应该使用编码,不能强制要求

    所以response在响应时,只要通知tomcat和浏览器使用同一张码表,一般使用第二种方法,那么就可以解决响应的乱码问题了

三、总结请求和响应的乱码

3.1、请求乱码 

  get请求:

    经过了两次编码,所以就要两次解码

      第一次解码:xxx.getBytes("ISO-8859-1");得到yyy

      第二次解码:new String(yyy,"utf-8");

    连续写:new String(xxx.getBytes("ISO-8859-1"),"UTF-8");

  post请求:

    只经过一次编码,所以也就只要一次解码,使用Servlet API request.setCharacterEncoding();

    request.setCharacterEncoding("UTF-8");  //不一定解决,取决于浏览器是用什么码表来编码,浏览器用UTF-8,那么这里就写UTF-8。

3.2、响应乱码

  getOutputStream();:

    使用该字节输出流,不能直接输出中文,会出异常,要想输出中文,解决方法如下

    解决:getOutputStream().write(xxx.getBytes("UTF-8"));  //手动将中文用UTF-8码表编码,变成字节传输,变成字节后,就不会报异常,并且tomcat也不会在编码,因为已经编码过了,所以到浏览器后,

                                如果浏览器使用的是UTF-8码表解码,那么就不会出现中文乱码,反之则出现中文乱码,所以这个方法,不能完全保证中文不乱码

  getWrite();:

    使用字符输出流,能直接输出中文,不会出异常,但是会出现乱码。能用三种方法解决,一直使用第二种方法

    解决:通知tomcat和浏览器使用同一张码表。

 response.setContentType("text/html;charset=utf-8");  //通知浏览器使用UTF-8解码 

    通知tomcat和浏览器使用UTF-8编码和解码。这个方法的底层原理是这句话:response.setHeader("contentType","text/html;charset=utf-8"); 

  注意:getOutputStream()和getWrite() 这两个方法不能够同时使用,一次只能使用一个,否则报异常 

四、Servlet中请求和转发的区别

 4.1、使用方式 

  1)在servlet中调用转发、重定向的语句如下:

代码语言:javascript
复制
request.getRequestDispatcher("new.jsp").forward(request, response); //转发到new.jsp
response.sendRedirect("new.jsp"); //重定向到new.jsp

  2)在jsp页面中你也会看到通过下面的方式实现转发:

代码语言:javascript
复制
<jsp:forward page="apage.jsp" />

  当然也可以在jsp页面中实现重定向:

代码语言:javascript
复制
<%response.sendRedirect("new.jsp"); %> //重定向到new.jsp

  示例:

代码语言:javascript
复制
//获取username信息
String username=request.getParameter("username");
 //转发与重定向
 if(username.equals("admin")){
  //提示用户已存在,不能注册
  request.setAttribute("message","该用户已存在,不能注册");//添加提示信息,需要在userCreate.jsp页面中进行提示信息展示
  request.getRequestDispatcher("userCreate.jsp").forward(request, response);//转法
 }else{
  //提示注册成功
  request.setAttribute("message","注册成功");
  response.sendRedirect("indext.jsp");//重定向
 }

4.2、区别:重定向和转发的工作流程

  1)转发的工作流程‘

    第一步:客户浏览器发送http请求     第二步:web服务器接受此请求         第三步:调用内部的一个方法在容器内部完成请求处理和转发动作       第四步:将目标资源发送给客户;在这里,转发的路径必须是同一个web容器下的url,其不能转向到其他的web路径上去,中间传递的是自己的容器内的request。在客户浏览器路径栏显示的仍然是其第一次访问的路径,         也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。 

  2)重定向的工作流程

    第一步:客户浏览器发送http请求     第二步:web服务器接受后发送302状态码响应及对应新的location给客户浏览器     第三步:客户浏览器发现是302响应,则自动再发送一个新的http请求,请求url是新的location地址     第四步:服务器根据此请求寻找资源并发送给客户。在这里location可以重定向到任意URL,既然是浏览器重新发出了请求,则就没有什么request传递的概念了。         在客户浏览器路径栏显示的是其重定向的路径,客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求的。

  总结:一句话,转发是服务器行为,重定向是客户端行为。

4.3、区别:请求次数

  1)重定向

    重定向,其实是两次request

    第一次,客户端request   A,服务器响应,并response回来,告诉浏览器,你应该去B。这个时候IE可以看到地址变了,而且历史的回退按钮也亮了。重定向可以访问自己web应用以外的资源。在重定向的过程中,传输的信息会被丢失。

    举例:          

代码语言:javascript
复制
    response.sendRedirect("loginsuccess.jsp"); 

  2)转发

    转发是一次request  

    请求转发是服务器内部把对一个request/response的处理权,移交给另外一个

    对于客户端而言,它只知道自己最早请求的那个A,而不知道中间的B,甚至C、D。传输的信息不会丢失。  

代码语言:javascript
复制
     RequestDispatcher dis=request.getRequestDispatcher(“loginsuccess.jsp”);
       dis.forward(request,response);

 4.4、生活中的例子说明区别

  假设你去办理某个执照   重定向:你先去了A局,A局的人说:“这个事情不归我们管,去B局”,然后,你就从A退了出来,自己乘车去了B局。   转发:你先去了A局,A局看了以后,知道这个事情其实应该B局来管,但是他没有把你退回来,而是让你坐一会儿,自己到后面办公室联系了B的人,让他们办好后,送了过来。

五、总结Servlet中请求和转发的区别

  1)重定向的执行过程:Web服务器向浏览器发送一个http响应--》浏览器接受此响应后再发送一个新的http请求到服务器--》服务器根据此请求寻找资源并发送给浏览器。它可以重定向到任意URL,不能共享request范围内的数据。   2)重定向是在客户端发挥作用,通过新的地址实现页面转向。   3)重定向是通过浏览器重新请求地址,在地址栏中可以显示转向后的地址。   4)转发过程:Web服务器调用内部方法在容器内部完成请求和转发动作--》将目标资源发送给浏览器,它只能在同一个Web应用中使用,可以共享request范围内的数据。   5)转发是在服务器端发挥作用,通过forward()方法将提交信息在多个页面间进行传递。   6)转发是在服务器内部控制权的转移,客户端浏览器的地址栏不会显示出转向后的地址。

喜欢就点个“推荐”哦!

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2017-10-06 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、request请求参数出现乱码问题
    • 1.1、get请求
      • 1.2、post请求
      • 二、response响应回浏览器出现中文乱码
        • 2.1、ServeltOutputStream getOutputStream(); 
          • 2.2、PrintWriter getWrite();
          • 三、总结请求和响应的乱码
            • 3.1、请求乱码 
              • 3.2、响应乱码
              • 四、Servlet中请求和转发的区别
                •  4.1、使用方式 
                  • 4.2、区别:重定向和转发的工作流程
                    • 4.3、区别:请求次数
                      •  4.4、生活中的例子说明区别
                      • 五、总结Servlet中请求和转发的区别
                      相关产品与服务
                      容器服务
                      腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
                      领券
                      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档