1樓：匿名使用者
資料庫是latin1也可以存入中文的~建立表字段的時候，設定字段字符集為utf-8（utf8 general）就行了
2樓：暮然回首時l燈火已闌珊
latin1格式的表結構欄位不可以放中文,但是latin1格式的資料庫裡面的表結構(字串型別)預設是latin1的,你可以改為utf8或者gbk之類的來存放中文
3樓：夜重生
中文不管用什麼字符集來表示（gbk\gb2312\utf8等），最終都是位元組的整數倍，而latin1或者說iso-8859-1就是滿8byte（整位元組）的編碼方式。無論你傳多少個位元組進去，mysql都可以認為它是乙個或者多個latin字元而已。是不是亂碼取決於讀出來之後的解碼方式，或者說客戶端的處理方式。
客戶端如果知道讀出來的是中文，那麼就會按照中文的方式來嘗試解碼，自然就得不到亂碼，如果按照其它編碼方式來解碼，自然就可能是亂碼。
4樓：匿名使用者
找到my.ini檔案，有個[mysqld]位置下方填入以下就成
character_set_server=utf8
mysql字符集亂碼問題
5樓：愛可生雲資料庫
一、轉碼失敗
在資料寫入到表的過程中轉碼失敗，資料庫端也沒有進行恰當的處理，導致存放在表裡的資料亂碼。
針對這種情況，前幾篇文章介紹過客戶端傳送請求到服務端。
其中任意乙個編碼不一致，都會導致表裡的資料存入不正確的編碼而產生亂碼。
比如下面簡單一條語句：
set @a = "文字字串";
insert into t1 values(@a);
1. 變數 @a 的字元編碼是由引數 character_set_client 決定的，假設此時編碼為 a，也就是變數 @a 的編碼。
2. 寫入語句在傳送到 mysql 服務端之前的編碼由 character_set_connection 決定，假設此時編碼為 b。
3. 經過 mysql 一系列詞法，語法解析等處理後，寫入到表 t1，表 t1 的編碼為 c。
那這裡編碼 a、編碼 b、編碼 c 如果不相容，寫入的資料就直接亂碼。
二、客戶端亂碼
表資料正常，但是客戶端展示後出現亂碼。
這一類場景，指的是從 mysql 表裡拿資料出來返回到客戶端，mysql 裡的資料本身沒有問題。客戶端傳送請求到 mysql，表的編碼為 d，從 mysql 拿到記錄結果傳輸到客戶端，此時記錄編碼為 e（character_set_results）。
那以上編碼 e 和 d 如果不相容，檢索出來的資料就看起來亂碼了。但是由於資料本身沒有被破壞，所以換個相容的編碼就可以獲取正確的結果。
這一類又分為以下三個不同的小類：
1)字段編碼和表一致，客戶端是不同的編碼
比如下面例子， 表資料的編碼是 utf8mb4，而 session 1 發起的連線編碼為 gbk。那由於編碼不相容，檢索出來的資料肯定為亂碼。
2）表編碼和客戶端的編碼一致，但是記錄之間編碼存在不一致的情形
比如表編碼是 utf8mb4，應用端編碼也是 utf8mb4，但是表裡的資料可能一半編碼是 utf8mb4，另外一半是 gbk。那麼此時表的資料也是正常的，不過此時採用哪種編碼都讀不到所有完整的資料。這樣資料產生的原因很多，比如其中一種可能性就是表編碼多次變更而且每次變更不徹底導致（變更不徹底，我之前的篇章裡有介紹）。
舉個例子，表 t3 的編碼之前是 utf8mb4，現在是 gbk，而且兩次編碼期間都被寫入了正常的資料。
3）每個欄位的編碼不一致，導致亂碼
和第二點一樣的場景。不同的是：非記錄間的編碼不統一，而是每個字段編碼不統一。
舉個例子，表 c1 字段 a1,a2。a1 編碼 gbk，a2 編碼是 utf8mb4。那每個字段單獨讀出來資料是完整的，但是所有字段一起讀出來，資料總會有一部分亂碼。
三、latin1
還有一種情形就是以 latin1 的編碼儲存資料
估計大家都知道字符集 latin1，latin1 對所有字元都是單位元組流處理，遇到不能處理的位元組流，保持原樣，那麼在以上兩種存入和檢索的過程中都能保證資料一致，所以 mysql 長期以來預設的編碼都是 latin1。這種情形，看起來也沒啥不對的點，資料也沒亂碼，那為什麼還有選用其他的編碼呢？原因就是對字元儲存的位元組數不一樣，比如 emoji 字元 "❤"，如果用 utf8mb4 儲存，占用 3 個位元組，那 varchar(12) 就能存放 12 個字元，但是換成 latin1，只能存 4 個字元。
總結通過上面的詳細說明，相信對 mysql 亂碼問題已經有乙個很好的了解了。那來回顧下本篇的內容。本篇主要列列舉了 mysql 亂碼可能出現的場景，並對應給出詳細的處理方法以及相關建議，希望以後大家永遠不會出現亂碼問題。
6樓：諸葛亮的很
在連線資料庫伺服器時出現了問題。
說密碼不對。。。
mysql資料庫中存進的是中文，為什麼查出來的亂碼？
7樓：匿名使用者
你的mysql客戶端和你的mysql伺服器的編碼不一樣，，應為utf8編碼的中文是3個字元，而gbk編碼的中文是兩個字元，，這樣解析出來的中文就是亂碼了。。你需要該資料庫的字符集編碼。。。具體如下：
找到mysql 的ini配置檔案
在[client]這裡加上default_character_set = utf8
在[mysqld]這裡加上character_set_server = utf8
不出意外應該可以了
8樓：匿名使用者
開啟資料庫裡看看顯示的是不是亂碼如果不是的話 就是你jsp頁面的編碼問題在頁面的第一行加上<%@ page contenttype="text/html; charset=gb2312"%>或者選擇utf-8
9樓：匿名使用者
mysql設定裡面不支援中文吧.
10樓：匿名使用者
你的系統中毒了，什麼問題你都遇到了。你好強大！
11樓：愛可生雲資料庫
一、轉碼失敗
在資料寫入到表的過程中轉碼失敗，資料庫端也沒有進行恰當的處理，導致存放在表裡的資料亂碼。
針對這種情況，前幾篇文章介紹過客戶端傳送請求到服務端。
其中任意乙個編碼不一致，都會導致表裡的資料存入不正確的編碼而產生亂碼。
比如下面簡單一條語句：
set @a = "文字字串";
insert into t1 values(@a);
變數 @a 的字元編碼是由引數 character_set_client 決定的，假設此時編碼為 a，也就是變數 @a 的編碼。
2. 寫入語句在傳送到 mysql 服務端之前的編碼由 character_set_connection 決定，假設此時編碼為 b。
3. 經過 mysql 一系列詞法，語法解析等處理後，寫入到表 t1，表 t1 的編碼為 c。
那這裡編碼 a、編碼 b、編碼 c 如果不相容，寫入的資料就直接亂碼。
二、客戶端亂碼
表資料正常，但是客戶端展示後出現亂碼。
這一類場景，指的是從 mysql 表裡拿資料出來返回到客戶端，mysql 裡的資料本身沒有問題。客戶端傳送請求到 mysql，表的編碼為 d，從 mysql 拿到記錄結果傳輸到客戶端，此時記錄編碼為 e（character_set_results）。
那以上編碼 e 和 d 如果不相容，檢索出來的資料就看起來亂碼了。但是由於資料本身沒有被破壞，所以換個相容的編碼就可以獲取正確的結果。
這一類又分為以下三個不同的小類：
1)字段編碼和表一致，客戶端是不同的編碼
比如下面例子， 表資料的編碼是 utf8mb4，而 session 1 發起的連線編碼為 gbk。那由於編碼不相容，檢索出來的資料肯定為亂碼。
2）表編碼和客戶端的編碼一致，但是記錄之間編碼存在不一致的情形
比如表編碼是 utf8mb4，應用端編碼也是 utf8mb4，但是表裡的資料可能一半編碼是 utf8mb4，另外一半是 gbk。那麼此時表的資料也是正常的，不過此時採用哪種編碼都讀不到所有完整的資料。這樣資料產生的原因很多，比如其中一種可能性就是表編碼多次變更而且每次變更不徹底導致（變更不徹底，我之前的篇章裡有介紹）。
舉個例子，表 t3 的編碼之前是 utf8mb4，現在是 gbk，而且兩次編碼期間都被寫入了正常的資料。
3）每個欄位的編碼不一致，導致亂碼和第二點一樣的場景。不同的是：非記錄間的編碼不統一，而是每個字段編碼不統一。
舉個例子，表 c1 字段 a1,a2。a1 編碼 gbk，a2 編碼是 utf8mb4。那每個字段單獨讀出來資料是完整的，但是所有字段一起讀出來，資料總會有一部分亂碼。
三、latin1
還有一種情形就是以 latin1 的編碼儲存資料
估計大家都知道字符集 latin1，latin1 對所有字元都是單位元組流處理，遇到不能處理的位元組流，保持原樣，那麼在以上兩種存入和檢索的過程中都能保證資料一致，所以 mysql 長期以來預設的編碼都是 latin1。這種情形，看起來也沒啥不對的點，資料也沒亂碼，那為什麼還有選用其他的編碼呢？原因就是對字元儲存的位元組數不一樣，比如 emoji 字元 "❤"，如果用 utf8mb4 儲存，占用 3 個位元組，那 varchar(12) 就能存放 12 個字元，但是換成 latin1，只能存 4 個字元。
怎樣設定使mysql支援中文的插入？
12樓：秧
mysql只要插入和取出時是同樣的編碼，即便是預設的latin1，都能儲存中文，但檢索會出現問題。 建議使用utf-8編碼。
13樓：仙鵬海
我建議使用gbk，因為utf-8是unicode碼，乙個字元佔四位，這樣定義資料表字段長度的話，你必須定義足夠大的長度，否則插入資料時會報錯
14樓：拱若
mysql安裝目錄下的 my.ini檔案中 default-character-set=utf8
記得採納啊
15樓：手機使用者
1. 安裝mysql的時候,會選擇預設的字符集,請選擇utf-8,因為utf-8才是王道. 2.
如果你不想改字符集,那麼建議你把資料表的字符集改為utf-8或者是gbk,建議utf-8. 3. 如果你不介意資料庫亂碼,在取出資料的時候你可以加上 mysql_query("set names gbk")這樣就可以將亂碼的中文正確顯示.
4. 要避免亂碼,你一定要保證字符集的一致性.從你的資料庫,資料表,以及你輸出的頁面.
盡量使用utf-8. 如果還沒有解決你的問題,你可以自己搜尋解決 關鍵字 mysql 字符集 或者是 mysql 亂碼. 很多答案.
mysql怎麼設定字符集，怎樣設定mysql建立表格時預設的字符集？
mysql set character set client utf8 mysql set character set connection utf8 mysql set character set database utf8 mysql set character set results utf8...
linu下怎麼修改mysql的字符集編碼
設定初始語言就行了啊 這個也是很重要的，否則亂碼 能否看一下my網名呢？這個問題可以幫助搞定一下的哦 mysql資料庫linux怎樣更改server characterset的編碼 mysql怎麼修改表的字符集和編碼 mysql修改表的字符集，可以執行如下sql語句 alter table tb a...
mysql設定字符集為utf8還是中文亂碼
一 轉碼失敗 在資料寫入到表的過程中轉碼失敗，資料庫端也沒有進行恰當的處理，導致存放在表裡的資料亂碼。針對這種情況，前幾篇文章介紹過客戶端傳送請求到服務端。其中任意乙個編碼不一致，都會導致表裡的資料存入不正確的編碼而產生亂碼。比如下面簡單一條語句 set a 文字字串 insert into t1 ...
如何設定Mysql資料庫預設的字符集編碼為GBK
1 更改伺服器的編碼方式，在終端輸入以下命令 mysqld character set server gbk collation server gbk chinese ci 2 更改某個資料庫的編碼方式 mysql u root p alter database character set gbk ...
如何更改Oracle字符集，oracle安裝後怎麼修改字符集
查詢oracle預裝設定 select from v nls parameters 修改字符集編碼 alter database character set internal use zhs16gbk 給你乙個參考連線 oracle安裝後怎麼修改字符集 資料庫字符集在建立後原則上不能更改。不過有2種...