发表于： 2018-06-10 23:24:54
1 881
一、今天完成的事情：
乱码问题：起初利用ajax序列化提交中文乱码，显示为？？ 于是尝试用表单直接提交数据依旧是？？ 数据传输到控制台显示正常，那么问题就是出在将数据插入数据库这一步
问题解决：在配置文件db.properties中
jdbc.url=jdbc:mysql://localhost:3306/learn?useSSL=false&characterEncoding=UTF-8将上面&改为&&后，中文乱码解决
尝试在applicationContext.xml中不引用数据源变量：
<property name="url" value="jdbc.url=jdbc:mysql://localhost:3306/learn?useSSL=false&characterEncoding=UTF-8"/>发现也不会出现中文乱码
总结： 在properties和xml中，两种配置文件格式有差别
xml中要使用&
properties中要使用&&
学习深度思考中的内容：
7.Spring MVC和Struts的区别是什么，为什么更倾向于使用Spring MVC？
SpringMvc和Struts2进行各方面的比较:
1.核心控制器（前端控制器、预处理控制器）：spring mvc核心控制器是Servlet，而Struts2是 Filter。
2.控制器实例：Spring Mvc会比Struts快一些（理论上）。Spring Mvc是基于方法设计，而Sturts是基于对象，每次发一次请求都会实例一个action，每个action都会被注入属性，而Spring更像Servlet一样，只有一个实例，每次请求执行对应的方法即可。
3.管理方式：大部分的公司的核心架构中，就会使用到spring,而spring mvc又是spring中的一个模块，所以spring对于spring mvc的控制器管理更加简单方便，而且提供了全 注解方式进行管理，各种功能的注解都比较全面，使用简单，而struts2需要采用XML很多的配置参数来管理。
4.参数传递：Struts2中自身提供多种参数接受，其实都是通过（ValueStack）进行传递和赋值，而SpringMvc是通过方法的参数进行接收。
5.学习难度：Struts更加很多新的技术点，比如拦截器、值栈及OGNL表达式，学习成本较高，springmvc 比较简单，很较少的时间都能上手。
6.intercepter的实现机制：struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得论使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上spring3 mvc就容易实现restful url。struts2是类级别的拦截，一个类对应一个request上下文；实现restful url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。spring3 mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间 也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。
7.spring mvc处理ajax请求,直接通过返回数据，方法中使用注解@ResponseBody，spring mvc自动帮我们对象转换为JSON数据。
https://blog.csdn.net/dove_knowledge/article/details/53354491
8.web.xml里的主要配置都包括什么，都代表什么含义，比如怎么加载Spring 配置的？
web.xml文件是Java web项目中的一个配置文件，主要用于配置欢迎页、Filter、Listener、Servlet等，但并不是必须的，一个java web项目没有web.xml文件照样能跑起来。
web.xml文件加载顺序为：(与xml中的书写顺序无关)
ServletContext -> context-param -> listener -> filter -> servlet
具体的各个标签：https://segmentfault.com/a/1190000011404088
9.Annotation和XML两种配置的差别，为什么更喜欢使用Annotaion来配置Spring MVC？
注解与XML配置的区别
注解：是一种分散式的元数据，与源代码紧绑定。
xml：是一种集中式的元数据，与源代码无绑定。
因此注解和XML的选择上可以从两个角度来看：分散还是集中，源代码绑定/无绑定。
注解的缺点：
1、很多朋友比如在使用spring注解时，会发现注解分散到很多类中，不好管理和维护；这个其实要借助工具，我目前使用的是IDEA，它在这方面表现的非常好；当然现在还有Spring的STS，也是不错的； 所以借助工具，能解决这个问题；
2、注解的开启/关闭必须修改源代码，因为注解是源代码绑定的，如果要修改，需要改源码，这个有这个问题，所以如果是这种情况，还是使用XML配置方式；比如数据源；
3、注解还一个缺点就是灵活性，比如在之前翻译的Spring Framework 4.0 M1: WebSocket 支持；在实现复杂的逻辑上，没有XML来的更加强大；注解就是要么用，要么不用，比如之前的jpa bean validation，要么全，要么没；遇到这种情况很痛苦；
4、还一种就是约定大于配置，但是在处理一些复杂的情况下，注解还是需要的（如Spring的数据验证/数据绑定注解很强大）；
5、通用配置还是走XML吧，比如事务配置，比如数据库连接池等等，即通用的配置集中化，而不是分散化，如很多人使用@Transactional来配置事务，在很多情况下这是一种太分散化的配置；
6、XML方式比注解的可扩展性和复杂性维护上好的多，比如需要哪些组件，不需要哪些；在面对这种情况，注解扫描机制比较逊色，因为规则很难去写或根本不可能写出来；
注解的好处：
1、XML配置起来有时候冗长，此时注解可能是更好的选择，如jpa的实体映射；注解在处理一些不变的元数据时有时候比XML方便的多，比如springmvc的数据绑定，如果用xml写的代码会多的多；
2、注解最大的好处就是简化了XML配置；其实大部分注解一定确定后很少会改变，所以在一些中小项目中使用注解反而提供了开发效率，所以没必要一头走到黑；
3、注解相对于XML的另一个好处是类型安全的，XML只能在运行期才能发现问题。
注解也好，XML也好，我们还是需要一些开关/替换机制来控制特殊需求，以改变那种要么全部 要么没有的方案。。
还一种呼声就是约定大于配置，这种方案可能在某些场景下是最优的，但是遇到一些复杂的情况可能并不能解决问题，所以此时注解也是一个不错的方案。尤其在使用springmvc时，好处是能体会的出的。
不管使用注解还是XML，做的事情还是那些事情，但注解和XML都不是万能的，满足自己的需求且已一种更简单的方式解决掉问题即可。
就像探讨一下技术问题，很多人都带有很强的个人喜好来评判一个东西的好坏，这种探讨没有任何意义，我们最终的目的是解决方案，所以我们应该探讨的是能不能解决问题，能不能以更容易理解的方式解决问题，能不能更简单的解决问题。
不管是约定大于配置、注解还是XML配置也好，没有哪个是最优的，在合适的场景选择合适的解决方案这才是重要的。就像设计模式一样：是对特定环境中重复出现的特定问题的一个经过前人验证了的解决方案。
10.使用Annotaion的时候需要有哪些配置，他的加载过程是怎么样的？
在spring中，每使用一个注解就要声明一个bean
比如 ：使用@Autowired注解，必须事先在Spring容器中声明AutowiredAnnotationBeanPostProcessor的Bean：
使用 @Required注解，就必须声明RequiredAnnotationBeanPostProcessor的Bean：
类似地，使用@Resource、@PostConstruct、@PreDestroy等注解就必须声明 CommonAnnotationBeanPostProcessor；使用@PersistenceContext注解，就必须声明 PersistenceAnnotationBeanPostProcessor的Bean。
样的声明未免太不优雅，所以Spring为我们提供了一种极为方便注册这些BeanPostProcessor的方式，即使用context:annotation- config标签，隐式地向 Spring容器注册各种bean
另外，在我们使用注解时一般都会配置扫描包路径选项：context:component-scan base-package=”pack.pack”/
该配置项其实也包含了自动注入上述processor的功能，因此当使用context:component-scan后，即可将context:annotation-config标签省去。
@autowired注解是如何加载的？自动注入是怎样实现的？？
@autowired是通过动态代理和反射，在类加载过程中动态生成代理类，当初始化全局变量时，代理类跳到invoke方法，然后通过反射获取field字段对象，在method.invoke()的调用前即可实现注入。aop和拦截器以及常用注解等功能的实现都是基于动态代理实现的。
11.什么是Filter，什么是Interceptor,他们的区别是什么，和AOP又是什么关系？
Java中常见的AOP技术有两个，分别是Filter和代理模式（也可以称为过滤器和拦截器），Filter是基于回调函数，代理模式是基于Java反射技术，代理模式又分为静态代理和动态代理，动态代理就是拦截器的简单实现。
WEB 开发人员通过 Filter 技术，对 web 服务器管理的所有 web 资源：例如 JSP、Servlet,、静态图片文件或静态 HTML 文件等进行拦截，从而实现一些特殊的功能。例如实现 URL 级别的权限访问控制、过滤敏感词汇、压缩响应信息等一些高级功能。
无论程序从左向右或者从右向左执行都必须经过Filter，Filter在Request到达JSP（Servlet）前截获Request并进行预处理，也可以在Response离开JSP（Servlet）时处理Response，然后对Request进行统一的设置后继续向后传递，比如可以在Filter完成字符集的设置，用户身份的识别，敏感词汇的过滤等等，配置Filter个数不限。
Java 里的拦截器是动态拦截 action 调用的对象。它提供了一种机制可以使开发者可以定义在一个 action 执行的前后执行的代码，也可以在一个 action 执行前阻止其执行，同时也提供了一种可以提取 action 中可重用部分的方式。在AOP（Aspect-Oriented Programming，面向切面编程）中拦截器用于在某个方法或字段被访问之前进行拦截，然后在之前或之后加入某些操作。拦截器 Interceptor 的拦截功能是基于 Java 的动态代理来实现的。
12.生成Json有几种方式，他们之间的好处和坏处分别是什么，为什么推荐使用JsonTaglib来处理Json？
json的生成方式：
1、第一种方式是spring2时代的产物，也就是每个json视图controller配置一个Jsoniew。
2、第二种使用JSON工具将对象序列化成json，常用工具Jackson，fastjson，gson。
3、第三种利用spring mvc3的注解@ResponseBody。
4、利用JsonTaglib从JSP中提取json
1.使用json-taglib,在控制器中的代码更加简洁,易读
2.使用json-taglib更加灵活,如果以后需要更改json数据格式,只需要更改jsp页面即可,不需要改动控制器代码
13.一份规范的接口文档应该包括什么内容，衡量接口（API）设计好和坏的准则是什么？
需要包括请求方法、uri、请求参数、返回参数、添加接口示例、接口文档版本号、版本修改内容、版本修改时间、修改人，错误代码等。
接口分为四部分：方法、uri、请求参数、返回参数：
1）方法：常用的方法就是下面的四种：GET PUT POST DELETE
2）uri：以/a开头，如果需要登录才能调用的接口（如新增、修改；前台的用户个人信息，资金信息等）后面需要加/u，即：/a/u；中间一般放表名或者能表达这个接口的单词。get方法，若果是后台通过搜索查询列表，那么以/search结尾，如果是前台的查询列表，以/list结尾。uri地址里不逊于出现大写字母，如果是两个单词拼接，用/分开
3）请求参数和返回参数：请求参数和返回参数都分为：字段、说明、类型、备注、是否必填这5列。
14.Http的Header里面包含哪些字段，每个字段都有哪些含义？
请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息
从第二行起为请求头部，HOST将指出请求的目的地.User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等。
http header 消息通常被分为4个部分：general header, request header, response header, entity header。但是这种分法就理解而言，感觉界限不太明确。根据维基百科对http header内容的组织形式，大体分为Request和Response两部分。
Requests部分
Header解释示例
Accept指定客户端能够接收的内容类型Accept: text/plain, text/html
Accept-Charset浏览器可以接受的字符编码集。Accept-Charset: iso-8859-5
Accept-Encoding指定浏览器可以支持的web服务器返回内容压缩编码类型。Accept-Encoding: compress, gzip
Accept-Language浏览器可接受的语言Accept-Language: en,zh
Accept-Ranges可以请求网页实体的一个或者多个子范围字段Accept-Ranges: bytes
AuthorizationHTTP授权的授权证书Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control指定请求和响应遵循的缓存机制Cache-Control: no-cache
Connection表示是否需要持久连接。（HTTP 1.1默认进行持久连接）Connection: close
CookieHTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。Cookie: $Version=1; Skin=new;
Content-Length请求的内容长度Content-Length: 348
Content-Type请求的与实体对应的MIME信息Content-Type: application/x-www-form-urlencoded
Date请求发送的日期和时间Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect请求的特定的服务器行为Expect: 100-continue
From发出请求的用户的EmailFrom: user@email.com
Host指定请求的服务器的域名和端口号Host: www.zcmhi.com
If-Match只有请求内容与实体相匹配才有效If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为EtagIf-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since只在实体在指定时间之后未被修改才请求成功If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards限制信息通过代理和网关传送的时间Max-Forwards: 10
Pragma用来包含实现特定的指令Pragma: no-cache
Proxy-Authorization连接到代理的授权证书Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range只请求实体的一部分，指定范围Range: bytes=500-999
Referer先前网页的地址，当前请求网页紧随其后,即来路Referer: http://www.zcmhi.com/archives/71.html
TE客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息TE: trailers,deflate;q=0.5
Upgrade向服务器指定某种传输协议以便服务器进行转换（如果支持）Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-AgentUser-Agent的内容包含发出请求的用户信息User-Agent: Mozilla/5.0 (Linux; X11)
Via通知中间网关或代理服务器地址，通信协议Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning关于消息实体的警告信息Warn: 199 Miscellaneous warning
Responses 部分
Header解释示例
Accept-Ranges表明服务器是否支持指定范围请求及哪种类型的分段请求Accept-Ranges: bytes
Age从原始服务器到代理缓存形成的估算时间（以秒计，非负）Age: 12
Allow对某网络资源的有效的请求行为，不允许则返回405Allow: GET, HEAD
Cache-Control告诉所有的缓存机制是否可以缓存及哪种类型Cache-Control: no-cache
Content-Encodingweb服务器支持的返回内容压缩编码类型。Content-Encoding: gzip
Content-Language响应体的语言Content-Language: en,zh
Content-Length响应体的长度Content-Length: 348
Content-Location请求资源可替代的备用的另一地址Content-Location: /index.htm
Content-MD5返回资源的MD5校验值Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range在整个返回体中本部分的字节位置Content-Range: bytes 21010-47021/47022
Content-Type返回内容的MIME类型Content-Type: text/html; charset=utf-8
Date原始服务器消息发出的时间Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag请求变量的实体标签的当前值ETag: “737060cd8c284d8af7ad3082f209582d”
Expires响应过期的日期和时间Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified请求资源的最后修改时间Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location用来重定向接收方到非请求URL的位置来完成请求或标识新的资源Location: http://www.zcmhi.com/archives/94.html
Pragma包括实现特定的指令，它可应用到响应链上的任何接收方Pragma: no-cache
Proxy-Authenticate它指出认证方案和可应用到代理的该URL上的参数Proxy-Authenticate: Basic
refresh应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）Refresh: 5; url=
http://www.zcmhi.com/archives/94.html
Retry-After如果实体暂时不可取，通知客户端在指定时间之后再次尝试Retry-After: 120
Serverweb服务器软件名称Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie设置Http CookieSet-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer指出头域在分块传输编码的尾部存在Trailer: Max-Forwards
Transfer-Encoding文件传输编码Transfer-Encoding:chunked
Vary告诉下游代理是使用缓存响应还是从原始服务器请求Vary: *
Via告知代理客户端响应是通过哪里发送的Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning警告实体可能存在的问题Warning: 199 Miscellaneous warning
WWW-Authenticate表明客户端请求实体应该使用的授权方案WWW-Authenticate: Basic
二、明日计划
学习深度思考，postman
三、收获与问题
梳理了web开发中的知识
返回列表
评论