深入springMVC

痛定思痛。 2022-06-17 12:06 175阅读 0赞

HTML 页面中的表单最初所采用 application/x-www-form-urlencode 编码方式，并不满足文件上传的需要，所以，RFC 1867 在此基础上增加了新的 multipart/form-data 编码方式以支持基于表单的文件上传。通常情况下，按照如下形式声明表单以及表单中的元素：

Html代码   ![收藏代码][icon_star.png]

1.  **<****form** action="..." method="post" enctype="multipart/form-data"**>**  
2.    **<****input** type="file" name="tile2upload" **/>**  
3.    **<****input** type="submit" value="Upload" **/>**  
4.  **</****form****>**

客户端浏览器将按照 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 类图：   
![点击查看原始大小图片][13e05e7d-7555-35f0-a0df-2cd007e5e82d.jpg]  
        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代码   ![收藏代码][icon_star.png]

1.  **public** MultipartHttpServletRequest resolveMultipart(**final** HttpServletRequest request) **throws** MultipartException \{  
2.    Assert.notNull(request, "Request must not be null");  
3.    **if** (**this**.resolveLazily) \{  
4.      **return** **new** DefaultMultipartHttpServletRequest(request) \{  
5.        @Override  
6.        **protected** **void** initializeMultipart() \{  
7.          MultipartParsingResult parsingResult = parseRequest(request);  
8.          setMultipartFiles(parsingResult.getMultipartFiles());  
9.          setMultipartParameters(parsingResult.getMultipartParameters());  
10.       \}  
11.     \};  
12.   \}  
13.   **else** \{  
14.     MultipartParsingResult parsingResult = parseRequest(request);  
15.     **return** **new** DefaultMultipartHttpServletRequest(  
16.         request, parsingResult.getMultipartFiles(), parsingResult.getMultipartParameters());  
17.   \}  
18. \}

暂且不管 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代码   ![收藏代码][icon_star.png]

1.  /\*\* 
2.   \* Obtain the MultipartFile Map for retrieval, 
3.   \* lazily initializing it if necessary. 
4.   \* @see \#initializeMultipart() 
5.   \*/  
6.  **protected** MultiValueMap<String, MultipartFile> getMultipartFiles() \{  
7.    **if** (**this**.multipartFiles == **null**) \{  
8.      initializeMultipart();  
9.    \}  
10.   **return** **this**.multipartFiles;  
11. \}  
12.   
13. /\*\* 
14.  \* Lazily initialize the multipart request, if possible. 
15.  \* Only called if not already eagerly initialized. 
16.  \*/  
17. **protected** **void** initializeMultipart() \{  
18.   **throw** **new** IllegalStateException("Multipart request not initialized");  
19. \}

我们来分析一下以上代码。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 类型的请求，但后续又不操作文件，就没有在请求一来就做文件解析操作吧。

[icon_star.png]: /images/20220617/1da6e341f9894095a86352ae8fa12ab0.png
[13e05e7d-7555-35f0-a0df-2cd007e5e82d.jpg]: /images/20220617/4a075f17295b4c0ebad71a12c7424c5b.png