這是本文件的舊版!


Jackson - Convert the value fields with special char

這陣子在擴充Rest API的功能時,聽同事說某功能輸出xml格式下,因內容使用unicode,導致無法正常在瀏覽器上顯示。xml並非不支援unicode,而是因為瀏覽器只支援xml 1.0;我們資料剛好不在1.0所規範的範圍內,因此瀏覽器才把它認為不合法。

為什麼Json沒這問題呢? 對於Json來說,unicode內容有兩種選擇:

  1. 以代碼顯示: \u0001\u0002\u0003。
  2. 以原始樣式顯示: 即欄位定義為unicode type。

而xml在瀏覽器接收到代碼後,會做轉換;無法轉換時,就會報錯。在花些時間研究後,得知Amazon的Simple DB針對client傳遞或是要回應給client的資料,如果有這種情況,會將內容做base64的encoding。雖然對user來說是個小effort,但也不失為一個解法。

假設我們的Event Bean物件是這樣子:

public class Event {
	private Date date;
 
	private String message;
 
	public Date getDate(){
		return date;
	}
 
	public void setDate(Date date){
		this.date = date;
	}
 
	public String getMessage(){
		return message;
	}
 
	public void setMessage(String message){
		this.message = message;
	}
}
當message中包含對xml不合法的字元,就會發生我所敘述的問題。

第一個方法 - 直接操作message

最簡單的方法,當然就是直接將message做base64的encoding。但如果直接把值塞到物件內,可能會讓使用到的client必須自行去decoding。因此,如果選擇使用這種方式,建議使用@JsonSerialize與@JsonDeserialize:

    @JsonSerialize(using=Base64StringSerializer.class)
    @JsonDeserialize(using=Base64StringDeserializer.class)
    private String message;
這方法可以讓物件在輸出為xml或json格式時,才被做encoding;如果user將值給塞回來時,也會透過descerializer還原為好操作的內容。通常使用這個方法message所輸出的xml會長這樣子:
<message>dGVzdAECAw==</message>
對於沒讀使用手冊的user來說,可能無法知道它是經過encoding;因此比較好的顯示方式為:
<message encoding="base64">dGVzdAECAw==</message>
這時在做序列化時,就要區分xml與json的做法: (Base64StringSerializer)
@Override
public class Base64StringSerializer extends StdSerializer<String> {
	private static final long serialVersionUID = 1L;
 
	public Base64StringSerializer() {
		super(String.class);
	}
 
	@Override
	public void serialize(String value, JsonGenerator jgen,
			SerializerProvider provider) throws IOException {
		String encodingVal = new String(Base64.getEncoder().encode(value.getBytes()));
		if( jgen instanceof ToXmlGenerator ) {
			ToXmlGenerator xgen = (ToXmlGenerator) jgen;
 
			xgen.writeStartObject();
			xgen.setNextIsAttribute(true);
			xgen.writeFieldName("type");
			xgen.writeString("base64");
			xgen.setNextIsAttribute(false);
 
			xgen.setNextIsUnwrapped(true);
			xgen.writeFieldName("value");
			xgen.writeObject(encodingVal);
			xgen.setNextIsUnwrapped(false);
 
			xgen.writeEndObject();
		} else {
			jgen.writeString(encodingVal);	
		}
	}
}
反序列化時,就是把輸入的base64轉回去,這部分看需求決定需不需要做: (Base64StringDeserializer)
public class Base64StringDeserializer extends StdDeserializer<String> {
 
	private static final long serialVersionUID = 1L;
 
	public Base64StringDeserializer() {
		super(String.class);
	}
 
	@Override
	public String deserialize(JsonParser parser, DeserializationContext context)
			throws IOException, JsonProcessingException {
		String text = parser.getValueAsString();
		return new String(Base64.getDecoder().decode(text));
	}
}
第一個方法在欄位上宣告了序列化與反序列化的物件,這也代表著這些物件同時身負處理不同格式的責任;因此第二個方法是希望讓client可以選擇序列化與反序列化的方法。

第二個做法 - 宣告一個EncodingText物件

首先我將原本message中使用的String特別宣告一個Base64Text物件,這可以讓Jackson區別與String的不同,且有相同需求的欄位也可以重複使用;另外在xml格式時,透過JacksonXmlProperty讓它帶上encoding的屬性:

public class Base64Text {
	@JacksonXmlText
	private String value;
 
	public Base64Text(String value) {
		this.value = value;
	}
	@JacksonXmlProperty(isAttribute=true,localName="encoding")
	public String getEncoding(){
		return "base64";
	}
 
	public String getValue(){
		return value;
	}
 
	@JsonIgnore
	public String getEncodingValue(){
		return new String(Base64.getEncoder().encode(value.getBytes()));
	}
 
	public static Base64Text decode(String aEncryptValue){
		return new Base64Text(new String(Base64.getDecoder().decode(aEncryptValue)));
	}
}
針對Event物件的調整,只要改為Base64Text並移除原本的@JsonSerialize與@JsonDeserialize:
public class Event {
	private Date date;
 
	private Base64Text message;
 
	public Date getDate(){
		return date;
	}
 
	public void setDate(Date date){
		this.date = date;
	}
 
	public Base64Text getMessage(){
		return message;
	}
 
	public void setMessage(String message){
		this.message = new Base64Text(message);
	}
}