springMvc中前台ajax传json数据后台controller接受对象为null

最新推荐文章于 2023-12-06 13:10:59 发布

青春依旧_

最新推荐文章于 2023-12-06 13:10:59 发布

阅读量4.6w

点赞数 59

文章标签：后台controller接受对象为null ajax传json数据后台接受不到 controller层接受json对象为null

本文链接：https://blog.csdn.net/qq_37960007/article/details/79542727

版权

一般地，出现这种情况很大一部分原因是对ajax中的参数作用不熟悉或者对@RequestBody注解不熟悉。

在jquery的ajax中，如果没加contentType:"application/json"，那么data就应该对应的是json对象，反之，如果加了contentType:"application/json"，那么ajax发送的就必须是字符串。为什么呢？contentType参数指定的是浏览器将发送什么样类型的编码，比如

text/html ： HTML格式

text/plain ：纯文本格式

text/xml ： XML格式

mage/gif ：gif图片

image/jpeg ：jpg图片格式

image/png：png图片格式

application/json ：json数据格式

application/pdf ：pdf格式

application/octet-stream ：二进制流数据

等等。。。

而你不指定contentType则代表为默认的application/x-www-form-urlencoded（表单）类型，这种类型有一个好处，它可以支持很多种情况，并能配合查询字符串（key1=value1&key2=vlaue2）的形式发送到服务器。而且这种默认类型可以很好地配合参数processData（默认为true，可以不用管他），该参数为true的时候，开启自动转化功能，只要是一个合法对象，都能将该对象自动地转化成查询字符串的形式。所以，在contentType默认的情况下(即不写)，ajax里的data参数既可以这么传：

$.ajax({

url:"http://xxxxxx",

data: { "username" : "ccc" } , //查询字符串的映射形式（即对象），在默认模式下提交时会自动地转化成查询字符串

.....

});

也可以这么传：

$.ajax({

url:"http://xxxxxx",

data: "username=ccc", //查询字符串形式

.....

});

所以看到这里，差不多也能知道为什么指定了contentType : "application/json"后，data就只能是字符串而且必须是json字符串了，首先你指定json格式，那提交格式肯定与json有关，再一个，因为你指定了"application/json"就意味着你放弃了"application/x-www-form-urlencoded"这种默认模式，默认模式虽可以自动地转化对象，不见得"application/json"这种格式就会自动帮你转，而事实证明，它确实不会帮你自动转。

下面便是两种犯错的例子：

1>前台ajax多加了contentType:"application/json"，data却错传成json对象：

后台处理：（employee该pojo对象里有username和password等String字段）

结果都为null

将contentType去掉后，

后台成功反射出对象：

2>ajax中没加contentType:"application/json"，data却直接使用了json字符串（和上面的一个道理）

后台情况：

有人就会说，去掉“application/json” 后的默认模式应该是支持字符串和对象的啊，是的，默认模式确实是可以支持两者，但是要看清楚，默认默认支持的字符串是什么？是json字符串吗？不！是查询字符串。

那么如何在application/json这种非默认模式下让Mvc后台接收到收据呢？这里就需要用到@RequestBody注解了，很巧，这个注解就是专门用来处理非默认模式下的请求的。该注解会提取你传过来的json字符串(注意是json字符串,不是查询字符串)，并将提取到的信息绑定到对象中。如果上图加了"application/json"那么controller就应该这么接收：

@RequestMapping("xxx")

......

public String test(@RequestBody Employee employee) {

......

}

3>第三点是真的有点恶心的一点，找了好久才找到。。

那就是有些关键的属性在Mvc层中反射失败，会导致其他所有属性都为null

比如上面的joindate对应的pojo是Date，本来input框里的值是 Thu Dec 30 00:00:00 CST 1999 ，传到后台用Date接收，但是显然格式不对，于是Date合成出了错，然后坑爹的就来了，因为这个特殊的属性反射失败，Mvc层就将请求打回去然后导致浏览器报错400 bad request ，从而导致其他所有属性都为null。最后把joindate属性注释掉，后台什么属性的值都收到了。。

希望能够帮到大家！

补充：在"application/json"的时候，ajax请求对跨域支持似乎不好，默认模式下的ajax成功跨域请求一旦改成了"application/json"就会报跨域请求的错

附加部分（有兴趣可以继续往下）

针对评论里关于application/json和application/x-www-form-urlencoded 孰好孰坏问题。正如评论所提到的，application/json就应该尽量避免使用吗？

看了很多资料，最主要的看法无非就是application/json能支持解析复杂又嵌套的对象，而认为application/x-www-form-urlencoded在面对复杂、对象+数组嵌套的往往就束手无策了。可事实真是这样吗？application/x-www-form-urlencoded就真的就不能解决复杂+对象嵌套+数组嵌套的情况吗？

思考

我们知道application/x-www-form-urlencoded默认模式下给后台传的是 key/value 形式的查询字符串，也就是所谓的QueryString。而springmvc会切割前台传来的 key/value查询字符串，并将切割到的信息绑定到controller方法对应的参数名中，从而我们能直接根据声明的参数名拿到对应的值。看到这里我们应该已经知道，为了能在默认模式下让后台接收到一个复杂+多重嵌套的对象，关键在于如何将该复杂对象序列化成springmvc能认识的QueryString。

前面我们提到过默认模式下会开启对象的自动转换，即自动帮你把对象转成QueryString，然后再把该QueryString传给后台。我们可以通过三个步骤：

1. let qs = JQuery.param(obj) 或者 let qs =  $.param(obj) 

2. let encoded_qs = decodeURIComponent(qs);

3. console.log(encoded_qs)

来查看一个对象究竟被自动序列化成了什么样子的QueryString，下面是一些测试结果

{passengers:[{"name":"Egor", "role":"pilot"},{"name":"DHH", "role":"2pilot"}]}

passengers[0][name]=Egor&passengers[0][role]=pilot&passengers[1][name]=DHH&passengers[1][role]=2pilot

{a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: {a: "you're outta ram" }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}

a[a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a][a]=you're outta ram

然后根据springmvc切割key/value查询字符串的特点，我们试着在controller的方法里声明下对应的key

可以看到后台成功取到了对应的值

其实不管他嵌套的再多，哪怕是上面多重嵌套的a[a][a][a][a][a]...，其本质上都只是QueryString的一个key而已，所以只要是正确的key，后台都能取到对应的值

看到这里可能有人要问了，虽然上面证明了可以从复杂+嵌套的结构中取到特定的值，但是自己想要的并不只是局限于取到特定的值，而是希望后台自动给我封装成一个对象，即我能直接从controller的方法参数中拿到一个完整的复杂嵌套对象。只不过，这样行的通吗？

再次思考

解决问题的出发点其实还是原来的原则，即如何将复杂对象序列化成springmvc能认识的QueryString [1*]，只不过这里有些小区别，更贴切的讲应该是如何将复杂对象序列化成springmvc能进行嵌套绑定的QueryString [2*]。

[1*]和[2*]对应的字符串是有区别的，举个例子，还是上面的那个passenger对象：

{passengers:[{"name":"Egor", "role":"pilot"},{"name":"DHH", "role":"2pilot"}]}

后台对应的bean对象应该是这种结构：

class Passengers {

    List<Passenger> passengers;
    //get set方法
    //...
｝

class Passenger {
    
    String name;

    String role;
    //get set方法
    //...
}

但是如果我们了解过springmvc的参数绑定就应该知道，为了让后台自动绑定好一个完整的对象，他的QueryString不应该是这样

passengers[0][name]=Egor&passengers[0][role]=pilot&passengers[1][name]=DHH&passengers[1][role]=2pilot

而应该是这样(即[2*]所对应的QueryString)：

passengers[0].name=Egor&passengers[0].role=pilot&passengers[1].name=DHH&passengers[1].role=2pilot

也就是说，如果能将JQuery.param序列化后的QueryString转化成[2*]对应的QueryString，那么一切问题也就解决了

于是，我写了份转换的代码，如下：

//定义字符栈
    var stack_chars = [];
    //定义[]括号栈
    var stack_parentheses = [];
	
	//定义这个下标变量是为了解决 {arr:[1,2,3]} ——> arr[]=1&arr[]=2&arr[]=3 这种情况
	//因为 arr[]=1&arr[]=2&arr[]=3 应该变成 arr[0]=1&arr[1]=2&arr[2]=3,所以定义了stackIdx是为了完成括号里下标的递增
    var stackIdx = -1;

    //判断当前读取的字符是否在[]中
    function inParentheses() {
        return stack_parentheses.length == 1;
    }

	//通过调用该方法完成将复杂对象obj转换成springmvc支持嵌套绑定的QueryString
    function serialize(obj) {
        let jqueryStr = decodeURIComponent(jQuery.param(obj));
        let serializeStr = "";
        for (let index = 0; index < jqueryStr.length; index++) {
            const c = jqueryStr[index];
            if (c === "[" || c === "]") {
                //入括号栈
                stack_parentheses.push(c);
                //检查是否栈满, 并进行相关操作
                serializeStr += checkCharsStack();
            } else {
                if (inParentheses()) {
                    stack_chars.push(c);
                } else {
                    //不在[]中的字符直接拼接到结果串中
                    serializeStr += c;
                }
            }
        }
        return serializeStr;
    }

    function checkCharsStack() {
        //栈满
        if (stack_parentheses.length >= 2) {
            let c;
            let str = "";
            let arr = [];
            while ((c = stack_chars.pop()) !== undefined) {
                //这里把pop出的内容又push进arr是为了防止字符顺序颠倒
                arr.push(c);
            }
            while ((c = arr.pop()) !== undefined) {
                str += c;
            }
            //[]出桟
            stack_parentheses.pop();
            stack_parentheses.pop();
            //如果符号栈为空只能说明JQuery序列化了没有key的数组,即序列化了这种 {arr:[1,2,3]} ——> arr[]=1&arr[]=2&arr[]=3
            if(str === ""){
                return "["+(++stackIdx)+"]";
            }else{
                stackIdx = -1;
            }
            //如果是其他字符，比如arr[1][name]应该转化成arr[1].name
            if (isNaN(parseInt(str))) {
                return "." + str;
            } else {
                //如果是数字，比如arr[1],转化后仍是arr[1], 即不需要动他
                return "[" + str + "]";
            }
        }
        return "";
    }

通过直接调用serialize(obj) 方法便可将复杂又多重嵌套的对象转换成[2*]对应的QueryString，于是，就可以直接提交给后台了，springmvc会自动帮你绑定好一个完整的复杂+嵌套对象。

(js文件传到码云上了点这里，里面有更详细说明)

下面我们来测试一个复杂而又多重嵌套的对象：

后台情况：

浏览器打印后台返回结果：

可以看到，application/x-www-form-urlencoded同样实现了多重嵌套的复杂对象到后台的传递，而且相对于application/json，在后台既不用手动写代码去合成bean对象，也不用手动声明@RequestBody注解，是不是也很方便？

就我个人而言，看了上面的例子后，在非特殊情况下会有些更倾向application/x-www-form-urlencoded了，跨域问题既没有application/json那么多，安全问题也不像application/json那样会有一定概率被一些植入恶意的回调代码，而且能很方便的传输和接受复杂而又多重嵌套的对象。

那么，application/json是不是就一点用都没有了呢？当然不是，比如你要调用别人的接口，那么就很可能要指定application/json格式，因为接口提供方就是这么规定的，下面就是一个例子：

而且在其他方面，json的数据格式传输时带宽会更小，尤其是在传输数组时，如果数组元素很多，那么application/json传输的数据量就会比application/x-www-form-urlencoded要少很多，自己可以拿上面的代码试试。同时，json的解析速度也会更快。总之，选择用谁个人觉得还是得看自己喜好以及团队里的规范和要求。

最后，还是希望大家能有所收获，如有问题也欢迎指出

青春依旧_

关注

59
点赞
踩
139

收藏

觉得还不错? 一键收藏
25
评论
springMvc中前台ajax传json数据后台controller接受对象为null

一般地，出现这种情况很大一部分原因是对ajax中的参数作用不熟悉或者对@RequestBody注解不熟悉。在jquery的ajax中，如果没加contentType:"application/json"，那么data就应该对应的是json对象，反之，如果加了contentType:"application/json"，那么ajax发送的就必须是字符串。为什么呢？contentType参数指定的...
复制链接

扫一扫