大略来说,要得到浏览器信息,就找HttpServletRequest工具

HttpServletRequest常用方法

得到客户机【浏览器】信息

getRequestURL方法返回客户端发出要求时的完全URL。
getRequestURI方法返回要求行中的资源名部分。
getQueryString 方法返回要求行中的参数部分。
getPathInfo方法返回要求URL中的额外路径信息。
额外路径信息是要求URL中的位于Servlet的路径之后和查询参数之前的内容,它以“/”开头。
getRemoteAddr方法返回发出要求的客户机的IP地址getRemoteHost方法返回发出要求的客户机的完全主机名getRemotePort方法返回客户机所利用的网络端口号getLocalAddr方法返回WEB做事器的IP地址。
getLocalName方法返回WEB做事器的主机名

得到客户机要求头

jsp中request对象采用什么方法Servlet第四篇request对象常用办法运用修订版 Webpack

getHeader方法getHeaders方法getHeaderNames方法

得到客户机要求参数(客户端提交的数据)

getParameter方法getParameterValues(String name)方法getParameterNames方法getParameterMap方法HttpServletRequest运用

防盗链

什么是防盗链呢?比如:我现在有海贼王最新的资源,想要看海贼王的要在我的网页上看。
现在别的网站的人看到我有海贼王的资源,想要把我的资源粘贴在他自己的网站上。
这样我独家的资源就被一个CTRL+C和CTRL+V抢走了?而反盗链便是不能被他们CRTL+C和CRTL+V

下面我仿照一了局景。
现在我首页先有一个超链接,指向着海贼王最新资源

当我点进去,就能看到海贼王最新资源了

其他的人可以通过复制粘贴我的地址,放到它们的网页上

这样我就划不来啦【我的广告你来没看呢!
】。
想要看我的资源,就必须经由我的首页点进去看。
想要实现这样的效果,就要获取Referer这个头,判断Referer是不是从我的首页来的。
如果不是从我的首页来的,跳转回我的首页。

首先按正常预想的,别人从首页点击我的资源,访问我海贼王最新的资源

\

能够成功访问到资源

如果我在浏览器直接输入地址【此时Referer是为null的】,我们来看看

跳回到首页上,不能访问到海贼王资源

再试试,如果别人粘贴了我的资源url,在它的网页上挂了一个网址呢。

在别人网页上点击的时候

又跳回到了我的首页了。

表单提交数据【通过post办法提交数据】

向表单输入数据

Servlet111得到表单带过来的数据,末了的一个数据是隐蔽域带过来的。

超链接办法提交数据

常见的get办法提交数据有:利用超链接,sendRedirect()

格式如下:

sendRedirect(\"大众servlet的地址?参数名=\"大众+参数值 &\"大众参数名=\公众+参数值);我们来利用一下,通过超链接将数据带给浏览器

<a href=\公众/zhongfucheng/Servlet111?username=xxx\"大众>利用超链接将数据带给浏览器</a>在Servlet111吸收数据

把稳看浏览器左下角

做事器成功吸收到浏览器发送过来的数据

并且,传输数据明文的涌如今浏览器的地址栏上

sendRedirect()和超链接类似,在这里就不赘述了

办理中文乱码问题

细心的朋友会创造,我在获取表单数据的时候,有这句代码 request.setCharacterEncoding(\"大众UTF-8\公众);,如果没有这句代码,会发生什么事呢?我们看看。

再重新填写数据

在做事器查看提交过来的数据,所有的中文数据都乱码了

来这里我们来剖析一下乱码的缘故原由,在前面的博客中我已经先容了,Tomcat做事器默认编码是ISO 8859-1,而浏览器利用的是UTF-8编码。
浏览器的中文数据提交给做事器,Tomcat以ISO 8859-1编码对中文编码,当我在Servlet读取数据的时候,拿到确当然是乱码。
而我设置request的编码为UTF-8,乱码就办理了。
接下来利用get办法通报中文数据,把表单的办法改成get即可当我们访问的时候,又涌现乱码了!

于是我按照上面的办法,把request工具设置编码为UTF-8试试

结果还是乱码。
这是为什么呢?我明明已经把编码设置成UTF-8了,按照post办法,乱码问题已经办理了!

我们来看看get和post办法的差异在哪?为什么post办法设置了request编码就可以办理乱码问题,而get办法不能呢。
首先我们来看一下post方法是怎么进行参数通报的。
当我们点击提交按钮的时候,数据封装进了Form Data中,http要求中把实体主体带过去了【传输的数据称之为实体主体】,既然request工具封装了http要求,以是request工具可以解析到发送过来的数据,于是只要把编码设置成UTF-8就可以办理乱码问题了。

而get办法不同,它的数据是从行带过去的,没有封装到request工具里面,以是利用request设置编码是无效的。

要办理get办法乱码问题也不难,我们既然知道Tomcat默认的编码是ISO 8859-1,那么get办法由体带过去给浏览器的时候肯定是用ISO 8859-1编码了。

上面的代码有些难明得,我画张图解释一下:

经由我们手工转换,再来访问一下

好的,成功办理掉乱码问题了。
除了手工转换,get办法还可以改Tomcat做事器的配置来办理乱码,但是不推举利用,这样不灵巧。
“我们都知道Tomcat默认的编码是ISO 8859-1,如果在Tomcat做事器的配置下改成是UTF-8的编码,那么就办理做事器在解析数据的时候造成乱码问题了在8080端口的Connector上加入 URIEncoding=\公众utf-8\公众,设置Tomcat的访问该端口时的编码为utf-8,从而办理乱码,这种改法是固定利用UTF-8编码的

设置了编码后,没有做任何手工转换,成功拿到数据

当然也有另一种改做事器编码的办法。
设置Tomcat的访问该端口时的编码为页面的编码,这种改法是随着页面的编码而变

设置编码为UTF-8

再次访问

手写超链接如果附带中文参数问题,要URL重写,在JSP博客中会讲到总结:post办法直接改request工具的编码get办法须要手工转换编码get办法也可以修正Tomcat做事器的编码,不推举,由于会太依赖做事器了!
提交数据能用post就用post

实现转发

之前讲过利用response的sendRedirect()可以实现重定向,做到的功能是页面跳转,利用request的getRequestDispatcher.forward(request,response)实现转发,做到的功能也是页面跳转,他们有什么差异呢?现在我先来说下转发

代码如下所示

访问Servlet111

上面已经说了,可以通过sendRedirect()重定向可以在资源尾部添加参数提交数据给做事器。
那么转发能不能提交数据给做事器呢?答案明显是可以的,并且利用这种方法非常频繁在讲ServletContext的时候,曾经说过Servlet之间可以通过ServletContext实现通讯,ServletContext也能称之为域工具。
而request也可以称之为域工具,只不过ServletContext的域是全体web运用,而request的域仅仅代表一次http要求下面我们来利用request实现Servlet之间的通讯,Servlet111代码

Servlet222代码

访问Servlet111看下效果

如上图所示,Servlet222成功拿到了request工具在Servlet111存进的数据。
现在问题又来了,我们可以利用ServletContext和request实现Servlet之间的通讯,那么我们用哪一种呢?一样平常的原则:可以利用request就尽可能利用request。
由于ServletContext代表着全体web运用,利用ServletContext会花费大量的资源,而request工具会随着要求的结束而结束,资源会被回收。
利用request域进行Servlet之间的通讯在开拓中是非常频繁的。

转发的时序图

要求转发的细节

如果在调用forward方法之前,在Servlet程序中写入的部分内容已经被真正地传送到了客户端,forward方法将抛出IllegalStateException非常。
也便是说:不要在转发之前写数据给浏览器我们来试试是不是真的会涌现非常。

访问的时候,看到浏览器可以输出数据,Tomcat后台抛出了非常

如果在调用forward方法之前向Servlet引擎的缓冲区中写入了内容,只要写入到缓冲区中的内容还没有被真正输出到客户端,forward方法就可以被正常实行,原来写入到输出缓冲区中的内容将被清空,但是,已写入到HttpServletResponse工具中的相应头字段信息保持有效。

转发和重定向的差异

实际发生位置不同,地址栏不同

转发是发生在做事器的转发是由做事器进行跳转的,细心的朋友会创造,在转发的时候,浏览器的地址栏是没有发生变革的,在我访问Servlet111的时候,纵然跳转到了Servlet222的页面,浏览器的地址还是Servlet111的。
也便是说浏览器是不知道该跳转的动作,转发是对浏览器透明的。
通过上面的转发时序图我们也可以创造,实现转发只是一次的http要求,一次转发中request和response工具都是同一个。
这也阐明了,为什么可以利用request作为域工具进行Servlet之间的通讯。
重定向是发生在浏览器的重定向是由浏览器进行跳转的,进行重定向跳转的时候,浏览器的地址会发生变革的。
曾经先容过:实现重定向的事理是由response的状态码和Location头组合而实现的。
这是由浏览器进行的页面跳转实现重定向会发出两个http要求,request域工具是无效的,由于它不是同一个request工具

用法不同

很多人都搞不清楚转发和重定向的时候,资源地址究竟怎么写。
有的时候要把运用名写上,有的时候不用把运用名写上。
很随意马虎把人搞晕。
记住一个原则:给做事器用的直接从资源名开始写,给浏览器用的要把运用名写上

request.getRequestDispatcher(\"大众/资源名 URI\"大众).forward(request,response)转发时\"大众/\"大众代表的是本运用程序的根目录【zhongfucheng】response.send(\"大众/web运用/资源名 URI\公众);重定向时\"大众/\公众代表的是webapps目录

能够去往的URL的范围不一样

转发是做事器跳转只能去往当前web运用的资源重定向是做事器跳转,可以去往任何的资源

通报数据的类型不同

转发的request工具可以通报各种类型的数据,包括工具重定向只能通报字符串

跳转的韶光不同

转发时:实行到跳转语句时就会急速跳转重定向:全体页面实行完之后才实行跳转

转发和重定向利用哪一个?

根据上面解释了转发和重定向的差异也可以很随意马虎概括出来。
转发是带着转发前的要求的参数的。
重定向是新的要求。

范例的运用处景:

转发: 访问 Servlet 处理业务逻辑,然后 forward 到 jsp 显示处理结果,浏览器里 URL 不变重定向: 提交表单,处理成功后 redirect 到另一个 jsp,防止表单重复提交,浏览器里 URL 变了

RequestDispatcher再解释

RequestDispatcher工具调用forward()可以实现转发上面已经说过了。
RequestDispatcher还有其余一个方法include(),该方法可以实现包含,有什么用呢?

我们在写网页的时候,一样平常网页的头部和尾部是不须要改变的。
如果我们多个地方利用Servlet输出网头和网尾的话,须要把代码重新写一遍。
而利用RequestDispatcher的include()方法就可以实现包含网头和网尾的效果了。

我们来操作吧!
现在我有网头和网尾的Servlet

利用Servlet111将网头和网尾包含

文章来源:https://dwz.cn/ITegT2xl作者:Java3y