Gson序列化不同环境中的坑

gson序列化 一个带有时间字符串的时候， 在本地项目中可以通过， 在测试环境报错

 

截图：

遇到这种异常怎么办？

我的解决方案：

看异常日志，明显就是日期解析问题，本地环境正常，那为什么测试环境不行呢?

先把项目中代码单独拎出来，自己写个test

演示demo

 public void execute() {
        Gson gson = new Gson();

        System.out.println("使用DateFormat类获取系统的当前时间的示例如下所示：");
        Date date = new Date();
        DateFormat shortDateFormat = DateFormat.getDateTimeInstance();

        System.out.println("模式的日期为：" + shortDateFormat.format(date));

        System.out.println("======================");


        String str = "{mydate:\"2013-10-06 00:00:00\"}";

        MyObj myObj = gson.fromJson(str, MyObj.class);
        String a = gson.toJson(myObj);
        System.out.println(a);
        System.out.println(myObj);
    }

原因是

DateFormat.getDateTimeInstance()

在不同的locale环境中，这样获取到的SimpleDateFormat的模式字符串会不一样

例如本地输出：

2018-3-19 16:29:35

测试环境输出：

Mar 19, 2018 4:24:47 PM

所以一个json字符串

String str = "{mydate:\"2013-10-06 00:00:00\"}";

序列化成对象在本地环境ok, 在测试环境就出错，

解决方案：为了避免使用Gson时遇到locale影响Date格式的问题，使用GsonBuilder来创建Gson对象，在创建过程中调用GsonBuilder.setDateFormat(String)指定一个固定的格式即可。例如：

public void execute() {
    //Gson gson = new Gson();

    System.out.println("使用DateFormat类获取系统的当前时间的示例如下所示：");
    Date date = new Date();
    DateFormat shortDateFormat = DateFormat.getDateTimeInstance();

    System.out.println("模式的日期为：" + shortDateFormat.format(date));

    System.out.println("======================");

    Gson gson = new GsonBuilder()
            .setDateFormat("yyyy-MM-dd HH:mm:ss")
            .create();

    String str = "{mydate:\"2013-10-06 00:00:00\"}";

    MyObj myObj = gson.fromJson(str, MyObj.class);
    String a = gson.toJson(myObj);
    System.out.println(a);
    System.out.println(myObj);
}

项目中 部分代码修改为：

public static GxbGsonConverterFactory create() {
    Gson gson = new GsonBuilder()
            .setDateFormat("yyyy-MM-dd HH:mm:ss")
            .create();

    return create(gson);
}

这样就解决该问题，

总结：

1，遇到这样的问题关键要看异常日志，

2，在本地 写个小demo, 本地没有问题， 然后把该小demo上传到测试环境，重现错误

3，搜索引擎查，类似这种问题，别人肯定遇到过，然后修改，本问题解决参考http://rednaxelafx.iteye.com/blog/788306

4，千万别小看小demo, 这个很考验一个人的基本能力，并不是每个人都会灵活运用，因为一个大项目的代码依赖的包太多，又是web环境，你总不可能修改一行代码然后提交发布，然后去验证，那这样就太笨了，太慢了。

5，我的心得是，并不是该问题有多难，而是一种解决方法，一个好的解决方法是在太重要了，因为它关系到你诸如此类的疑难杂症是否能最快速解决掉，以后项目中无论任何异常问题，你都得把代码能拎得出来， 在你自己的小demo, 小工程上能调试，以最快的速度解决掉，而不是在原来臃肿的工程中陷入一种无解的循环而无法自拔， 举一反三，比如我们的其他工程项目，项目依赖多，你得单独拧出来，抠出来，注意我提的这两个词，拧出来，抠出来