初學者往往會犯糊塗，mysql 的預設字符集 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 '***')，寫入和讀取時要記得確保位元組流的編碼是ok的
mysql 的 latin1 中文支援
初學者往往會犯糊塗，mysql 的預設字符集 latin1 是否支援中文？初步分析表明，是的，確實支援中文！是初步的結論，只做了初步的分析 1.先來看看 latin1 latin1 是iso 8859 1的別名，有些環境下寫作latin 1。iso 8859 1 編碼是單位元組編碼 向下相容asci...
MySQL基礎知識 Latin1
latin1是 iso 8859 1的別名，有些環境下寫作latin 1。iso 8859 1 iso 8859 1編碼是單 位元組編碼，向下相容 ascii，其編碼範圍是0x00 0xff，0x00 0x7f之間完全和ascii一致，0x80 0x9f之間是 控制字元，0xa0 0xff之間是文字...
latin1轉gbk的亂碼問題，jdbc的bug
有時候json檔案，純文字的檔案在nginx或者tomcat上為亂碼 可能不像html或者jsp那樣可以設定字元編碼 注意nginx和tomcat都有utf8的配置 另外要注意 檔案也有編碼 linux下用vim開啟 set encoding utf 8 set fileencoding utf 8...