正文

使用Spring处理x-www-form-urlencoded方式

︶ㄣSDDLL学院 メ
SDDLL学院V管理员 / 阅读
0705
这篇文章主要介绍了使用Spring处理x-www-form-urlencoded方式，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教

这篇文章主要介绍了使用Spring处理x-www-form-urlencoded方式，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教

Spring处理x-www-form-urlencoded方式

最近在重写一个项目时遇到了许多奇葩问题，这个项目是一个简单的web后台项目，基本上全都是增删改查数据库的操作。这里面遇到几个用spring接收前端post请求的接口。

基本情况是post请求有四种data参数格式，这些基础知识在我另一片博文中提到过这里就不废话了。主要是因为前端有两个地方用到了这个接口，但是在用这个接口的时候两个地方用法都不同，奇葩的c++居然还都解析成功了（其实因为c++没有对请求参数格式和数据做检查所以一直没有问题）。

一个地方是发送的是application/json格式，发送了一个jsonArray数据（数据例子["abc", "bcd"]）这个是没有问题的正确使用方式。（下面简称前者）

另一个地方是发送的application/x-www-form-urlencode格式，发送的也是一个jsonArray数据。（下面简称后者）

前者解析方式比较简单

?
1
2
3
4
5
6
7
8
9
@RequestMapping(value = "/check_apps_version",
     method = RequestMethod.POST,
     produces = {"application/json;charset=UTF-8"},
     consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)
 @ResponseBody
 public BaseResponse<List<AppListItem>> checkAppsVersion(ReqCheckAppsVersion requstParam,
     @RequestBody List<String> apps) {
   return new BaseResponse<>();
 }

后者这个发送方式在spring用@RequestBody解析时就很怪异，但是前段是手机APP已经发布出去了没法修改，只能后端来修改满足这个奇怪的需求

通过调试发现后者前端的接口传过来的参数是"["abc","def"]="这样子的，本身x-www-form-urlencode是多个kev-value对的数据格式，所以现在没有value只有key了，只能通过字符串处理来解决了。

?
1
2
3
4
5
6
7
8
9
10
11
@RequestMapping(value = "/check_apps_version",
     method = RequestMethod.POST,
     produces = {"application/json;charset=UTF-8"},
     consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE)
 @ResponseBody
 public BaseResponse<List<AppListItem>> checkAppsVersionParams(HttpServletRequest request,
                                                               ReqCheckAppsVersion requstParam,
                                                               @RequestBody String apps) {
String body = request.getReader().lines().collect(Collectors.joining(System.lineSeparator()));
   return BaseResponse.success();
 }

两种方式，一种是通过@RequestBody把post data解析成string格式，另一种是通过HttpServletRequest解析出整个原始post data。然后做字符串处理。

但是在做做这个测试时候我们想了一下会不会有只有value没有key的情况，也就是这样"=["abc","def"]"。

测试结果是用tomcat没法从HttpServletRequest到这个post data，但是用jetty可以从HttpServletRequest解析到post data。

这个可能是tomcat和jetty的区别吧，还没有弄清楚什么原因。但是我们的问题总算是解决了，最大感触就是前人挖坑后人埋啊。

希望以后能注意一下代码健壮性的问题，避免给别人或者自己挖坑。

关于application/x-www-form-urlencoded编码

同事遇到在servlet端通过request对象getInputStream读取POST过来的数据，却读不到的问题，怀疑是tomcat的问题。查了一下Content-type是application/x-www-form-urlencoded，估计是被解析成了parameters，果然在他获取流之前，有过request.getParameter的操作。

熟悉servlet的话，这个问题应该算常识了。它其实跟容器无关，所有的servlet容器都是这样的行为。几年前在实现一个网关代理的时候就遇到过这个问题，当时使用的是jetty，发现POST过来的数据读不到，也是application/x-www-form-urlencoded编码，断点跟踪发现是在获取流之前有过request.getParameter，数据会被解析，并且后续数据流不可再被读取。

在servlet规范3.1.1节里，对POST数据何时会被当做parameters有描述：

1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter family of methods on the request object.

If the conditions are met, post form data will no longer be available for reading directly from the request object's input stream.

规范里已经明确的声明当请求满足：

1) http/https

2) POST

3) Content-type 是application/x-www-form-urlencoded

4) 调用过getParameter方法，则数据会被当做请求的paramaters，而不能再通过 request 的 inputstream 直接读取。

所以不论tomcat、jetty还是其他servlet容器都遵循这个方式。不过话说回来，为什么application/x-www-form-urlencoded编码的数据会被当做parameter来解析呢？

使用http上传数据可以用GET或POST，使用GET的话，只能通过uri的queryString形式，这会遇到长度的问题，各个浏览器或server可能对长度支持的不同，所以到要提交的数据如果太长并不适合使用GET提交。

采用POST的话，既可以在uri中带有queryString也可以将数据放在body中。body内容可以有多种编码形式，其中application/x-www-form-urlencoded编码其实是基于uri的percent-encoding编码的，所以采用application/x-www-form-urlencoded的POST数据和queryString只是形式不同，本质都是传递参数。

在tomcat的Request.parseParameters方法里，对于application/x-www-form-urlencoded是有做判断的，对这种编码会去解析body里的数据，填充到parameters里，所以后续想再通过流的方式读取body是读不到的(除非你没有触发过getParameter相关的方法)。

在HTML4之前，表单数据的编码方式只有application/x-www-form-urlencoded这一种（现在默认也是这种方式），因为早期的时候，web上提交过来的数据也是非常简单的，基本上以key-value形式为主，所以表单采用application/x-www-form-urlencoded这种编码形式也没什么问题。

在HTML4里又引入了multipart/form-data编码，对于这两种编码如何选择，请参考这里。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持米米素材网。

原文链接：https://blog.csdn.net/zpzkitt/article/details/79217811