这篇文章主要为大家介绍了FastJson时间格式化问题避坑经验分享,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
问题背景
某一天,我们系统服务的依赖方找到我们,问我们为什么时间类型的字段会有这种数据存在?导致他们解析的时候报错。
{"sloganEndtime": "20211-03-10 11:30:00"}
// 字段类型
private Date sloganEndtime;
于是我们开始进行排查,最后发现数据源头来源于一个导入表格的功能,商家运营人员在导入数据的时候写错了,所以导致了非常离谱的问题。
问题复现
利用原生JDK来转换时间 代码截图如下:会发现不会出现异常
我们换FastJson来尝试下,代码如下:发现会报错!
SkuMainBean mainBean = JSON.parseObject("{\"sloganEndTime\":\"20211-03-10
11:30:00\"}", SkuMainBean.class);
System.out.println(mainBean);
# 异常信息
Exception in thread "main" com.alibaba.fastjson.JSONException: For input
string: "20211-03-10 11:30:00"
at
com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONPars
er.java:627)
at com.alibaba.fastjson.JSON.parseObject(JSON.java:361)
为什么FastJson会出问题
通过跟代码,我们发现FastJson有其自己的默认时间格式:
// com.alibaba.fastjson.JSON#DEFFAULT_DATE_FORMAT
public static String DEFFAULT_DATE_FORMAT = "yyyy-MM-dd HH:mm:ss";
但是其使用判断逻辑是预先校验了FORMAT与入参的长度:
if (strVal.length() == parser.getDateFomartPattern().length()) {
DateFormat dateFormat = parser.getDateFormat();
try {
return (T) dateFormat.parse(strVal);
} catch (ParseException e) {
// skip
}
}
// ....................................
return (T) new java.util.Date(longVal);
解决方案(3种)
1、主动增加格式化注解,尤其是需要转换未知的入参时,需要提前确定
@JSONField(format="yyyy-MM-dd HH:mm:ss")
private Date sloganEndtime;
2、利用时间戳(Long)替换Date类型
3、自己的系统在进行数据传输时,保证数据的合理性,增加相关校验
反思
- 为什么FastJson(1.2.36版本)在使用日期格式化的时候要预先校验长度?
PS:为什么不检测无注解直接转换失败?
- 为什么其他系统在进行JSON转换的时候不给字段主动添加格式化注解?
- 没有绝对的答案,因为使用习惯和代码惯性的原因,我们经常会忽略一些已经习以为常的东西,只有做到更加的严谨和周全,才能尽量减少出错的可能性。
以上就是FastJson时间格式化问题避坑经验分享的详细内容,更多关于FastJson时间格式化的资料请关注编程学习网其它相关文章!
沃梦达教程
本文标题为:FastJson时间格式化问题避坑经验分享
猜你喜欢
- ExecutorService Callable Future多线程返回结果原理解析 2023-06-01
- SpringBoot使用thymeleaf实现一个前端表格方法详解 2023-06-06
- 深入了解Spring的事务传播机制 2023-06-02
- JSP页面间传值问题实例简析 2023-08-03
- 基于Java Agent的premain方式实现方法耗时监控问题 2023-06-17
- JSP 制作验证码的实例详解 2023-07-30
- Java实现顺序表的操作详解 2023-05-19
- Java中的日期时间处理及格式化处理 2023-04-18
- Springboot整合minio实现文件服务的教程详解 2022-12-03
- Spring Security权限想要细化到按钮实现示例 2023-03-07