差異處

這裏顯示兩個版本的差異處。

連向這個比對檢視

Both sides previous revision 前次修改
下次修改
前次修改
java:jackson:annotation:jsonserialize:module_annotation [2018/06/03 22:54]
tony
java:jackson:annotation:jsonserialize:module_annotation [2023/06/25 09:48] (目前版本)
行 2: 行 2:
 ====== Jackson - Convert the value fields with special char ====== ====== Jackson - Convert the value fields with special char ======
 ===== Problem ===== ===== Problem =====
-這陣子在擴充Rest API的功能時,聽同事說某功能輸出xml格式下,因內容使用unicode,導致無法正常在瀏覽器上顯示。xml並非不支援unicode,而是因為瀏覽器只支援xml 1.0;我們資料剛好不在1.0所規範的範圍內,因此瀏覽器才把它認為不合法。+這陣子在擴充Rest API的功能時,聽同事說某功能輸出xml格式下,因內容使用unicode,導致無法在瀏覽器上正常顯示。xml並非不支援unicode,而是因為瀏覽器只支援xml 1.0;我們資料剛好不在1.0所規範的範圍內,因此瀏覽器才把它認為不合法。本篇文章分享解決此問題的方法。
 ===== Research ===== ===== Research =====
-為什麼Json沒這問題呢?​ 對Json來說,unicode內容有兩種選擇:​+首先我思考的是,為什麼Json沒這問題呢? ​因為對Json來說,unicode內容有兩種選擇:​
   - 以代碼顯示:​ \u0001\u0002\u0003。   - 以代碼顯示:​ \u0001\u0002\u0003。
   - 以原始樣式顯示:​ 即欄位定義為unicode type。   - 以原始樣式顯示:​ 即欄位定義為unicode type。
-而xml在瀏覽器接收到代碼後,會做轉換;無法轉換時,就會報錯。在花些時間研究後,得知Amazon的Simple DB針對client傳遞或是要回應給client的資料,如果有這種情況,會將內容做base64的encoding。雖然對user來說是個小effort,但也不失為一個解法。+而xml在瀏覽器接收到代碼後,會做轉換;無法轉換時,就會報錯。在花些時間研究後,得知Amazon的Simple DB針對client傳遞或是要回應給client的資料;在有這種情況,會將內容做base64的encoding。雖然對user來說需要額外轉換,但也不失為一個解法。因此我的解法核心在於encoding,差別只在於用什麼方式。 
 ===== How to? ===== ===== How to? =====
 假設我們的Event Bean物件是這樣子:​ 假設我們的Event Bean物件是這樣子:​
行 49: 行 50:
 <message encoding="​base64">​dGVzdAECAw==</​message>​ <message encoding="​base64">​dGVzdAECAw==</​message>​
 </​code>​ </​code>​
-這時在做序列化時,就要區分xml與json的做法: ​(Base64StringSerializer)+這時在做序列化時,就要區分xml與json的做法,程式碼如下:
 <code java> <code java>
 @Override @Override
行 84: 行 85:
 } }
 </​code>​ </​code>​
-反序列化時,就是把輸入的base64轉回去,這部分看需求決定需不需要做: ​(Base64StringDeserializer)+反序列化時,就是把輸入的base64字串轉回去,這部分看需求決定需不需要做: ​
 <code java> <code java>
 public class Base64StringDeserializer extends StdDeserializer<​String>​ { public class Base64StringDeserializer extends StdDeserializer<​String>​ {
行 102: 行 103:
 } }
 </​code>​ </​code>​
-第一個方法在欄位上宣告了序列化與反序列化的物件,這也代表著這些物件同時身負處理不同格式的責任;因此第二個方法是希望讓client可以選擇序列化與反序列化的方法。+第一個方法在欄位上宣告了序列化與反序列化的物件,這也代表著這些物件同時身負處理不同格式的責任;因此第二個方法是希望讓client可以針對不同格式選擇序列化與反序列化的方法。
 ==== 第二個做法 - 宣告一個EncodingText物件 ==== ==== 第二個做法 - 宣告一個EncodingText物件 ====
 +Jackson提供module註冊功能,讓你可以針對特定物件型態提供序列化與反序列化的方法。接下來分享給大家我所使用的方式:​
 === EncodingText物件 === === EncodingText物件 ===
-首先我將原本message中使用的String特別宣告一個Base64Text物件,這可以讓Jackson區別與String的不同,且有相同需求的欄位也可以重複使用;另外在xml格式時,透過JacksonXmlProperty讓它帶上encoding的屬性:​+首先我將原本message中使用的String改為Base64Text物件,這是為了讓Jackson有所區別,且也可以重複使用;需要注意的部分是在xml格式時,透過JacksonXmlProperty讓它帶上encoding的屬性:​
 <code java> <code java>
 public class Base64Text { public class Base64Text {
行 114: 行 116:
  this.value = value;  this.value = value;
  }  }
 +
  @JacksonXmlProperty(isAttribute=true,​localName="​encoding"​)  @JacksonXmlProperty(isAttribute=true,​localName="​encoding"​)
  public String getEncoding(){  public String getEncoding(){
行 133: 行 136:
 } }
 </​code>​ </​code>​
-針對Event物件的調整,只要改為Base64Text並移除原本的@JsonSerialize與@JsonDeserialize。setMessage部分接受Base64Text與String型態以便於Client操作,這裡需要特別宣告@JsonSetter(value="​message"​)以避免Jackson找錯set method:+針對Event物件的調整,只要改為Base64Text並移除原本的@JsonSerialize與@JsonDeserialize。setMessage部分接受Base64Text與String型態以便於client操作,這裡需要特別宣告@JsonSetter(value="​message"​)以避免Jackson找錯set method:
 <code java> <code java>
 public class Event { public class Event {
行 218: 行 221:
  e.setMessage(msg);​  e.setMessage(msg);​
  
- tring ret = mapper.writeValueAsString(e);​+ String ​ret = mapper.writeValueAsString(e);​
  System.out.println(ret);​  System.out.println(ret);​
  Event newEvent = mapper.readValue(ret,​ Event.class);​  Event newEvent = mapper.readValue(ret,​ Event.class);​