展開全部
mysqllatin1資料庫支援中文編碼。
ISO－8859－1編碼是單位元組編碼，向下相容ASCII，其e5a48de588b662616964757a686964616f31333433633432編碼範圍是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位的容器。
如果資料庫内表的字元集是latin1，那麼預設情況下中文也可被支援，latin1覆寫了所有單位元組的值，任何其他的碼流都可以被看做latin1。
把一個gbk編碼的串寫入latin1的表，不會有任何問題，儲存的是原封不動的位元組流，從表中讀取已寫入的串也不會有任何問題，且讀出的位元組流就和當初寫入的完全一緻。
讀取出來以後，如果在終端下，就會了解成locale類型(如果locale系gbk，當時寫入的gbk中文串可正常回顯)
讀取出來以後，如果要寫入檔案，則檔案編碼方式即當時寫入的位元組流編碼，如gbk寫入的，讀出存入檔案後，檔案編碼也是gbk！但是如果混着寫(utf－8＋gbk)，那編輯器就犯蒙了，就可能會顯示會有亂碼。
純文字檔案大多無檔案頭，編輯器是通過位元組流自己識别編碼方式和字元集的
總結，建DB和通路DB時如果都采用預設的latin1，那就不僅僅支援中文，而是支援任意的編碼方式。
擴充資料：
資料庫中文編碼的注意事項：
1．基于可維護的角度，雖然latin1可用，但是還是盡量換成utf8或者gb系列；
2．出現亂碼時：
SHOWVARIABLESLIKE＇character％＇SHOWVARIABLESLIKE＇collation＿％＇；
要保證資料庫中存的資料與資料庫編碼一緻，即資料編碼與character＿set＿database一緻；要保證通訊的字元集與資料庫的字元集一緻，即character＿set＿client，character＿set＿connection與character＿set＿database一緻；
要保證SELECT的傳回與程式的編碼一緻，即character＿set＿results與程式編碼一緻；要保證程式編碼與浏覽器、終端編碼一緻
要想簡單一點，将各個字元集都設為一緻的，寫入mysql的配置檔案，每次用用戶端都設定一下字元集(setnames＇xxx＇)，寫入和讀取時要記得確定位元組流的編碼是正确的。