1樓：愛尚實訓_博雅
1）在安裝資料庫的時候指定字符集
2）如果在安裝完了以後可以更改以下檔案：
\mysql目錄\my.ini裡的所有的default-character-set=utf-8
\mysql目錄\data\depot_development\db.opt
default-character-set=utf-8
default-collation=utf-8_chinese_ci
3）建立資料庫的時候：指定字符集型別
create database test
character set 'gbk'
collate 'gbk_chinese_ci";
4）建立表的時候也指定字符集
create table student
(id varchar(40) not null default,
uuseid varchar(40) not null default
)engine=innodb default charset=gbk;
5）設定url的時候
2樓：匿名使用者
首先寫一個資料庫test，然後寫一個表table，最後插入你想要寫入的欄位"工資"。出現了了亂碼。就得
1. 啟動mysql，在裡面輸入 alter database `test` default character set utf8 collate utf8_bin,將test資料庫的編碼設為utf8。
2. 修改表的編碼：alter table `category` default character set utf8 collate utf8_bin 以上命令就是將一個表category的編碼改為utf8 。
3. 修改欄位的編碼：直接在mysql裡右擊表，然後點編輯表，在裡面修改或輸入**：
alter table `test` change `dd` `dd` varchar ( 45 ) character set utf8 collate utf8_bin not null。4.得刪除之前插入的欄位之類的，再重新匯入之前的欄位
3樓：匿名使用者
建庫的時候設定編碼，時刻保證編碼統一
mysql資料庫中存進的是中文，為什麼查出來的亂碼？
4樓：匿名使用者
你的mysql客戶端和你的mysql伺服器的編碼不一樣，，應為utf8編碼的中文是3個字元，而gbk編碼的中文是兩個字元，，這樣解析出來的中文就是亂碼了。。你需要該資料庫的字符集編碼。。。具體如下：
找到mysql 的ini配置檔案
在[client]這裡加上default_character_set = utf8
在[mysqld]這裡加上character_set_server = utf8
不出意外應該可以了
5樓：匿名使用者
呵呵，mysql資料庫編碼是比較複雜的，既然你資料庫中沒有出現亂碼，那就是說從資料庫讀取轉換的時候出現了亂碼。你只說是亂碼，沒有相關資訊，大家沒法幫你解決。所以你首先，開啟mysql控制檯。
輸入： show variebles like 「character_set_%」;然後把得到的資訊，貼出來，我看看問題是出在**了。
6樓：匿名使用者
開啟資料庫裡看看顯示的是不是亂碼如果不是的話 就是你jsp頁面的編碼問題在頁面的第一行加上<%@ page contenttype="text/html; charset=gb2312"%>或者選擇utf-8
7樓：匿名使用者
mysql設定裡面不支援中文吧.
8樓：匿名使用者
你的系統中毒了，什麼問題你都遇到了。你好強大！
9樓：愛可生雲資料庫
一、轉碼失敗
在資料寫入到表的過程中轉碼失敗，資料庫端也沒有進行恰當的處理，導致存放在表裡的資料亂碼。
針對這種情況，前幾篇文章介紹過客戶端傳送請求到服務端。
其中任意一個編碼不一致，都會導致表裡的資料存入不正確的編碼而產生亂碼。
比如下面簡單一條語句：
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 個字元。
10樓：淡淡的雷人生活
首先檢視mysql字符集
show variables like 'character_set%';
修改配置檔案 vim /etc/my.cnf[client]
default-character-set=utf8[mysqld]
character_set_server=utf8
為什麼向資料庫插入中文出現亂碼，mysql資料庫中存進的是中文，為什麼查出來的亂碼？
你的mysql客戶端和你的mysql伺服器的編碼不一樣，應為utf8編碼的中文是3個字元，而gbk編碼的中文是兩個字元，這樣解析出來的中文就是亂碼了。你需要該資料庫的字符集編碼。具體如下 找到mysql 的ini配置檔案 在 client 這裡加上default character set utf8...
jsp寫入mysql資料庫出現亂碼
改承天 這個是你mysql資料庫編碼有問題，你可以使用show variables like character set 先檢視你的資料庫編碼，然後設定編碼不一樣的 set names utf8 夢飛 是不是jsp頁面一提交到後臺就顯示的是亂碼，如果是這個問題建議你參考下這個 網頁連結 看看網頁編碼...
使用PHP向MYSQL資料庫插入中文資料時，頁面中文顯示正常
這個問題不大。主要匯出來是亂碼才問題。你檢查過頁面是不是utf8的沒有，不行最上面加上 header content type text html charset utf 8 好像是utf 8，你可以試試utf8,gb2312總有一個可以的啦。你在資料庫裡看，你在資料庫裡打 set names ut...