以前遇到這類問題第一個反應就是覺得客戶端和服務端的編碼不一樣導致的。所以一開始也是那么認為的。以為我們項目使用的是pgsql,默認的就是utf-8,然后我們使用了字符也是utf-8,並且還有一個問題就是說一般的string類型(數據庫映射為varchar)顯示的是正常的,然后我就有些抓不着頭腦了,去google和百度都沒有找到合適的答案。都沒有解決。
問題是我們在JPA項目中使用了@Lob注解。這個注解的解釋是這樣的:
@Lob 注解屬性將被持久化為 Blog 或 Clob 類型。
- Clob(Character Large Ojects)類型是長字符串類型,具體的java.sql.Clob, Character[], char[] 和 java.lang.String 將被持久化為 Clob 類型。
- Blob(Binary Large Objects)類型是字節類型,具體的java.sql.Blob, Byte[], byte[] 和 serializable type 將被持久化為 Blob 類型。
- @Lob 持久化為Blob或者Clob類型,根據get方法的返回值不同,自動進行Clob和Blob的轉換。
- 因為這兩種類型的數據一般占用的內存空間比較大,所以通常使用延遲加載的方式,與@Basic標記同時使用,設置加載方式為FetchType.LAZY
但是很可惜,我明明是String類型的,但是還是亂碼
@Lob @Basic(fetch=FetchType.LAZY) private String content;

,我們再去看數據庫,發現數據庫中的類型是text的,那估計應該是@Lob注解影響到了,也就是說我們要讓數據庫生成text類型的字段,但是同時又不能夠使用這個注解,所以自然想到@Column中有一個columnDefinition屬性,可以指定類型,那么ok,我們現在把@Lob注解去掉,改成
@Basic(fetch=FetchType.LAZY) @Column(columnDefinition="TEXT") private String content;
,然后我們再來看的時候發現,亂碼就沒有了。
