資料庫中文

⑴ Mysql資料庫中的中文亂碼如何解決

mysql數據亂碼問題可能有以下三種原因:
1.server本身設定問題，例如還停留在latin1版本;
2.table的語系設定問題(包含character與collation);
3.客戶端程式(例如php,java)的連線語系設定問題;
建議使用utf8!!!!

想要避免mysql的中文亂碼問題,可以嘗試以下方法：
1,對於版本問題，建議去官網更新最新的版本或者比較好用的版本；

2,創建資料庫，創建表時沒有對字元編碼進行設定會造成亂碼問題:

創建資料庫的時候：CREATE DATABASE `test`
CHARACTER SET 'utf8'
COLLATE 'utf8_general_ci';

建表的時候 CREATE TABLE `database_user` (
`ID` varchar(40) NOT NULL default '',
`UserID` varchar(40) NOT NULL default '',
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

3,對於第三種情況,參考一下方法:
編輯linux伺服器中/etc/my.cnf文件,在[mysql]段加入default_character_set=utf8;
如果只是調試遇到亂碼問題:
在編寫Connection URL時，加上?useUnicode=true&characterEncoding=utf-8參數;
並且在網頁代碼中加上一個"set names utf8"或者"set names gbk"的指令，告訴MySQL連線內容都要使用utf-8或者gbk。
utf8或者gbk;

⑵ 資料庫里中文也是一個位元組長度

不同的編碼方式，所需的佔用空間不同。

latin1:

1character=1byte,1漢字=2character,

也就是說一個欄位定義成 varchar(200)，則它可以存儲100個漢字或者200個字母。

這一點要注意，尤其是當欄位內容是字母和漢字組成時，盡量假設欄位內容都是由漢字組成，據此來設置欄位長度

utf8:

1character=3bytes, 1漢字=1character

也就是說一個欄位定義成 varchar(200)，則它可以存儲200個漢字或者200個字母。

gbk:

1character=2bytes,1漢字=1character

也就是說一個欄位定義成 varchar(200)，則它可以存儲200個漢字或者200個字母。

請採納！

⑶ MySQL 中如何存中文

MySQL 中何存中文方法如下：

1、create table的時候加上：ENGINE=InnoDB DEFAULT CHARSET=gbk;

例如：

CREATE TABLE t_department (

sid varchar(32) NOT NULL,

pid varchar(32) NOT NULL,

thedata varchar(50) NOT NULL

ENGINE=InnoDB DEFAULT CHARSET=gbk;

2、打開MySQL目錄下的my.ini文件，把裡面所有的default-character-set選項設為GBK或者GB2312，保存後重啟MySQL。

⑷ mysql資料庫表裡中文亂碼應該選哪種編碼

資料庫中關於字元集的種類有很多,個人建議,資料庫字元集盡量使用utf8(utf-8),以使你的數據能很順利的實現遷移,因為utf8字元集是目前最適合於實現多種不同字元集之間的轉換的字元集,盡管你在命令行工具上無法正確查看資料庫中的內容,我依然強烈建議使用utf8作為默認字元集.如果你想使用gb2312編碼,那麼建議你使用latin1作為數據表的默認字元集,這樣就能直接用中文在命令行工具中插入數據,並且可以直接顯示出來.而不要使用gb2312或者gbk等字元集,如果擔心查詢排序等問題,可以使用binary屬性約束 對編程有影響的主要是客戶端字元集和資料庫字元集（還有一個伺服器字元集，不知道干什麼用的), 資料庫中常用的操作就是保存數據和讀取數據，在這過程中，亂不亂碼和資料庫字元集貌似沒有什麼關系。我們只要保證寫入時選擇的字元集和讀取時選擇的字元集一致，即只需保證兩次操作的客戶端字元集一致即可。 x0dx0a在MySQL的客戶端上執行一次查詢的過程一般是，在客戶端的提示符後面輸入一條SQL語句，回車，然後終端顯示出查詢的結果。這個過程中，只有終端和三個MySQL的系統變數指定了正確的字元集，才能保證我們將一個正確的SQL語句送到伺服器，然後伺服器返回正確的結果，並且在終端正確顯示。 x0dx0a三個MySQL的系統變數是： x0dx0a1. character_set_client，終端字元集，告訴Server客戶端提交的SQL語句的編碼格式 x0dx0a2. character_set_connection，連接字元集，是伺服器翻譯SQL語句時用到的編碼格式 x0dx0a3. character_set_results，返回的結果集的字元集，是伺服器返回結果集之前把結果集轉換成的編碼格式 x0dx0a在MySQL終端通過執行命令 show variables like 『char%』 可以查看這幾個變數的值。這三個變數通常都設定為同一種字元集，用命令set names [charset name]就可以修改這三個變數的值。一般來說，只要你設定了能夠表示你的數據的字元集，你查詢的結果都可以在終端正確顯示。 x0dx0a舉個例子，使用的表t1是utf8編碼，表中的欄位c1繼承了這個編碼，表創建如下 x0dx0amysql> create table t1 ( c1 text not null ) character set utf8; x0dx0a用的字元是漢字「范」，gbk編碼為B7 B6，utf8編碼為E8 8C 83 x0dx0a用下面的SQL語句插入數據 x0dx0amysql> insert into t1 values( 『范』); x0dx0aa）如果終端設置為utf8，並且執行了 set names utf8，那麼插入到資料庫中的就是「范」這個字的utf8編碼，這個過程中MySQL不需要做編碼轉換。寫入資料庫的內容可以通過執行 select hex( c1 ) from t1 得到數據的十六進制編碼來驗證。 x0dx0ax0dx0ab）如果終端設置為 utf8，並且執行了set names gbk，那麼執行完這個插入操作後，寫入的二進制數據是E9 91 BC，這是「漢字「鑼」的utf8編碼。這是因為，終端輸入的「范」用的是utf8編碼，而伺服器以為終端發送過來的內容是gbk編碼，所以在向t1表中插入的時候進行了一次gbk到utf8的轉換，結果當然是錯誤的。 x0dx0ax0dx0ac）如果終端設置為gbk，並且執行了set names gbk，那麼執行完插入操作後，寫入t1的依然是「范」這個字的utf8編碼。插入過程中，終端輸入的是「范」的gbk編碼B7 B6，伺服器被告知終端發過來的SQL語句是gbk編碼（由character_set_client指定），所以在插入數據前做了一次gbk到utf8的編碼轉換。 x0dx0ax0dx0ad）如果終端設置為gbk，並且執行了set names utf8，那麼執行完插入操作後，MySQL會報出一個數據被截斷的警告。實際上，輸入終端的是「范」這個字元的gbk編碼B7 B6，而伺服器被告知客戶端發過來的SQL語句是utf8編碼，所以在執行過程中沒有做轉碼，直到插入數據的時候，發現B7 B6不符合utf8的編碼規則，給出了警告信息，實際插入的數據是3F 3F，也就是兩個問號。 x0dx0ax0dx0a查詢的時候是同樣的道理，MySQL也是根據set names設定的字元集來對返回給客戶端的結果集做相應的編碼轉換，如果轉換的結果和終端顯示的字元集一致，就能正確顯示，如果不一致就是亂碼。 x0dx0ax0dx0a結論是，只要終端的字元集和set names指定的字元集一致就可以讓MySQL在處理過程中執行正確的轉碼並且正確地顯示。 x0dx0ax0dx0a另外，如果通過程序操作MySQL資料庫， 那麼也需要事先執行set names命令來指定程序希望輸出的字元集。比如，用程序從一個utf8編碼的資料庫向另外一個gbk編碼的資料庫進行數據遷移，在選取源資料庫數據之前，需要執行set names gbk，才能取到gbk編碼的數據。

⑸ oracle資料庫里中文顯示不出來是怎麼回事

資料庫編碼字元集設置的不對。

資料庫碼就是資料庫編程語言中的代碼。流行的關系資料庫系統都支持資料庫字元集編碼，也就是說在創建資料庫時可以指定它自己的字元集設置，資料庫的數據以指定的編碼形式存儲。

當應用程序訪問數據時，在入口和出口處都會有字元集編碼的轉換。對於中文數據，資料庫字元編碼的設置應當保證數據的完整性。

GB2312、GBK、UTF-8等都是可選的資料庫字元集編碼;當然我們也可以選擇。ISO8859-1(8-bit)，只是我們得在用程序寫數據之前先將16Bit的一個漢字或Unicode拆分成兩個8-bit的字元，讀數據之後也需要將兩個位元組合並起來，同時還要判別其中的SBCS字元。

字元編碼也稱字集碼，是把字元集中的字元編碼為指定集合中某一對象（例如：比特模式、自然數序列、8位組或者電脈沖），以便文本在計算機中存儲和通過通信網路的傳遞。

常見的例子包括將拉丁字母表編碼成摩斯電碼和ASCII。其中，ASCII將字母、數字和其它符號編號，並用7比特的二進制來表示這個整數。通常會額外使用一個擴充的比特，以便於以1個位元組的方式存儲。

在計算機技術發展的早期，如ASCII（1963年）和EBCDIC（1964年）這樣的字元集逐漸成為標准。但這些字元集的局限很快就變得明顯，於是人們開發了許多方法來擴展它們。

對於支持包括東亞CJK字元家族在內的寫作系統的要求能支持更大量