form-data和x-www-form-urlencoded,它们完整的表示是multipart/form-data和application/x-www-form-urlencoded。
为了方便,我们下面就用form-data和x-www-form-urlencoded表示。
两者的区别,可谓是老生常谈,随便百度一下,也是有大堆资料。可是我还想用一篇文章来总结一下,主要有两点原因:
好了,闲话少叙,我们进入正题。
form-data 和 x-www-form-urlencoded 都是表单请求的一种格式,主要区别有两点。
编码方式不同
我们先说x-www-form-urlencoded,它的编码方式就隐藏在名字里:urlencoded。看到这个关键词,你想到了什么?
没错,就是js中的encodeURI函数,这个函数的功能,我相信大家并不陌生,我们就不在赘述了。
x-www-form-urlencoded就可以理解为被encodeURI编码过的querystring。
比如,我们用x-www-form-urlencoded提交如下内容:
name: 张三
age: 18
实际上,请求体会被编码成如下格式:
name=%E5%BC%A0%E4%B8%89&age=18
这里需要强调一下,urlencoded这种格式并不是json格式,因此不能使用json库将其转成json。
接下里,我们来讲form-data,完整的表示为multipart/form-data。
multipart/form-data这种格式,会把表单内容分成多个部分,这也就是multipart的含义。
比如,同样是上面的表单内容,使用multipart/form-data格式,请求体将会类似下面这样:
--AaB03x
Content-Disposition: form-data; name="name"
Content-Type: text/plain
张三
--AaB03x
Content-Disposition: form-data; name="age"
Content-Type: text/plain
18
--AaB03x--
接下来,我们详细说一下其中的细节。
除了上面的请求体,我们的请求头需要向下面这样设置:
Content-Type: multipart/form-data; boundary=AaB03x
这里关键的部分就是boundary=AaB03x,定义分界线的随机数是什么,请求体中使用的随机数,需要和请求头中定义的随机数一致。
好了,这两种编码方式的基本格式,我们已经讲完了,你的第一感觉是什么,是不是觉得multipart/form-data的格式,要比x-www-form-urlencoded复杂的多。
没错,这正x-www-form-urlencoded的一大优点——对于普通的文本内容,x-www-form-urlencoded占用的字节更少。
支持的内容类型不同
x-www-form-urlencoded只支持普通的文本内容,而multipart/form-data的每一个part部分,都支持不同的Content-Type,比如图片、音频、视频等。
比如,我们向表单里面添加一个图片:
--AaB03x
Content-Disposition: form-data; name="name"
Content-Type: text/plain
张三
--AaB03x
Content-Disposition: form-data; name="age"
Content-Type: text/plain
18
--AaB03x
Content-Disposition: form-data; name="age"; filename="test.jpg"
Content-Type: image/jpeg
xxxxxxxx
--AaB03x--
和普通的文本内容不同的是,我们增加一个filename参数,来表示文件名称;并且把Content-Type设置成image/jpeg,表明它的格式是图片。
而且,你肯定也意识到了,multipart/form-data也不是json格式,也不能用json库读取它。
接下来,我们简单总结一下两者区别。
上面,我们已经把multipart/form-data和x-www-form-urlencoded的基本区别,给大家讲明白了。
接下来,我们来延伸一个内容,就是HttpServletRequest的getParameter——这个我们几乎每天都会接触到的方法。
我之前一直以为,getParameter方法只能获取请求地址上的参数,比如:
/api/user?name=张三&age=18
直到最近,我才发现事情远没有这么简单。这也是我为什么要单独给大家引申这块内容的原因。
实际上,getParameter除了能获取请求地址上的参数,还能获取表单中的参数,包括x-www-form-urlencoded和form-data这两种格式。
不知道,你有没有好奇过,为什么getParameterMap返回的是Map<String, String[]>格式,除了请求地址上可能传数组的情况,比如:
/api/user?name=张三&age=18&age=20
另外一个重要的原因,就是同一个参数名,除了可以出现在url地址上,还可以出现在请求体中,比如下面的post请求:
/api/user?name=张三&age=18
Content-Type: application/x-www-form-urlencoded
age=20&gender=male
此时age就有两个值,所以返回的是数组,只是getParameter方法默认只返回数组的第一个元素而已。
public String getParameter(String name ) {
handleQueryParameters();
ArrayList<String> values = paramHashValues.get(name);
if (values != null) {
if(values.size() == 0) {
return "";
}
return values.get(0);
} else {
return null;
}
}
至此,你有没有发现什么细思极恐的事情。在之前我一直排斥使用getParameterMap方法,原因就是我讨厌处理数组。
相反,我更情愿使用getParameter。但现在看来,这种便利可能给我的代码带来bug——因为getParameter并不兼容参数传数组的情况。
当然,并不是说getParameter不能用,而是在用之前需要问下自己,这个参数是不是只会传单个值。
这里还能总结一个经验:如果可以,不要用HttpServletRequest接收参数,更好的做法是将请求参数封装成一个类。
比如:
@Data
public class UserDTO {
private String name;
private List<Integer> age;
}
一方面,数据类型能够传达更多的信息,告诉我们这个参数可能传递一个数组;另一方便,Spring的data-binder能帮我处理好一切。
虽然,getParameter可以获取x-www-form-urlencoded和form-data中参数,但是它们还是有一些细微差别。
private void parseRequest(HttpServletRequest request) {
try {
Collection<Part> parts = request.getParts();
this.multipartParameterNames = new LinkedHashSet<>(parts.size());
MultiValueMap<String, MultipartFile> files = new LinkedMultiValueMap<>(parts.size());
for (Part part : parts) {
String headerValue = part.getHeader(HttpHeaders.CONTENT_DISPOSITION);
ContentDisposition disposition = ContentDisposition.parse(headerValue);
String filename = disposition.getFilename();
if (filename != null) {
if (filename.startsWith("=?") && filename.endsWith("?=")) {
filename = MimeDelegate.decode(filename);
}
files.add(part.getName(), new StandardMultipartFile(part, filename));
}
else {
// 只有filename为空part,才会放到multipartParameterNames里面
this.multipartParameterNames.add(part.getName());
}
}
setMultipartFiles(files);
}
catch (Throwable ex) {
handleParseFailure(ex);
}
}
你是不是还好奇,getParameter取数组的第一个元素,到底是请求体中的参数,还是url地址上的参数呢。
在写这篇文章时,我本打算介绍一下这个细节。但是后来,理智告诉我放弃传播这种无用的知识,因为它并不能指导我们写出更好的代码。相反可能会将我们引入错误的方向,比如下面的代码:
Map<String, String[]> parameterMap = request.getParameterMap();
if (parameterMap.containsKey("age") && parameterMap.get("age").length > 1) {
String age = parameterMap.get("age")[1];
}
你知道它想表达什么吗?
好了,这一节的内容细节有点多,如果你读起来有点吃力,建议多读几遍。
流不可重复读的问题,相信你一定遇到过。不过,你可能会疑问:我们今天讲的内容,跟这个问题有什么关系呢?
你别说,还真有,我最近就被这个问题坑了!
最近,我在工作中要开发一个接口代理的工具,需要对请求体进行一些处理。当我测试x-www-form-urlencode格式时,死活获取不到请求体。通过debug才发现,原来是getParameter搞的鬼。
相信通过前面的介绍,你已经知道原因:对于form-data和x-www-form-urlencoded这两种格式,getParameter方法会从请求体中查询参数,既然是请求体,当然会读取InputStream,从而导致后续再读取流的时候获取不到任何内容。
这个问题的一般解法,相信你已经知道了,就是写一个Filter对HttpServletRequest包装,读取InputStream中的数据,并缓存到一个byte[]中。包装类重写getInputStream方法返回一个ByteArrayInputStream,从而解决流不同重复读的问题。
上面的解法,网上的资料一搜一大堆,我就不贴代码了。
我今天要给你介绍的是另外一种思路,这种思路只能部分解决由于getParameter或getParameterMap导致的流读取的问题。
这里的部分解决,指的是如果你只是希望获取请求地址上的参数,那么这个方法能够奏效——它不会读取IO流。
这里的思路就是解析querystring。
可以通过request.getQueryString方法获取查询字符串,接下来的关键,就是如何方便的处理它。
推荐两个工具类,第一个是UriComponentsBuilder:
String queryString = request.getQueryString();
MultiValueMap<String, String> queryParams = UriComponentsBuilder.fromUriString("?" + queryString)
.build()
.getQueryParams();
这个类是Spring提供的,对于SpringBoot用户来说,开箱即用。
第二个是URLEncodedUtils:
String queryString = request.getQueryString();
List<NameValuePair> nameValuePairs = URLEncodedUtils.parse(queryString, StandardCharsets.UTF_8);
Map<String, List<String>> queryParams = nameValuePairs.stream()
.collect(Collectors.groupingBy(NameValuePair::getName))
.entrySet().stream()
.collect(Collectors.toMap(Map.Entry::getKey, e -> e.getValue().stream()
.map(NameValuePair::getValue).collect(Collectors.toList())));
这个类是httpclient提供的工具类,需要引入maven包:
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>${version}</version>
</dependency>
这两个工具类,能很好的帮助我们处理querystring,别再傻傻的用split函数分割了。
“温故而知新,可以为师矣”。
这篇文章从form-data和x-www-form-urlencoded的区别为起点,一步步展开,介绍了HttpServletRequest的getParameter方法,及其导致的流不可重复读的问题。
相信再遇到的类似的问题,你应该能游刃有余了。