Previous blog has introduced the definition of the life cycle and about the role of built-in objects, as well as comparative analysis of built-in object data transfer, then you talk about the detail of the application between the various built-in objects
The request object
例：requset.getParameter(“name”);
At this time, neither get the html text nor the characters, but to get from the http protocol characters, the static encoder has been unavailable
solution:
(1) dynamic network transmission encoded (converted to an array of bytes (byte stream))
String name = request.getParameter("uname") ;
byte[] b = name.getBytes("ISO8859-1") ;
name = new String(b) ;
Both can do the encoding of characters http protocol header of the http protocol in the body of the Chinese character coding (post, get)
Encoding a high success rate: 90%
Feasible but is not available, a lot of characters to be encoded, then encoding excessive
(2) using the built-in object request for dynamic coding
request.setCharacterEncoding("GBK") ;
Direct request in all un-encoded characters are encoded using the getParameter (); acquired already encoded characters
Advantages: small code amount
Cons: http protocol only body in Chinese characters are encoded (post), in the form of Chinese characters do coding (post)
Encoding success rate is not high: 80%
Summary: For most request.setCharacterEncoding can not use () encoding, a small request to use dynamic coding encoded byte stream
Multi-valued requests Scene
A check box corresponding to the plurality of parameter name parameter value
Sending a request, built-in objects Tomcat create request, the parameter name key = uname, parameter value, the parameter name key = inst, the parameter value = tom value = init1 (init1 is an array of strings objects); stored in the request object parameter area
Problem: if the check box is not selected String inst [] = null; output when the rear prone null pointer exception (inst.length)
Solution:
Can be obtained by request where the browser is the client's IP address: Request.getRemoteAddr ();
Server Jump: requester.getRequestDispatcher ( "XXX.jsp");
Response
1. regularly updated
2. Jump Timing (periodically refresh exception)
3. Client jump (redirect) (timing jump exception)
It is equivalent to:
Executing the current page will first jump again
Client belonging to jump, corresponding to re-request (setting control information to the server http protocol, the browser automatically jump)
The figure, the server console will print:
** Before the jump ...
** after the jump ...
to sum up:
resquest role:
1 receives passed parameters, properties
2 dynamic coding
Server 3 Jump requester.getRequestDispatcher ( "XXXX.jsp");
response effect:
A result of the data sent to the browser display (jsp page)
Http protocol header 2 is provided, the browser automatically sends a request to control: a timing of the refresh timing of the jump b
3 client Jump
4 sends a cookie to the user (insecure, accounting for memory)
Introduce the same point jump server and client-side jumps and differences
Same point:
It is to jump from one page to another page, or a component or components
difference:
Syntax different
Response.sendRedirect(“xxx.jsp”);
Request.setRequestDispatcher(“XXX.jsp”).forword(resquest,response);
2 Jump essence different
The browser automatically jump (server just set control information to the http protocol)
Server Jump
3 behind the code is executed
Jump execute client, the server does not perform jumps
4 can transfer the data to the jump page
The client can not, the server can
5 whether to re-transmit parameters
The client can, the server can not
6 whether the browser address bar changes
Client changes, the server does not change
Jump for the normal process server, the client jump for abnormal process
Before introducing the Session would let you talk about Cookie
Cookie
System Cookie (browser client)
把客户端和服务端用户对应的session进行联系，从而使客户端的请求可以找到对应的session，完成对用户身份的验证工作；
作用：封装用户对应的sessionId，以便于用户找到用户对应的session；
key----sessionId value----32位的session标识；
由tomcat自动创建、维护；
用户Cookie（不鼓励使用）
把本应保存在服务端上用户的敏感信息，以cookie的形式保存在客户端；
实例：本地的软件自动保存用户的账户和密码；
创建、获取：
创建 http协议：127.0.0.1：8080/test/cookieDemo01.jsp?name=ZTE&password=ZS
Cookie c1 = new Cookie("name","ZTE") ;// 封装用户的信息
Cookie c2 = new Cookie("password","ZS") ;
// 保存在本地，时间为60秒
c1.setMaxAge(60) ;
c2.setMaxAge(60) ;
// 通过response对象将Cookie设置到客户端
response.addCookie(c1) ;
response.addCookie(c2) ;
创建过程：
把用户名和密码设到cookie里（cookie的数据结构是特殊的map，只能封装一个对键值对，有多少个用户信息就有多少个cookie）；在请求结束时，通过response把c1，c2所指的封装了用户名密码的cookie对象放在http协议头回传给浏览器所在的客户端（用户并不知道）；（原则上cookie可以无时间限制的存放在客户端的硬件上，为了减少cookie的存放时间，可以设置cookie的存放时间setMaxAge；）
获取：
// 通过request对象，取得客户端设置的全部Cookie
// 实际上客户端的Cookie是通过HTTP头信息发送到服务器端上的
Cookie[] c = request.getCookies() ;
for(int i=0;i<c.length;i++) //若没有取得Cookies就会产生空指针异常
{
Cookie temp = c[i] ;
<h1><%=temp.getName()%> <%=temp.getValue()%></h1>
}
上面展示的JSESSIONID 89*****是系统Cookie，而下面的则是用户Cookie
获取过程：
通过request取得该用户相关的所有cookie，放到cookie数组对象；
循环获取cookie数组里的每个key和value；
Session
作用：保存用户的各种信息
什么时候创建：用户第一次发送请求访问服务器的动态主键
销毁方式：
1.关闭浏览器后15分钟;2.人为释放掉;3.后台强行关闭;4.在配置文件中设置
例：sessionNew.jsp
执行过程：
重启tomcat ，第一次发送请求，tomcat创建request内置对象，将IP地址和参数，cookie（现在没有）存放到request内置对象中，通过目录名找到SessionNew.jsp，执行isNew()方法先到request内置对象去找系统cookie，没有系统cookie,则认为没有对应的session,返回true,tomcat为用户创建新的session，从新的session里调用getId()拿到sessionID,然后创建一个系统cookie对象，将32位的sessionId作为value,请求结束后，通过response内置对象将系统cookie发送到客户端
第二次发送请求
......执行isNew()，到request内置对象去找系统cookie，存在系统cookie，通过getID()拿到对应的sessionid,在系统session中通过sessionid找到对应的session，返回false，则认为是旧的session(旧用户)
Session和Cookie
| Session |
Cookie |
| 存放用户的验证信息 |
存放用户的敏感信息 |
| 存放在服务端 |
存放在客户端 |
| 用法： 在系统cookie里获取sessionId找到服务端相应的session完整用户的验证 |
用法： 通过request拿到用户cookie和系统cookie，并在请求完通过response再传回浏览器 |
| 需要通过cookie才能找到session |
|
Application
Class MyClass Implements ServletContext
MyClass 是实现ServletContext的类；而ServletContext application=new MyClass();getServletContext()方法取得一个实现ServletContext接口类的对象；
举例：得到工作目录的真实路径：
public String getRealPath(String path)
需要一个参数：/
在实际应用中往往使用getServletContext()方法代替application
<h1><%=getServletContext().getRealPath("/")%></h1>
实现原理：
请求：http://127.0.0.1：8080/test/base/07/Hello.jsp
1 String currentURL = request.getRequestURL();
currentURL = /test/base/07/Hello.jsp
2 Int endURL = currentURL.indexOf(“/”,1);
String targetURL = currentURL.substring(0,endURL);
targetURL = /test
3 在server.xml文件中通过path=”/test” 取得docBase=”f:\test\Web”/>
<Context path=”/test” docBase=”f:\test\Web”/>
Config
作用：存放、传递组件在web.xml中配置信息的初始化参数；
创建：tomcat启动；销毁：tomcat关闭
二异性：
一个servlet-name对应了两个jsp-file，就会出错
<servlet>
<servlet-name>zte</servlet-name>
<jsp-file>/WEB-INF/sdemo.jsp</jsp-file>
</servlet>
<servlet>
<servlet-name>zte</servlet-name>
<jsp-file>/WEB-INF/hello.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>zte</servlet-name>
<url-pattern>/a4</url-pattern>
</servlet-mapping>
tomcat一启动，就会先创建一个config对象（时间比application还要早），有的话就把组件的初始化参数就封装到config内置对象里，并指明是哪个组件的初始化参数
初始化参数：
设置<init-param>的param-name和parameter-value
<servlet>
<servlet-name>zte</servlet-name>
<jsp-file>/WEB-INF/sdemo.jsp</jsp-file>
<init-param>
<param-name>uname</param-name>
<param-value>zs</param-value>
</init-param>
<init-param>
<param-name>upass</param-name>
<param-value>zhangsan</param-value>
</init-param>
</servlet>从config里获取初始化参数：
要在web.xml里面配置初始化参数（见上图）；
只能取得该组件的初始化参数；
<h1><%=config.getInitParameter("uname")%></h1>
<h1><%=config.getInitParameter("upass")%></h1>
Out内置对象
作用：动态向客户端输出数据；（尽量少用）
缺点：
不符合MVC设计模式；不安全；
