著重基礎之—MySql Blob類型和Text類型

標籤：路徑   回顧   color   mda   odi   ext   配置   dash   初步   

著重基礎之—MySql Blob類型和Text類型—二進位儲存 

　　在經曆了幾個Java項目後，遇到了一些問題，在解決問題中體會到基礎需要不斷的回顧與鞏固。

　　最近做的項目中，提供給介面調用方資料同步介面，傳輸的資料格式是Json串。由於json串的結構層級較多，資料量也不少。在設計資料庫的時候，選擇了Blob類型做為欄位類型。一切的一切就打這開始，同步服務正常運作，但是問題慢慢的暴露了出來，用戶端在暫時我所提供的資料的時候，中文總是顯示亂碼，亂碼，亂碼，一直亂碼。

　　問題的分析路徑

　　1.查看了資料庫連接字串，characterEncoding=utf8 ，配置正常。

　　2.詢問介面調用方，編碼格式一致，utf8。

　　3.查看資料庫編碼格式，utf8，正常。

　　4.查看資料表編碼格式，utf8，正常。

　　然後問題依然存在，中文資料通過查詢指令碼查出來的結果都顯示正常，但是一到網頁上依然是亂碼，亂碼。於是把線上的資料匯出到本地一份，接著觀察，發現中文亂碼處可以看出，一個中文被3個位元組所代替，考慮到utf8編碼格式下，一個中文佔3個位元組，問題的原因初步可以斷定是資料的儲存格類型引起的。然後查閱了Mysql Blob 類型的說明，Blob儲存的其實是位元據，我們來看看Blob的定義：

 

　　BLOB是一個二進位大對象，可以容納可變數量的資料。有4種BLOB類型：TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB。它們只是可容納值的最大長度不同。BLOB 列被視為二進位字串(位元組字串)。BLOB列沒有字元集，並且排序和比較基於列值位元組的數值值。我們再來看看常用的大文本類型Text的定義，這樣能有一個對比。

　　TEXT列被視為非二進位字串(字元字串)，TEXT列有一個字元集，並且根據字元集的校對規則對值進行排序和比較。

 

　　通常Mysql 字元集的配置就告訴了Mysql在執行查詢時所呈現的編碼格式，就拿Blob中儲存的位元據舉例來說：在mysql 控制台執行查詢命令時，控制台自身就幫我們完成了由位元組到文本的轉換，相應地中文也進行了正常的轉換。記得，此處我們強調了mysql控制台，或者說就是我們常用的shell命令，mysql -u *** -p 指令碼執行的控制台環境。位元組——文本的轉換Mysql 控制台按照utf8的編碼格式進行了轉換。  這也是為什麼我們登陸到mysql服務後，mysql -u *** -p 登陸mysql伺服器後，執行查詢指令碼的到正常資料的原因。

 

　　那麼為什麼通過程式串連mysql返回的結果不對呢，是因為java程式串連mysql執行查詢後，Blob類型本身是沒有字元集的，也就不會做根據字元集的校對，所以java串連mysql執行查詢返回的Byte[]位元組數組是沒有經過任何字元集校隊的，即便你存入Blob的資料本身就是符合utf8編碼格式的，最終得到的結果依然會是亂碼，除非你在程式中有相應的處理邏輯。

 

　　好了，到這終於解決了中文亂碼展示的問題，同時也明白了亂碼出現的原因。對Blob類型的認識也更加深刻。

 

　　小提示：如果你的BLOB中儲存的資料原本就是符合utf8編碼格式的，同時你的資料庫以及資料表的編碼格式的符合utf8，那麼欄位類型由BLOB變更為Text類型時，資料時可是保證正常轉換的，當然，別忘記了欄位長度要保持一個量級。這個我自己測試了下，沒有問題。

 

　　

 

著重基礎之—MySql Blob類型和Text類型