乒乓狂魔
- 浏览: 237991 次
- 性别:
- 来自: 上海
-
文章分类
最新评论
-
shuhucy：
必须赞啊，源码理解的很深，解决一个困扰两天的问题
Spring AOP源码分析（八）SpringAOP要注意的地方 -
sealinesu：
精彩
Spring事务源码分析（一）Spring事务入门 -
whlt20090509：
"WEB-INF/view目录下有一个简单的hell ...
SpringMVC源码总结（一）HandlerMapping和HandlerAdapter入门 -
hai0378：
兄台 算我一个，最近在研究dubbo motan 及 zk ...
ZooKeeper源码研究寻求小伙伴 -
zpkbtzmbw：
看懂了，原理
SpringMVC源码总结（五）Tomcat的URIEncoding、useBodyEncodingForURI和CharacterEncodingFilter
SpringMVC源码总结（五）Tomcat的URIEncoding、useBodyEncodingForURI和CharacterEncodingFilter
- 博客分类：
- SpringMVC源码分析
- 乱码
继续上一章节的乱码问题。上一篇文章仅仅说了设置Tomcat的URIEncoding可以解决乱码问题，这篇文章便会讲述这一背后的内容。首先说明下，光看是没用的，要多实验实验。
目前我的tomcat版本为：7.0.55，spring所有文章的版本始终为4.0.5
本文章会从tomcat的源码角度来解析Tomcat的两个参数设置URIEncoding和useBodyEncodingForURI。
对于一个请求，常用的有两种编码方式，如下：
首先说说结论：
上述请求有两处含有中文，一处是请求参数中，即？name='中国'，另一处是请求体中，即user='张三'。对于这两处tomcat7是分两种编码方式的。URIEncoding就是针对请求参数的编码设置的，而filter的request.setCharacterEncoding('UTF-8')或者请求header中的content-type中的编码都是针对请求体的。不要把他们搞混了。
useBodyEncodingForURI=true是说，请求参数的编码方式要采用请求体的编码方式。当useBodyEncodingForURI=true时，若请求体采用utf-8解析，则请求参数也要采用utf-8来解析。这两个属性值的设置在tomcat的conf/server.xml文件中配置，如下：
这样写只是说明这两者的配置位置，并不是两个属性要同时配置，不要理解错了。
继续说说CharacterEncodingFilter的作用。
使用方式，将如下代码加入web.xml文件中：
作用是，当forceEncoding为false的前提下（默认为false），当request没有指定content-type或content-type不含编码时，该filter将会为这个request设定请求体的编码为filter的encoding值。
当forceEncoding为true的前提下，就会为request的请求体和response都设定为这个filter的encoding值。
CharacterEncodingFilter源码如下：
这个filter有两个属性,encoding和forceEncoding，我们可以在web.xml文件中来设定这两个属性值。
每次request请求到来执行方法doFilterInternal，首先调用request.getCharacterEncoding()，本质就是从请求header content-type中获取编码值，如果没有，则调用request.setCharacterEncoding(this.encoding)将该filter的encoding值设置为请求体的编码方式，记住该编码方式只对请求体，不针对请求参数。当forceEncoding=true时，不管请求header content-type有没有编码方式，始终将该filter的encoding值设置到request和response中，同样只针对request的请求体。
以上的结论说完了，下面就要看看源代码了。不想看的就算了不影响使用，想看看原理的请继续：
首先是三个名词：
org.apache.coyote.Request：这是一个最底层的request，包含各种参数信息。暂且称为coyoteRequest。
org.apache.catalina.connector.Request：实现了HttpServletRequest接口，称它为request，同时包含了一个coyoteRequest，一个connector,待会你就会发现这个connector的编码传递作用。
org.apache.catalina.connector.RequestFacade：同样实现了HttpServletRequest接口，它仅仅是一个装饰类，称它为requestFacade，构造函数为：
该构造函数将一个org.apache.catalina.connector.Request传进来，requestFacade的工作全是靠它内部的org.apache.catalina.connector.Request来完成的，org.apache.catalina.connector.Request又是依据它所包含的org.apache.coyote.Request这个最底层的类来完成的。通过org.apache.catalina.connector.Request，我们可以设定org.apache.coyote.Request的一些工作方式，如通过什么编码来解析数据。
org.apache.coyote.Request含有的属性：
String charEncoding：针对请求体的编码(在第一次解析参数时会传递给Parameters的encoding)
Parameters ：用于处理和存放请求参数和请求体参数的类
（1）含String encoding：针对请求体的编码
（2）含String queryStringEncoding：针对请求参数的编码
（3）含Map<String,ArrayList<String>> paramHashValues：存放解析后的参数
Parameters的两个编码是最最重要的编码，直接参与解析数据的编码，不像其他对象的编码大部分都是起传递作用，最终作用到Parameters的两个编码上
传给过滤器filter的HttpServletRequest request其实是org.apache.catalina.connector.RequestFacade类型的，我们看下获取参数的具体过程：
requestFacade.getParameter("user")会传递到org.apache.catalina.connector.Request的相应方法，如下：
parametersParsed是org.apache.catalina.connector.Request的属性，用于标示是否已经解析过参数，如果解析过，便不再解析，直接从coyoteRequest的Parameters参数中取出。所以当已经解析过后，你再去设置编码，会无效的，因为它会直接返回第一次的解析结果。并且解析过程仅仅发生在第一次获取参数的时候。
我们来看下parseParameters()这个解析参数的过程：
上面有四处我们需要关注的重点。
重点1：getCharacterEncoding()其实是通过底层的coyoteRequest来获取header content-type中的编码。
如下：
若无，则返回空。
重点2：
boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();这里就是我们在tomcat的server中配置的useBodyEncodingForURI属性的值。
常量值org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING="ISO-8859-1"；
当重点1中的enc为空时，则会设置底层coyoteRequest的parameters对象的encoding=s上述"ISO-8859-1"，即请求体采用"ISO-8859-1"来解析。当useBodyEncodingForURI=true时，请求参数和请求体的编码设置的都是同一个值，即"ISO-8859-1"。当useBodyEncodingForURI=false时，不改变queryStringEncoding即请求参数的编码，queryStringEncoding默认是为null的，当解析时碰见queryStringEncoding也会采用默认的编码"ISO-8859-1"，然而我们可以通过org.apache.catalina.connector.Request所包含的connector配置来给queryStringEncoding赋值。如下：
当你在tomcat的server.xml文件中加入URIEncoding="UTF-8"时，它将会为queryStringEncoding赋值此值。
在tomcat的server.xml中配置此值
connector将这个值为queryStringEncoding赋值的过程如下：
connector.getURIEncoding()便是我们配置的URIEncoding值
req.getParameters().setQueryStringEncoding
(connector.getURIEncoding());
这句代码便是将我们在tomcat的server.xml文件中配置的URIEncoding值设置进最重要的Parameters的queryStringEncoding中。
当重点1中的enc不为空时,为Parameters请求体的的编码encoding设置为enc。
至此，Parameters的encoding和queryStringEncoding都有相应的值了，然后便按照对应的编码来解析字节数组。
重点3和4：有个相应的编码方式，分别执行请求参数的解析过程和请求体的解析过程。
总结下一些设置的作用：
request.setCharacterEncoding(encoding) ：暴漏给我们的request为requestFacade，最终调用request->调用coyoteRequest->设置到coyoteRequest的charEncoding，所以coyoteRequest的charEncoding有两种来源，一种可能是content-type中的编码，另一种就是调用request.setCharacterEncoding(encoding) 方法。此方法最好在第一次解析参数之前调用，不然就无效。
URIEncoding：直接设置Parameters的queryStringEncoding的值。即针对请求参数的编码。
useBodyEncodingForURI：设置queryStringEncoding的值=encoding的值，即请求参数采用请求体的编码方式。
目前我的tomcat版本为：7.0.55，spring所有文章的版本始终为4.0.5
本文章会从tomcat的源码角度来解析Tomcat的两个参数设置URIEncoding和useBodyEncodingForURI。
对于一个请求，常用的有两种编码方式，如下：
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title></title> </head> <body> <form action="http://127.0.0.1:8080/string?name=中国" method="post"> <input type="text" name="user" value="张三"/> <input type="submit" value="提交"/> </form> </body> </html>
首先说说结论：
上述请求有两处含有中文，一处是请求参数中，即？name='中国'，另一处是请求体中，即user='张三'。对于这两处tomcat7是分两种编码方式的。URIEncoding就是针对请求参数的编码设置的，而filter的request.setCharacterEncoding('UTF-8')或者请求header中的content-type中的编码都是针对请求体的。不要把他们搞混了。
useBodyEncodingForURI=true是说，请求参数的编码方式要采用请求体的编码方式。当useBodyEncodingForURI=true时，若请求体采用utf-8解析，则请求参数也要采用utf-8来解析。这两个属性值的设置在tomcat的conf/server.xml文件中配置，如下：
<Service name="Catalina">
<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" useBodyEncodingForURI='true' URIEncoding='UTF-8' />
<!-- A "Connector" using the shared thread pool-->
这样写只是说明这两者的配置位置，并不是两个属性要同时配置，不要理解错了。
继续说说CharacterEncodingFilter的作用。
使用方式，将如下代码加入web.xml文件中：
<filter> <filter-name>encoding</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encoding</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
作用是，当forceEncoding为false的前提下（默认为false），当request没有指定content-type或content-type不含编码时，该filter将会为这个request设定请求体的编码为filter的encoding值。
当forceEncoding为true的前提下，就会为request的请求体和response都设定为这个filter的encoding值。
CharacterEncodingFilter源码如下：
public class CharacterEncodingFilter extends OncePerRequestFilter {
private String encoding;
private boolean forceEncoding = false;
/**
* Set the encoding to use for requests. This encoding will be passed into a
* {@link javax.servlet.http.HttpServletRequest#setCharacterEncoding} call.
* <p>Whether this encoding will override existing request encodings
* (and whether it will be applied as default response encoding as well)
* depends on the {@link #setForceEncoding "forceEncoding"} flag.
*/
public void setEncoding(String encoding) {
this.encoding = encoding;
}
/**
* Set whether the configured {@link #setEncoding encoding} of this filter
* is supposed to override existing request and response encodings.
* <p>Default is "false", i.e. do not modify the encoding if
* {@link javax.servlet.http.HttpServletRequest#getCharacterEncoding()}
* returns a non-null value. Switch this to "true" to enforce the specified
* encoding in any case, applying it as default response encoding as well.
* <p>Note that the response encoding will only be set on Servlet 2.4+
* containers, since Servlet 2.3 did not provide a facility for setting
* a default response encoding.
*/
public void setForceEncoding(boolean forceEncoding) {
this.forceEncoding = forceEncoding;
}
@Override
protected void doFilterInternal(
HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
throws ServletException, IOException {
if (this.encoding != null && (this.forceEncoding || request.getCharacterEncoding() == null)) {
request.setCharacterEncoding(this.encoding);
if (this.forceEncoding) {
response.setCharacterEncoding(this.encoding);
}
}
filterChain.doFilter(request, response);
}
}
这个filter有两个属性,encoding和forceEncoding，我们可以在web.xml文件中来设定这两个属性值。
每次request请求到来执行方法doFilterInternal，首先调用request.getCharacterEncoding()，本质就是从请求header content-type中获取编码值，如果没有，则调用request.setCharacterEncoding(this.encoding)将该filter的encoding值设置为请求体的编码方式，记住该编码方式只对请求体，不针对请求参数。当forceEncoding=true时，不管请求header content-type有没有编码方式，始终将该filter的encoding值设置到request和response中，同样只针对request的请求体。
以上的结论说完了，下面就要看看源代码了。不想看的就算了不影响使用，想看看原理的请继续：
首先是三个名词：
org.apache.coyote.Request：这是一个最底层的request，包含各种参数信息。暂且称为coyoteRequest。
org.apache.catalina.connector.Request：实现了HttpServletRequest接口，称它为request，同时包含了一个coyoteRequest，一个connector,待会你就会发现这个connector的编码传递作用。
org.apache.catalina.connector.RequestFacade：同样实现了HttpServletRequest接口，它仅仅是一个装饰类，称它为requestFacade，构造函数为：
/**
* Construct a wrapper for the specified request.
*
* @param request The request to be wrapped
*/
public RequestFacade(Request request) {
this.request = request;
}
该构造函数将一个org.apache.catalina.connector.Request传进来，requestFacade的工作全是靠它内部的org.apache.catalina.connector.Request来完成的，org.apache.catalina.connector.Request又是依据它所包含的org.apache.coyote.Request这个最底层的类来完成的。通过org.apache.catalina.connector.Request，我们可以设定org.apache.coyote.Request的一些工作方式，如通过什么编码来解析数据。
org.apache.coyote.Request含有的属性：
String charEncoding：针对请求体的编码(在第一次解析参数时会传递给Parameters的encoding)
Parameters ：用于处理和存放请求参数和请求体参数的类
（1）含String encoding：针对请求体的编码
（2）含String queryStringEncoding：针对请求参数的编码
（3）含Map<String,ArrayList<String>> paramHashValues：存放解析后的参数
Parameters的两个编码是最最重要的编码，直接参与解析数据的编码，不像其他对象的编码大部分都是起传递作用，最终作用到Parameters的两个编码上
public class MyCharacterEncodingFilter extends CharacterEncodingFilter{
@Override
protected void doFilterInternal(HttpServletRequest request,
HttpServletResponse response, FilterChain filterChain)
throws ServletException, IOException {
request.setCharacterEncoding("UTF-8");
String name=request.getParameter("user");
System.out.println(name);
request.setCharacterEncoding("UTF-8");
String name1=request.getParameter("user");
System.out.println(name1);
super.doFilterInternal(request, response, filterChain);
}
}
传给过滤器filter的HttpServletRequest request其实是org.apache.catalina.connector.RequestFacade类型的，我们看下获取参数的具体过程：
requestFacade.getParameter("user")会传递到org.apache.catalina.connector.Request的相应方法，如下：
public String getParameter(String name) {
if (!parametersParsed) {
parseParameters();
}
return coyoteRequest.getParameters().getParameter(name);
}
parametersParsed是org.apache.catalina.connector.Request的属性，用于标示是否已经解析过参数，如果解析过，便不再解析，直接从coyoteRequest的Parameters参数中取出。所以当已经解析过后，你再去设置编码，会无效的，因为它会直接返回第一次的解析结果。并且解析过程仅仅发生在第一次获取参数的时候。
我们来看下parseParameters()这个解析参数的过程：
/**
* Parse request parameters.
*/
protected void parseParameters() {
//解析发生后，便将是状态置为已解析
parametersParsed = true;
Parameters parameters = coyoteRequest.getParameters();
boolean success = false;
try {
// Set this every time in case limit has been changed via JMX
parameters.setLimit(getConnector().getMaxParameterCount());
// getCharacterEncoding() may have been overridden to search for
// hidden form field containing request encoding
//重点1
String enc = getCharacterEncoding();
//重点2
boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();
if (enc != null) {
parameters.setEncoding(enc);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding(enc);
}
} else {
parameters.setEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
}
}
//重点3
parameters.handleQueryParameters();
if (usingInputStream || usingReader) {
success = true;
return;
}
if( !getConnector().isParseBodyMethod(getMethod()) ) {
success = true;
return;
}
String contentType = getContentType();
if (contentType == null) {
contentType = "";
}
int semicolon = contentType.indexOf(';');
if (semicolon >= 0) {
contentType = contentType.substring(0, semicolon).trim();
} else {
contentType = contentType.trim();
}
if ("multipart/form-data".equals(contentType)) {
parseParts();
success = true;
return;
}
if (!("application/x-www-form-urlencoded".equals(contentType))) {
success = true;
return;
}
int len = getContentLength();
if (len > 0) {
int maxPostSize = connector.getMaxPostSize();
if ((maxPostSize > 0) && (len > maxPostSize)) {
if (context.getLogger().isDebugEnabled()) {
context.getLogger().debug(
sm.getString("coyoteRequest.postTooLarge"));
}
checkSwallowInput();
return;
}
byte[] formData = null;
if (len < CACHED_POST_LEN) {
if (postData == null) {
postData = new byte[CACHED_POST_LEN];
}
formData = postData;
} else {
formData = new byte[len];
}
try {
if (readPostBody(formData, len) != len) {
return;
}
} catch (IOException e) {
// Client disconnect
if (context.getLogger().isDebugEnabled()) {
context.getLogger().debug(
sm.getString("coyoteRequest.parseParameters"), e);
}
return;
}
//重点4
parameters.processParameters(formData, 0, len);
} else if ("chunked".equalsIgnoreCase(
coyoteRequest.getHeader("transfer-encoding"))) {
byte[] formData = null;
try {
formData = readChunkedPostBody();
} catch (IOException e) {
// Client disconnect or chunkedPostTooLarge error
if (context.getLogger().isDebugEnabled()) {
context.getLogger().debug(
sm.getString("coyoteRequest.parseParameters"), e);
}
return;
}
if (formData != null) {
parameters.processParameters(formData, 0, formData.length);
}
}
success = true;
} finally {
if (!success) {
parameters.setParseFailed(true);
}
}
}
上面有四处我们需要关注的重点。
重点1：getCharacterEncoding()其实是通过底层的coyoteRequest来获取header content-type中的编码。
如下：
/**
* Return the character encoding for this Request.
*/
@Override
public String getCharacterEncoding() {
return coyoteRequest.getCharacterEncoding();
}
public String getCharacterEncoding() {
if (charEncoding != null)
return charEncoding;
charEncoding = ContentType.getCharsetFromContentType(getContentType());
return charEncoding;
}
若无，则返回空。
重点2：
boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();这里就是我们在tomcat的server中配置的useBodyEncodingForURI属性的值。
常量值org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING="ISO-8859-1"；
当重点1中的enc为空时，则会设置底层coyoteRequest的parameters对象的encoding=s上述"ISO-8859-1"，即请求体采用"ISO-8859-1"来解析。当useBodyEncodingForURI=true时，请求参数和请求体的编码设置的都是同一个值，即"ISO-8859-1"。当useBodyEncodingForURI=false时，不改变queryStringEncoding即请求参数的编码，queryStringEncoding默认是为null的，当解析时碰见queryStringEncoding也会采用默认的编码"ISO-8859-1"，然而我们可以通过org.apache.catalina.connector.Request所包含的connector配置来给queryStringEncoding赋值。如下：
当你在tomcat的server.xml文件中加入URIEncoding="UTF-8"时，它将会为queryStringEncoding赋值此值。
在tomcat的server.xml中配置此值
<Service name="Catalina">
<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" URIEncoding='UTF-8'/>
connector将这个值为queryStringEncoding赋值的过程如下：
public void log(org.apache.coyote.Request req,
org.apache.coyote.Response res, long time) {
Request request = (Request) req.getNote(ADAPTER_NOTES);
Response response = (Response) res.getNote(ADAPTER_NOTES);
if (request == null) {
// Create objects
request = connector.createRequest();
request.setCoyoteRequest(req);
response = connector.createResponse();
response.setCoyoteResponse(res);
// Link objects
request.setResponse(response);
response.setRequest(request);
// Set as notes
req.setNote(ADAPTER_NOTES, request);
res.setNote(ADAPTER_NOTES, response);
// Set query string encoding
//重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点
req.getParameters().setQueryStringEncoding
(connector.getURIEncoding());
}
connector.getURIEncoding()便是我们配置的URIEncoding值
req.getParameters().setQueryStringEncoding
(connector.getURIEncoding());
这句代码便是将我们在tomcat的server.xml文件中配置的URIEncoding值设置进最重要的Parameters的queryStringEncoding中。
当重点1中的enc不为空时,为Parameters请求体的的编码encoding设置为enc。
至此，Parameters的encoding和queryStringEncoding都有相应的值了，然后便按照对应的编码来解析字节数组。
重点3和4：有个相应的编码方式，分别执行请求参数的解析过程和请求体的解析过程。
总结下一些设置的作用：
request.setCharacterEncoding(encoding) ：暴漏给我们的request为requestFacade，最终调用request->调用coyoteRequest->设置到coyoteRequest的charEncoding，所以coyoteRequest的charEncoding有两种来源，一种可能是content-type中的编码，另一种就是调用request.setCharacterEncoding(encoding) 方法。此方法最好在第一次解析参数之前调用，不然就无效。
URIEncoding：直接设置Parameters的queryStringEncoding的值。即针对请求参数的编码。
useBodyEncodingForURI：设置queryStringEncoding的值=encoding的值，即请求参数采用请求体的编码方式。
分享到：
发表评论
-
SpringMVC源码总结（十二）ViewResolver介绍
2014-09-10 06:43 2285首先我们先看看ModelAndView中重要的View接口。 ... -
SpringMVC源码总结（十一）mvc:interceptors拦截器介绍
2014-09-08 20:21 5819本文章针对mvc:interceptors标签进行介绍，它的注 ... -
SpringMVC源码总结（十）自定义HandlerMethodArgumentResolver
2014-09-04 07:45 7397上一篇文章介绍了HandlerMethodArgumentRe ... -
SpringMVC源码总结（九）HandlerMethodArgumentResolver介绍
2014-09-02 06:24 12435本文章主要介绍HandlerMethodArgumentRes ... -
SpringMVC源码总结（八）类型转换PropertyEditor的背后
2014-08-30 17:13 4888PropertyEditor是Spring最初 ... -
SpringMVC源码总结（七）mvc:annotation-driven中的HttpMessageConverter
2014-08-27 22:32 6616这一篇文章主要介绍下HttpMessageConverter整 ... -
HTTP协议header中Content-Disposition中文文件名乱码
2014-08-25 22:07 15669在做文件下载时，当文件名为中文时，经常会出现乱码现象。 参考文 ... -
SpringMVC源码总结（六）mvc:annotation-driven中的HandlerMethodReturnValueHandler
2014-08-26 06:21 6551经过了两篇的乱码说明，要重新回到mvc:annotation- ... -
SpringMVC源码总结（四）由StringHttpMessageConverter引出的客户端服务器端之间的乱码过程分析
2014-08-20 22:49 3689继续上一篇文章遗留的乱码问题，引出从客户端数据到服务器端的乱码 ... -
SpringMVC源码总结（三）mvc:annotation-driven和mvc:message-converters简单介绍
2014-08-19 06:58 10152上一篇文章讲述了最简单的mvc:annotation-driv ... -
SpringMVC源码总结（二）mvc:annotation-driven以及@Controller和@RequestMapping的那些事
2014-08-16 22:47 8673上一篇文章让我们了解HandlerMapping和Handle ... -
SpringMVC源码总结（一）HandlerMapping和HandlerAdapter入门
2014-08-16 22:42 14721刚接触SpringMVC,对它的xml文件配置一直比较模模糊糊 ...
相关推荐
Spring MVC参数传递中文乱码解决方法分享 在 Web 开发中，参数传递中文乱码问题是一个常见的问题，特别是在使用 Spring MVC 框架时。...这些文章将为您提供更多关于 Spring MVC 框架的知识和经验。
qtz40塔式起重机总体及塔身有限元分析法设计().zip
Elasticsearch是一个基于Lucene的搜索服务器
资源内项目源码是来自个人的毕业设计，代码都测试ok，包含源码、数据集、可视化页面和部署说明，可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源，毕设答辩评审绝对信服的保底85分以上，放心下载使用，拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务，拿来就能用的绝对好资源！！！ 项目备注 1、该资源内项目代码都经过测试运行成功，功能ok的情况下才上传的，请放心下载使用！ 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习，也适合小白学习进阶，当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行，也可在此代码基础上进行修改，以实现其他功能，也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件，仅供学习参考, 切勿用于商业用途。
美国纽约HVAC(暖通空调)数据示例，谷歌地图数据包括：时间戳、名称、类别、地址、描述、开放网站、电话号码、开放时间、更新开放时间、评论计数、评级、主图像、评论、url、纬度、经度、地点id、国家等。 在地理位置服务（LBS）中，谷歌地图数据采集尤其受到关注，因为它提供了关于各种商业实体的详尽信息，这对于消费者和企业都有极大的价值。本篇文章将详细介绍美国纽约地区的HVAC（暖通空调）系统相关数据示例，此示例数据是通过谷歌地图抓取得到的，展示了此技术在商业和消费者领域的应用潜力。 无需外网，无需任何软件抓取谷歌地图数据：wmhuoke.com
2023-04-06-项目笔记-第四百五十五阶段-课前小分享_小分享1.坚持提交gitee 小分享2.作业中提交代码 小分享3.写代码注意代码风格 4.3.1变量的使用 4.4变量的作用域与生命周期 4.4.1局部变量的作用域 4.4.2全局变量的作用域 4.4.2.1全局变量的作用域_1 4.4.2.453局变量的作用域_453- 2025-04-01
1_实验三 扰码、卷积编码及交织.ppt
北京交通大学901软件工程导论必备知识点.pdf
内容概要：本文档总结了 MyBatis 的常见面试题，涵盖了 MyBatis 的基本概念、优缺点、适用场合、SQL 语句编写技巧、分页机制、主键生成、参数传递方式、动态 SQL、缓存机制、关联查询及接口绑定等内容。通过对这些问题的解答，帮助开发者深入理解 MyBatis 的工作原理及其在实际项目中的应用。文档不仅介绍了 MyBatis 的核心功能，还详细解释了其在不同场景下的具体实现方法，如通过 XML 或注解配置 SQL 语句、处理复杂查询、优化性能等。 适合人群：具备一定 Java 开发经验，尤其是对 MyBatis 有初步了解的研发人员，以及希望深入了解 MyBatis 框架原理和最佳实践的开发人员。 使用场景及目标：①理解 MyBatis 的核心概念和工作原理，如 SQL 映射、参数传递、结果映射等；②掌握 MyBatis 在实际项目中的应用技巧，包括 SQL 编写、分页、主键生成、关联查询等；③学习如何通过 XML 和注解配置 SQL 语句，优化 MyBatis 性能，解决实际开发中的问题。 其他说明：文档内容详尽，涵盖面广，适合用于面试准备和技术学习。建议读者在学习过程中结合实际项目进行练习，以更好地掌握 MyBatis 的使用方法和技巧。此外，文档还提供了丰富的示例代码和配置细节，帮助读者加深理解和应用。
《基于YOLOv8的智能电网设备锈蚀评估系统》（包含源码、可视化界面、完整数据集、部署教程）简单部署即可运行。功能完善、操作简单，适合毕设或课程设计
插头模具 CAD图纸.zip
资源内项目源码是来自个人的毕业设计，代码都测试ok，包含源码、数据集、可视化页面和部署说明，可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源，毕设答辩评审绝对信服的保底85分以上，放心下载使用，拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务，拿来就能用的绝对好资源！！！ 项目备注 1、该资源内项目代码都经过测试运行成功，功能ok的情况下才上传的，请放心下载使用！ 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习，也适合小白学习进阶，当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行，也可在此代码基础上进行修改，以实现其他功能，也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件，仅供学习参考, 切勿用于商业用途。
《基于YOLOv8的智慧农业水肥一体化控制系统》（包含源码、可视化界面、完整数据集、部署教程）简单部署即可运行。功能完善、操作简单，适合毕设或课程设计
python爬虫；智能切换策略，反爬检测机制
台区终端电科院送检文档
e235d-main.zip
丁祖昱：疫情对中国房地产市场影响分析及未来展望
MCP快速入门实战，详细的实战教程
YD5141SYZ后压缩式垃圾车的上装箱体设计.zip
IMG_20250401_195352.jpg