初學者往往會犯糊塗，mysql 的預設字符集 latin1 是否支援中文？ 

初步分析表明，是的，確實支援中文！(是初步的結論，只做了初步的分析)

1. 先來看看latin1 (參考百度百科)

　　Latin1是ISO-8859-1的別名，有些環境下寫作Latin-1。

　　ISO-8859-1編碼是單位元組編碼，向下相容ASCII，其編碼範圍是0x00-0xFF，0x00-0x7F之間完全和ASCII一致，0x80-0x9F之間是控制字元，0xA0-0xFF之間是文字元號。

　　ISO-8859-1收錄的字元除ASCII收錄的字元外，還包括西歐語言、希臘語、泰語、阿拉伯語、希伯來語對應的文字元號。歐元符號出現的比較晚，沒有被收錄在ISO-8859-1當中。

　　因為ISO-8859-1編碼範圍使用了單位元組內的所有空間，在支援ISO-8859-1的系統中傳輸和儲存其他任何編碼的位元組流都不會被拋棄。換言之，把其他任何編碼的位元組流當作ISO-8859-1編碼看待都沒有問題。這是個很重要的特性，MySQL資料庫預設編碼是Latin1就是利用了這個特性。ASCII編碼是一個7位的容器，ISO-8859-1編碼是一個8位的容器。

2. 稍微再想想字符集

    是的，不用糾結太多了，如果資料庫內表的字符集是latin1，那麼預設情況下中文也可被支援！

    · latin1覆蓋了所有單位元組的值，任何其他的碼流都可以被看做latin1

    · 把一個gbk編碼的串寫入latin1的表，不會有任何問題，儲存的是原封不動的位元組流

    · 從表中讀取已寫入的串也不會有任何問題，且讀出的位元組流就和當初寫入的完全一致

讀取出來以後，如果在終端下，就會理解成locale型別（如果locale系gbk，當時寫入的gbk中文串可正常回顯）

讀取出來以後，如果要寫入檔案，則檔案編碼方式即當時寫入的位元組流編碼，如gbk寫入的，讀出存入檔案後，檔案編碼也是gbk！但是如果混著寫（utf-8 + gbk），那編輯器就犯蒙了，就可能會顯示會有亂碼。

注: 純文字檔案大多無檔案頭，編輯器是通過位元組流自己識別編碼方式和字符集的

3. 綜上，建DB和訪問DB時如果都採用預設的latin1，那就不僅僅支援中文，而是支援任意的編碼方式

附送幾個資料庫中文編碼的經驗教訓：

1. 基於可維護的角度，雖然latin1沒什麼問題，但是還是儘量換成utf8或者gb系列

2. 出現亂碼時：

SHOW VARIABLES LIKE 'character%'
SHOW VARIABLES LIKE 'collation_%';

a、要保證資料庫中存的資料與資料庫編碼一致，即資料編碼與character_set_database一致；
b、要保證通訊的字符集與資料庫的字符集一致，即character_set_client, character_set_connection與character_set_database一致；
c、要保證SELECT的返回與程式的編碼一致，即character_set_results與程式編碼一致；
d、要保證程式編碼與瀏覽器、終端編碼一致

3. 要想簡單一點的話，就將各個字符集都設為一致的，寫入mysql的配置檔案，每次用客戶端都設定一下字符集(set names 'xxx')，寫入和讀取時要記得確保位元組流的編碼是ok的