浅析MultipartResolver

处理文件是大多数项目必要的一个功能模块。有的只是简单的保存文件例如图片和视频，有的则需要解析例如Word、Excel、PDF等等。

一、使用multipartResolver解析文件

在Spring的配置文件中加入如下文件解析器

<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver"><property name="maxUploadSize"><value>9242880</value></property>
</bean>

package com.controller;import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.Map.Entry;import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.multipart.MultipartFile;import com.bean.Response;
import com.util.ExcelUtil;@Controller
@RequestMapping(value = "/file")
public class FileController {@RequestMapping(value = "/fileUpload", method = RequestMethod.POST)@ResponseBodypublic Response fileUpload(HttpServletRequest request, HttpServletResponse httpResponse) {List<Map<String, Object>> dataList =new ArrayList<Map<String,Object>>();try {DiskFileItemFactory fileFactory = new DiskFileItemFactory();// 内存存储的最大值fileFactory.setSizeThreshold(4096);ServletFileUpload fu = new ServletFileUpload(fileFactory);List<FileItem> fileItems = fu.parseRequest(request);Iterator<FileItem> iter = fileItems.iterator();while (iter.hasNext()) {FileItem item = iter.next();// 文件if (!item.isFormField()) {dataList.addAll(ExcelUtil.readExcel(item.getInputStream(), item.getName()));for (Map<String, Object> data : dataList) {Iterator<Entry<String, Object>> iterator = data.entrySet().iterator();System.out.println("----------------------------------");while (iterator.hasNext()) {Entry<String, Object> entry = iterator.next();System.out.print("   " + entry.getKey() + "--" + entry.getValue() + "   ");}System.out.println("----------------------------------");}}}} catch (Exception e) {System.out.println(e.getMessage());}Response response = new Response();response.setResult(dataList);return response;}@RequestMapping(value = "/multipartUpload", method = RequestMethod.POST)@ResponseBodypublic Response multipartUpload(@RequestParam("files") MultipartFile[] files) {List<Map<String, Object>> dataList = new ArrayList<Map<String,Object>>();Response response = new Response();try {for (MultipartFile file : files) {dataList.addAll(ExcelUtil.readExcel(file.getInputStream(), file.getOriginalFilename()));for (Map<String, Object> data : dataList) {Iterator<Entry<String, Object>> iterator = data.entrySet().iterator();System.out.println("----------------------------------");while (iterator.hasNext()) {Entry<String, Object> entry = iterator.next();System.out.print("   " + entry.getKey() + "--" + entry.getValue() + "   ");}System.out.println("----------------------------------");}}System.out.println("finish");} catch (Exception e) {System.out.println(e.getMessage());return response;}response.setResult(dataList);return response;}
}

此处用两种方式去解析文件

第一种：通过从原生的HttpServerletRequest解析出FileItem去解析文件

第二种：通过注解的方式直接拿到MultipartRequest中的MultipartFile去解析文件

从代码上看两种方式都没有问题，但是multipartResolver会作怪，让我们看看测试结果

先来看通过注解的方式我们拿到了什么

两个CommnsMultipartFile实例，它实现了MultipartFile接口。此时我们可以正常的解析文件

再来看第一种方式我们拿到的东西

神马都没有，为啥呢，因为此时的HttpServletRequest并不是我们想象中的那种，它已经被转换成了DefaultMultipartHttpServletRequest，里面的具体属性是这样的：

所以如果我们要用FileUpload去从request里面解析出文件，就不要让HttpServerletRequest被转换。于是重新实现一个解析器

     <bean id="multipartResolver" class="com.config.MyMultipartResolver"><property name="maxUploadSize"><value>9242880</value></property><property name="excludeUrls" ><list><value>fileUpload</value><value>fileUpload1</value><value>fileUpload2</value></list></property><!-- url属于excludeUrls的http请求就不会被multipartResolver先解析 --></bean>

package com.config;import java.util.List;import javax.servlet.http.HttpServletRequest;
import org.springframework.web.multipart.commons.CommonsMultipartResolver;public class MyMultipartResolver extends CommonsMultipartResolver {private List<String> excludeUrls;public List<String>  getExcludeUrls() {return excludeUrls;}public void setExcludeUrls(List<String> excludeUrls) {this.excludeUrls = excludeUrls;}/*** 这里是处理Multipart http的方法。如果这个返回值为true,那么Multipart http* body就会MyMultipartResolver 消耗掉.如果这里返回false* 那么就会交给后面的自己写的处理函数处理例如刚才ServletFileUpload 所在的函数* * @see org.springframework.web.multipart.commons.CommonsMultipartResolver#isMultipart(javax.servlet.http.HttpServletRequest)*/@Overridepublic boolean isMultipart(HttpServletRequest request) {for (String url : excludeUrls) {// 这里可以自己换判断if (request.getRequestURI().contains(url)) {return false;}}return super.isMultipart(request);}
}

现在就可以两种方式都支持了。

以下转载至http://zachary-guo.iteye.com/blog/1294443，源码分析

客户端浏览器将按照 RFC 1867 所规定的格式，对提交表单内容进行编码，服务器端只需要根据 RFC 1867 规定的格式对请求中的信息进行解码，就可以获得客户端表单提交的数据，包括上传的文件。

既然 RFC 1867 所规定的规则是一定的，所以，我们没有必要每次都根据这一规则分析每一次请求中的信息。既然是通用的逻辑，当然也就有通用的类库，比如早期的 jsp smart upload 和 Oreilly 的 COS 类库，以及现在使用最多的 Commons FileUpload 类库。实际开发中，我们只需要使用这些专门针对表单的文件上传处理类库即可。

在实际基于表单的文件上传功能的时候，Spring MVC 框架底层实际上也是使用了以上几种类库。只不过，通过 org.springframework.web.multipart.MultipartResolver 接口的抽象，Spring MVC 将具体选用哪一种类库的权利留给了我们。

MultipartResolver 位于 HandlerMapping 之前，请求一来就交由它来处理。当 Web 请求到达 DispatcherServlet 并等待处理的时候，DispatcherServlet 首先会检查能否从自的 WebApplicationContext 中找到一个名称为 multipartResolver(由 DispatcherServlet 的常量 MULTIPART_RESOLVER_BEAN_NAME 所决定)的 MultipartResolver 实例。如果能够获得一个 MultipartResolver 的实例，DispatcherServlet 将调用 MultipartResolver 的 isMultipart(request) 方法检查当前 Web 请求是否为 multipart类型。如果是，DispatcherServlet 将调用 MultipartResolver 的 resolveMultipart(request) 方法，对原始 request 进行装饰，并返回一个 MultipartHttpServletRequest 供后继处理流程使用(最初的 HttpServletRequest 被偷梁换柱成了 MultipartHttpServletRequest)，否则，直接返回最初的 HttpServletRequest。来看看 UML 类图：

MultipartRequest 毕竟是接口，接口就是接口，总得有人实现。AbstractMultipartHttpServletRequest 这个抽象类持有 MultiValueMap<String, MultipartFile> multipartFiles 这样一个实例变量，有了这个 map，把 MultipartRequest 接口里的方法逐一实现就不是难事了。现在的问题是，multipartFiles 从哪来的？不可能像孙悟空似的从石缝里蹦出来吧。。。。。

再回到 MultipartResolver。MultipartResolver 的 isMultipart(request) 方法好实现，当判断出当前的 request 是 multipart 类型的请求，它将调用 MultipartResolve 的 resolveMultipart(request)。这里的 request 就是原始的 HttpServletRequest 对象，奇迹就出现在这里。以 CommonsMultipartResolver 为例，当调用 resolveMultipart(request) 时，看看它是如何创建 MultipartRequest 的：

Java代码

public MultipartHttpServletRequest resolveMultipart(final HttpServletRequest request) throws MultipartException {
Assert.notNull(request, "Request must not be null");
if (this.resolveLazily) {
return new DefaultMultipartHttpServletRequest(request) {
@Override
protected void initializeMultipart() {
MultipartParsingResult parsingResult = parseRequest(request);
setMultipartFiles(parsingResult.getMultipartFiles());
setMultipartParameters(parsingResult.getMultipartParameters());
}
};
}
else {
MultipartParsingResult parsingResult = parseRequest(request);
return new DefaultMultipartHttpServletRequest(
request, parsingResult.getMultipartFiles(), parsingResult.getMultipartParameters());
}
}

暂且不管 resolveLazily 为何意。假设 resolveLazily 为 false，我们看 else 的片段。由于是 CommonsMultipartResolver，它的 parseRequest 方法将从原始的 HttpServletRequest 中解析出文件，得到基于 Commons FileUpload API 的 FileItem 对象。Spring 在这里封装了一下，对于 MultipartResolver 而言，它看到的就是 MultipartFile。注意最后的 return，它将构建一个 DefaultMultipartHttpServletRequest，也就是 MultipartRequest。它将 MultipartFile 和 MultipartParameter 作为构造函数的参数传入，在这个构造函数里，有 setMultipartFiles 这句话。这个方法正是 AbstractMultipartHttpServletRequest 里的方法，这样，AbstractMultipartHttpServletRequest 的实例变量 multipartFiles 就有正规来源了吧，即解决了上面我们提到的疑问。然去实现 MultipartRequest 接口里的方法就是轻而易举的事了。

再来看看 resolveLazily。request 被装饰了一下，后续处理上传的文件，通过 multipartRequest.getFile(name) 就可以拿到文件。MultipartRequest 接口里定义的方法全在 AbstractMultipartHttpServletRequest 类里给实现了，而它之所以能实现，因为它持有了 multipartFiles。虽说是实例变量，但拿到该变量，还是要通过方法得到的。我们来看看 AbstractMultipartHttpServletRequest 里是如何得到 multipartFiles 的：

Java代码

/**
* Obtain the MultipartFile Map for retrieval,
* lazily initializing it if necessary.
* @see #initializeMultipart()
*/
protected MultiValueMap<String, MultipartFile> getMultipartFiles() {
if (this.multipartFiles == null) {
initializeMultipart();
}
return this.multipartFiles;
}
/**
* Lazily initialize the multipart request, if possible.
* Only called if not already eagerly initialized.
*/
protected void initializeMultipart() {
throw new IllegalStateException("Multipart request not initialized");
}

我们来分析一下以上代码。multipartFiles 会为 null 吗？为什么要做这样的判断？不是之前通过 DefaultMultipartHttpServletRequest 的构造函数传入了吗？这里就是 resolveLazily 的作用了。如果非延迟解析，则的确会通过 DefaultMultipartHttpServletRequest 的构造函数传入 multipartFiles。如果为延迟解析，则不会传入 multipartFiles，那么它当然就有可能为 null 了。multipartFiles 为 null 就会调用 initializeMultipart 来初始化(谁让它延迟呢)。resolveLazily 为 true 时，构造的 DefaultMultipartHttpServletRequest 的对象覆写了 AbstractMultipartHttpServletRequest 的 initializeMultipart 方法，它从原始请求中解析文件。思考一个问题：resolveLazily 为 true，直接构造 DefaultMultipartHttpServletRequest 而不覆写 initializeMultipart 会有什么后果？

我认为，resolveLazily 为 false 时，请求一旦被 MultipartResolver 接手，它就会解析请求中的文件，而不必等待后续 controoler 主动从 MultipartRequest 中 getFile。 resolveLazily 为 true 时，只有等后续的 controller 主动调用 MultipartRequest.getFile 才会从原始请求中解析文件。Spring 这样处理，可能是考虑效率问题吧。也许是 multipart 类型的请求，但后续又不操作文件，就没有在请求一来就做文件解析操作吧。

浅析MultipartResolver相关推荐

浅析 JavaScript 中的函数 uncurrying 反柯里化
柯里化柯里化又称部分求值,其含义是给函数分步传递参数,每次传递参数后部分应用参数,并返回一个更具体的函数接受剩下的参数,这中间可嵌套多层这样的接受部分参数函数,直至返回最后结果. 因此柯里化的过程是 ...
浅析Python中bytes和str区别
本博转载自:Chown-Jane-Y的浅析Python3中的bytes和str类型 Python 3最重要的新特性之一是对字符串和二进制数据流做了明确的区分.文本总是Unicode,由str类型表示, ...
学习《Linux设备模型浅析之设备篇》笔记(深挖一)
这篇文章既然说了是浅析,那就是跳过了一些东西,我们把这些跳过的东西给它尽可能的补回来今天登陆 lxr.free-electrons.com 发现内核版本已经升级到3.15了,那以后都使用3.15的源 ...
学习《Linux设备模型浅析之设备篇》笔记(一)
最近在学习Linux设备模型,前面几篇文章也是读这篇的时候遇到问题,然后为了搞清楚先转去摸索才写出来的. 当然了,刚开始是先读到<Linux那些事儿之我是Sysfs>,搞不清楚才去读的&l ...
架构周报| 浅析MySQL JDBC连接配置上的两个误区
经典案例 \\ 浅析MySQL JDBC连接配置上的两个误区:相信使用MySQL的同学都配置过它的JDBC驱动,多数人会直接从哪里贴一段URL过来,然后稍作修改就上去了,对应的连接池配置也是一样的,很 ...
超级账本（Hyperledger Fabric）之权限管理浅析
链客,专为开发者而生,有问必答! 此文章来自区块链技术社区,未经允许拒绝转载. 超级账本(Hyperledger Fabric)之权限管理浅析超级账本是联盟链的代表,而其相对于共链(例如比特币,以太 ...
linux内核SMP负载均衡浅析
需求在<linux进程调度浅析>一文中提到,在SMP(对称多处理器)环境下,每个CPU对应一个run_queue(可执行队列).如果一个进程处于TASK_RUNNING状态( ...
CAS、原子操作类的应用与浅析及Java8对其的优化
点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试文章作者:CoderBear juejin.im/post/5c7a8 ...
Python标准库queue模块原理浅析
Python标准库queue模块原理浅析本文环境python3.5.2 queue模块的实现思路作为一个线程安全的队列模块,该模块提供了线程安全的一个队列,该队列底层的实现基于Python线程th ...
Python标准库threading模块Condition原理浅析
Python标准库threading模块Condition原理浅析本文环境python3.5.2 threading模块Condition的实现思路在Python的多线程实现过程中,在Linux平 ...

浅析MultipartResolver

一、使用multipartResolver解析文件

浅析MultipartResolver相关推荐

最新文章

热门文章