mysql字符轉化出現亂碼的原因

這篇文章主要介紹“字符轉化出現亂碼的原因”，在日常操作中，相信很多人在mysql字符轉化出現亂碼的原因問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對大家解答”mysql字符轉化出現亂碼的原因”的疑惑有所幫助！接下來(lái)，請跟著(zhù)小編一起來(lái)學(xué)習吧！

mysql中存入數據時(shí)發(fā)生的編碼轉換過(guò)程：
1、在終端(Terminal，可以是bash窗口，也可以是客戶(hù)端工具如navicat)中輸入，輸入的內容由Terminal根據其自己的字符進(jìn)行編碼。
2、經(jīng)Terminal編碼后的二進(jìn)制流被傳輸到mysql server。mysql server(mysql engine)根據參數character_set_client的字符設置來(lái)對該二進(jìn)制流進(jìn)行解碼。
3、解碼之后，mysql server再次根據目的表，即table的字符集來(lái)判斷是否需要字符編碼轉換。如果character_set_client的字符設置和table定義時(shí)的character設置一致，則無(wú)需字符編碼轉換。否則進(jìn)行轉換，然后將轉換后的二進(jìn)制流存放到數據文件(file)中去。
總結：client ------> server(engine) -----> file     需要經(jīng)過(guò)三次編碼，兩次編碼轉化。

mysql中取出數據時(shí)發(fā)生的編碼轉換過(guò)程：
1、從數據文件(file)中讀出二進(jìn)制數據流，將該數據流根據table定義時(shí)的character設置來(lái)進(jìn)行解碼。
2、在用table character對二級制數據流進(jìn)行解碼之后，在mysql engine(mysql server)中，需要根據參數character_set_client的字符集設置對解碼后的數據庫流再一次進(jìn)行編碼，將編碼之后的二級制數據庫流傳輸到client端。
3、client端，即終端(Terminal)根據其自己的字符集編碼來(lái)展示查詢(xún)結果。
總結：  file ------> server(engine) -----> client  需要經(jīng)過(guò)三次編碼，兩次編碼轉化。

可能會(huì )有些疑問(wèn)，在上面的分析中，數據都是以二進(jìn)制流的方式在各個(gè)節點(diǎn)之間流動(dòng)的。那么為什么需要編碼轉化了？
1、client 和 server(engine) 之間的轉換，或者說(shuō)編解碼是為了對傳進(jìn)來(lái)的二進(jìn)制流做語(yǔ)法和詞法解析，否則你不會(huì )知道傳進(jìn)來(lái)的是insert還是update。
2、file 和 server(engine) 之間的轉換是為了在從數據文件讀入數據后，在存儲引擎內部進(jìn)行字符級別的操作。

經(jīng)過(guò)以上分析，應該很快發(fā)現導致亂碼出現的原因是有以下幾種：
1、數據在存入的時(shí)候和取出的時(shí)候，編碼不一致。比如存入時(shí)用的utf8，取出時(shí)用的GBK。
2、編碼轉換不是無(wú)損編碼轉換導致亂碼出現。比如clien是utf8，mysql server中的character_set_client設置為gbk，表結構的字符集設置為utf8。這里會(huì )有兩次編碼轉化，client到server時(shí)，utf8要轉為gbk，然后server到file時(shí)，gbk要轉為utf8。由于gbk到utf8是有損編碼轉化，導致了亂碼出現。

無(wú)損編碼轉換：假設我們要把用編碼A表示的字符X，轉化為編碼B的表示形式，而編碼B的字形集中并沒(méi)有X這個(gè)字符，那么此時(shí)我們就稱(chēng)這個(gè)轉換是有損的。
但不是任何兩種字符集編碼之間的轉換都是有損，轉換是否有損取決于以下幾點(diǎn)：
------被轉換的字符是否同時(shí)在兩個(gè)字符集中
------標字符集是否能夠對不支持字符，保留其原有表達形式。(比如latin1在遇到自己無(wú)法表示的字符時(shí)，會(huì )保留原字符集的編碼數據，并跳過(guò)忽略該字符進(jìn)而處理后面的數據。)

因此只要客戶(hù)端，MySQL Server的character-set-client，table charset的三個(gè)字符集完全一致就可以保證一定不會(huì )有亂碼出現了。