FastJson時間格式化問題避坑經(jīng)驗(yàn)分享

更新時間：2022年08月22日 09:49:40 作者：樹洞君

這篇文章主要為大家介紹了FastJson時間格式化問題避坑經(jīng)驗(yàn)分享，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

問題背景

某一天，我們系統(tǒng)服務(wù)的依賴方找到我們，問我們?yōu)槭裁磿r間類型的字段會有這種數(shù)據(jù)存在？導(dǎo)致他們解析的時候報錯。

{"sloganEndtime": "20211-03-10 11:30:00"}
// 字段類型
private Date sloganEndtime;

于是我們開始進(jìn)行排查，最后發(fā)現(xiàn)數(shù)據(jù)源頭來源于一個導(dǎo)入表格的功能，商家運(yùn)營人員在導(dǎo)入數(shù)據(jù)的時候?qū)戝e了，所以導(dǎo)致了非常離譜的問題。

問題復(fù)現(xiàn)

利用原生JDK來轉(zhuǎn)換時間代碼截圖如下：會發(fā)現(xiàn)不會出現(xiàn)異常

我們換FastJson來嘗試下，代碼如下：發(fā)現(xiàn)會報錯！

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會出問題

通過跟代碼，我們發(fā)現(xiàn)FastJson有其自己的默認(rèn)時間格式：

// com.alibaba.fastjson.JSON#DEFFAULT_DATE_FORMAT
public static String DEFFAULT_DATE_FORMAT = "yyyy-MM-dd HH:mm:ss";

但是其使用判斷邏輯是預(yù)先校驗(yàn)了FORMAT與入?yún)⒌拈L度：

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、主動增加格式化注解，尤其是需要轉(zhuǎn)換未知的入?yún)r，需要提前確定

@JSONField(format="yyyy-MM-dd HH:mm:ss")
private Date sloganEndtime;

2、利用時間戳（Long）替換Date類型

3、自己的系統(tǒng)在進(jìn)行數(shù)據(jù)傳輸時，保證數(shù)據(jù)的合理性，增加相關(guān)校驗(yàn)

反思

為什么FastJson（1.2.36版本）在使用日期格式化的時候要預(yù)先校驗(yàn)長度？

PS：為什么不檢測無注解直接轉(zhuǎn)換失??？

為什么其他系統(tǒng)在進(jìn)行JSON轉(zhuǎn)換的時候不給字段主動添加格式化注解？
沒有絕對的答案，因?yàn)槭褂昧?xí)慣和代碼慣性的原因，我們經(jīng)常會忽略一些已經(jīng)習(xí)以為常的東西，只有做到更加的嚴(yán)謹(jǐn)和周全，才能盡量減少出錯的可能性。

以上就是FastJson時間格式化問題避坑經(jīng)驗(yàn)分享的詳細(xì)內(nèi)容，更多關(guān)于FastJson時間格式化的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: