Servlet相关

Servlet请求路径

具体请求路径:(经常使用这种,其余的架构师经常使用)

浏览器请求的地址与当前Servlet中的<url-pattern>中内容彻底一致
以'/'开头

前置请求路径:

<url-pattern>/abc/*</url-pattern>(例子)
'*'是一个通配符,表任意长度字符串

后置请求路径:

<url-pattern>*.do</url-pattern>(例子)

通配符请求路径:

<url-pattern>/*</url-pattern>(全部网址均可访问)

请求路径优先级:具体>前置>通配符>后置

Servlet实例对象的生命周期

1. 项目中全部的Servlet实例对象都由tomcat负责建立,开发人员无权建立

2. 建立时机:

   1. 默认状况下,第一次访问时,tomcat建立实例对象
   2. 人工干预,在tomcat启动的时候建立.在配置文件中的Servlet标签中加入load-on-startup标签,里面放一个大于0的整数就行
   3. 在tomcat运行期间,一个Servlet实现类只能被建立一个实例对象
   4. 在tomcat关闭时,由tomcat负责销毁全部Servlet实例对象

---

Servlet开发时使用的五种工具对象

1. HttpServletResponse接口:负责将运行结果写入到响应包
2. HttpServletRequest接口:读取请求协议包信息
3. ServletContext接口:可为当前网站中的全部Servlet提供共享数据
4. Cookie:在一次会话过程当中,存储浏览器在服务端产生的私人数据
5. HttpSession接口：在一次会话过程当中，存储浏览器在服务端产生的私人数据

HttpServletResponse接口:

1. 来自Servlet规范中的接口,实现类由tomcat负责提供
2. 其修饰的对象通常称为"响应对象"
3. 将相关数据写入到响应头和响应体

如何将"英文字符串"写入到响应体
String str="hello";
从响应对象得到一个"输出流"
PrintWriter out =Response.getWriter();
out.write(str);

若是将字符串替换成int 50呢?网页结果是2.
out.write()方法只能将"字符串"或"unicode码"写入到响应体
值为50的unicode码对应的字符串"2"
此时换用print()方法.可将任意类型数据写入到响应体中并保持原有类型

String str="明天休息";
out.write(str);
结果显示乱码

浏览器是根据响应头中设置的字符集对接收内容进行解码
在默认状况下响应头的字符集为ISO-8859-1
在得到输出流以前设置响应头中字符集
String str="下课休息";
response.setCharacterEncoding("GBK");
response.getWriter().writer(str);

String str="apple<br/>oranger<br/>egg";
通常浏览器默认状况下响应头中[内容类型]是test
设置响应头内容类型
response.setcontentType("text/html;charset=GBK");

写一个Servlet用来经过JDBC查询表,并把表信息写入到响应体中

HttpServletRequest接口:

其修饰对象request,称为响应对象.可读取请求协议包相关信息,相似于Scanner
request.getRequestURL();获取请求地址
request.getMethod();获取请求方法
request.getParameterNames();获取请求头(体)中的请求参数名
request.getParameter("请求参数名");返回一个字符串(单个请求参数)
request.getParameterValues("请求参数名");返回一个数组(多个同名参数)复选框做为参数时

请求对象和响应对象的生命周期

1. 每当Tomcat收到一个请求协议包时,会为其建立一对请求对象和响应对象
2. 一次请求对应一对请求对象和响应对象
3. Servlet被请求时,Tomcat将两个对象做为参数传入到服务方法中(doGet/doPost)
4. 服务方法工做完毕后,Tomcat负责销毁两个对象
5. Tomcat负责将响应包推送到浏览器上

当浏览器以Get方式发送请求时,请求参数存放在请求头,在请求协议包到达服务端时,请求头的内容由Tomcat解析,Tomcat9.0在解析数据时,默认采用的字符集是utf-8.此时浏览器发送的中文参数不会再服务端出现乱码问题
以Post方式发送请求时,请求参数存放在请求体中,到达服务端时由对应的请求对象负责解析,request对象默认使用ISO-8859-1字符集,此时请求出现中文字符会出现乱码问题
方案:在request对象解析数据前,从新设置使用字符集
request.setCharacterEncoding("utf-8");
String value=request.getParameter("参数");

---

ServletContext接口

1.servlet规范中的一个接口,接口实现类由Tomcat负责提供
2.为当前工程中的全部servlet提供共享数据
3.习惯将其修饰对象称为全局做用域对象

在Tomcat启动时, 由其建立全局做用域对象,一个网站只能有一个全局做用域对象,当网站关闭时,由Tomcat负责销毁
向Tomcat索要当前工程的全局做用域对象
ServletContext application = request.getServletContext();


共享数据的来源
1.开发人员添加到web.xml中
    <context-param>
        <param-name>共享数据名称</param-name>
        <param-value>共享数据内容</param-value>
    </context-patam>
    共享数据内容=application.getInitParameter("共享数据名称");
    此时共享数据只能读取,不能修改.
2.由某个servlet将数据写入全局做用域对象中,其余servlet可使用
    写入:application.serAttribute("共享数据名",共享数据内容); 数据可任意类型
    获取:application.getAttribute("共享数据名");
    此时servlet的数据能够被修改,一样使用setAttribute将共享数据名覆盖便可

---

会话

浏览器和服务端一次完整的交流
特色:

1. 一次会话经历屡次请求和响应
2. 一次会话访问多个不一样的servlet

cookie 和 HttpSession

Cookie

是servlet规范提供的一个工具类
在参与一次会话的servlet之间实现数据共享
Cookie存储在浏览器上,保存本次会话的共享数据

原理:(A和B均表明不一样的servlet)
    浏览器访问A时,A负责将数据保存到cookie,再有response响应到浏览器,当浏览器再访问B时,须要无条件将已存在的cookie推送给B,这样A和B之间就实现了数据共享
    
Cookie的使用:一个cookie只能存储一个键值对,并只能存储String类型数据
    建立
    Cookie c1=new Cookie("key","value");
    写入
    response.addCookie(c1);
    读取
    Cookie array[]=request.getCookies();
    cookie.getName();读取关键字
    cookie.getValue();读取数据内容
生命周期:
    cookie是存储在浏览器中的,因此通常状况下,浏览器关闭时,cookie会被销毁
    人工干预存活时间:
    cookie.setMaxAge(以秒为单位);设定cookie在硬盘上存活的时间

HttpSession

来自servlet规范的一个接口,实现类来自Tomcat
其修饰对象为会话做用域对象,或session对象

与cookie的区别:
    cookie存储在客户端的浏览器或硬盘当中,
    session存储在服务端的内存中
    
    cookie只能存储String数据
    session能够存储任意类型的数据
    
    一个cookie只能存储一个键值对
    一个session能够存储任意数量的键值对
    
使用:
    浏览器来访时,Tomcat不会主动建立相应的HttpSession对象,须要servlet提出要求
    HttpSession session=request.getSession();
    HttpSession session=request.getSession(true);
    若当前浏览器在服务端已有一个session对象,Tomcat将此session返回,若没有则新建一个session对象返回(如来访用户身份已获得确认)
    HttpSession session=request.getSession(false);
    如有则返回,若没有则返回null(当用户身份未获得确认)
    
    session.setAttribute("key",共享数据);
    session.getAttribute("key");
原理:
在Tomcat建立了一个SESSION对象时，为SESSION对象生成一个惟一编号而后将这个编号保存到cookie中，推送到当前的浏览器内存中
等到浏览器再次发送请求时，Tomcat就能够经过读取浏览器返回的cookie来判断浏览器在服务端中是否有session对象

---

Http状态码

Http状态码通知浏览器在收到响应包以后的行为,及告知浏览器,服务端没法提供本次服务的缘由
1xx:通知浏览器本次返回资源文件并不完整,须要浏览器向服务端再次发送请求
2xx:传送文件完整
    200:正常状态码,浏览器和服务端进行了一次完美的通讯
3xx:服务器给浏览器推送的是一个网址,浏览器在接收到该网址后要马上向该网址发送请求
    response.sendRedirect("地址");
4xx:通知浏览器,服务端没法提供本次服务的缘由,是因为服务端没有相应资源
    400:服务端没有相应的资源
    405:服务端有处理本次请求的servlet,但该servlet不支持当前浏览器的请求方式.如浏览器已get方式请求服务端,但相应servlet没有重写doGet方法.
5xx:通知浏览器,服务端未能提供本次服务的缘由,是被调用servlet在运行时出现了异常

默认欢迎资源文件

浏览器向服务器发送了默认请求,没有指定索要的文件的时候
http://localhose/555
手动在web.xml配置
    <welcome-file-list>
        <welcome-file>one.html</welcome-file>
    </welcome-file-list>
当web.xml文件中没有的时候
    Tomcat回到本身的config文件下有个web.xml文件,里面写的有默认的文件名

---

多个servlet来处理一次请求方案

1.重定向方案

在第一个servlet工做完毕后,将第二个servlet的地址发给浏览器,浏览器自动请求第二个servlet
response.sendRedirect(第二个servlet的地址)
发生位置:客户端浏览器上,请求屡次,地址栏内容会发生改变,请求方式必定是get,可访问内网和外网的资源

适用场景:添加,删除,更新后调用查询功能

2.请求转发方案

第一个servlet工做完毕后,代替浏览器向Tomcat申请调用第二个servlet
1.建立一个资源申请报告对象
    RequestDispatcher report=request.getRequestDispatcher("第二个servlet的地址")
2.将申请报告推送给Tomcat,并将第一个servlet的response和request一并发送
    report.forward(request,response)
 
 请求转发时为何将第一个Servelt中request和response交给Tomcat：
    Tomcat在调用第二个Serelt时须要为其提供运行时须要【request】和【response】
    可是，本次请求是由第一个Servelt来发送的，没有对应的【请求协议包】
    所以致使Tomcat在接受到请求后，不会建立【request】和【response】,
    为了解决这个问题，须要将第一个Servlet的request和response交给第二个Servlet来使用。
发生位置在服务端,浏览器只向服务器发送了一次请求,只能访问内部的资源,请求方式始终和第一个servlet保持一致
适用于查询servlet调用jsp