sqlserver中char轉(zhuǎn)化為varchar出現(xiàn)的問題

Users 數(shù)據(jù)庫下 create table other_user ( id int identity ( 1 , 1 ) primary key not null, name varchar ( 30 ), pass varchar ( 30 ), university char ( 20 ), qq char ( 20 )); 這里我讓 id 號自動增加。 我插入第一條數(shù)據(jù)記錄： insert into other_u

Users數(shù)據(jù)庫下

create table other_user (

id int identity(1,1) primary key not null,

name varchar(30),

pass varchar(30),

university char(20),

qq char(20));

這里我讓id號自動增加。

我插入第一條數(shù)據(jù)記錄：insert into other_user values('zhb','123','bnu','8888');作為登錄驗證

我一開始存儲密碼pass，這里是(‘123’),用的是varchar格式的，可以完成登錄驗證；但是后來

我用這條語句alter table other_user alter column pass char(10);

換成了char(10)數(shù)據(jù)類型的時候就不行了，應(yīng)該是用char的時候（定長的原因）出現(xiàn)了多余的空格，所以在rs.getString(“pass”).equals(pass)的時候為false,所以登錄驗證不了。此時的pass是char(10)類型的，更奇怪的是：我將pass的數(shù)據(jù)類型還原成原來的varchar(30)的時候，

alter table other_user alter column pass varchar(30);

再次使用之前的表中的那條記錄進(jìn)行登錄驗證，結(jié)果是登錄不了。這是為什么了？

還沒有結(jié)束，pass的數(shù)據(jù)類型還原之后，我再往表中插入一條數(shù)據(jù)，

insert into other_user values('bhz','321','bnu','8888');

對這條數(shù)據(jù)記錄進(jìn)行登錄驗證就可以了，奇怪了，難道是轉(zhuǎn)換數(shù)據(jù)類型的時候，原來的數(shù)據(jù)所占的空間是不變的（從我這里來看，varchar變成char出現(xiàn)多余的空格，而char變成varchar是不是還保留著原來的空格呢？）。

這里使用char和varchar的時候要小心。

以下是我從其他地方找來的資料，本來想標(biāo)注一下資料的處處，但是看到網(wǎng)上有太多是copy，魚目混雜，也不知道誰是原創(chuàng)的，所以請原創(chuàng)者多多包含，也謝謝你的分享

1．char的長度是固 定的，而VARCHAR2的長度是可以變化的， 比如，存儲字符串“abc"，對于char (20)，表示你存儲的字符將占20個字節(jié)(包括17個空字符)，而同樣的varchar2 (20)則只占用3個字節(jié)的長度，20只是最大值，當(dāng)你存儲的字符小于20時，按實際長度存儲。由于char是以固定長度的，所以它的速度會比 varchar快得多!但程序處理起來要麻煩一點，要用trim之類的函數(shù)把兩邊的空格去掉!

2.char的效率比varchar2的效率稍高。

3．目前VARCHAR是VARCHAR2的同義詞。工業(yè)標(biāo)準(zhǔn)的VARCHAR類型可以存儲空字符串，但是oracle不這樣做，盡管它保留以后這樣做的權(quán)利。Oracle自己開發(fā)了一個數(shù)據(jù)類型VARCHAR2，這個類型不是一個標(biāo)準(zhǔn)的VARCHAR，它將在數(shù)據(jù)庫中varchar列可以存儲空字符串的特性改為存儲NULL值。如果你想有向后兼容的能力，Oracle建議使用VARCHAR2而不是VARCHAR。

何時該用CHAR，何時該用varchar2？
CHAR與VARCHAR2是一對矛盾的統(tǒng)一體，兩者是互補的關(guān)系.
VARCHAR2比CHAR節(jié)省空間，在效率上比CHAR會稍微差一些，即要想獲得效率，就必須犧牲一定的空間，這也就是我們在數(shù)據(jù)庫設(shè)計上常說的‘以空間換效率’。
VARCHAR2 雖然比CHAR節(jié)省空間，但是如果一個VARCHAR2列經(jīng)常被修改，而且每次被修改的數(shù)據(jù)的長度不同，這會引起‘行遷移’(Row Migration)現(xiàn)象，而這造成多余的I/O，是數(shù)據(jù)庫設(shè)計和調(diào)整中要盡力避免的，在這種情況下用CHAR代替VARCHAR2會更好一些。

一般地說，只要一個表有一個字段定義為varchar(n)類型，那么其余用char(n)定義的字段實際上也是varchar(n)類型。

如果你的長度本身不長，比如就3～10個字符，那么使用char(n)格式效率比較高，搜索速度快。但是如果有的數(shù)據(jù)很長，有的數(shù)據(jù)有比較短，比如注冊用戶的簡介這樣的字段，實在沒有辦法，而且很在乎浪費的空間，那么就用varchar(n)格式。

Char,varchar,nvarchar字段是sql server數(shù)據(jù)庫中的三種字段類型。好多人在選擇存儲的時候不知道如何抉擇，我給大家講下這個三個字段類型的區(qū)別。 Char(n)是長度為n個字節(jié)的定長的非unicode的字符數(shù)據(jù)。N為一個介于1到8000之間的值。其存儲大小為輸入數(shù)據(jù)的實際字節(jié)長度，而不是n個字節(jié)。如果你輸入的實際字節(jié)長度少于n,那么其他位置會被空格填充。在數(shù)據(jù)存儲中英文字母和數(shù)字占一個字節(jié)，漢字占兩個字節(jié)。那么char(n)最多可以存儲n個英文字母或數(shù)字，或者n/2個漢字。 Varchar(n)是長度為n 個字節(jié)的可變長度且非 Unicode 的字符數(shù)據(jù)。n 必須是一個介于1 和8,000 之間的數(shù)值。存儲大小為輸入數(shù)據(jù)的字節(jié)的實際長度，而不是 n 個字節(jié)。注意它和char(n)的區(qū)別是char(n)是定長的，varchar(n)是變長的。

如果你輸入的字符的實際字節(jié)長度少于n,那么它的長度就是你實際輸入的字節(jié)長度。在數(shù)據(jù)存儲中英文字母和數(shù)字占一個字節(jié)，漢字占兩個字節(jié)。Varchar(n)最多可以存儲n個英文字母或數(shù)字，或者n/2個漢字。 Nvarchar(n) 包含 n 個字符的可變長度 Unicode 字符數(shù)據(jù)。n 的值必須介于 1 與 4,000 之間。字節(jié)的存儲大小是所輸入字符個數(shù)的兩倍. 在數(shù)據(jù)存儲中英文字母,數(shù)字,漢字都是占兩個字節(jié)。Char(n)最多可以存儲n個英文字母或數(shù)字，或者n個漢字。

在數(shù)據(jù)檢索中，一般來說char型字段的數(shù)據(jù)是最快的，varchar,nvarchar型字段其次。 在所存數(shù)據(jù)長度不一的情況下，varcahr型字段所占空間最少，char,nvarchar其次。 那么到底在什么樣的情況下使用什么樣的數(shù)據(jù)類型那？ 如果你所存數(shù)據(jù)長度基本一致，建議使用char型。這樣檢索速度快，但是提取的時候要注意用trim()函數(shù)剔除所存數(shù)據(jù)兩邊的空格。 如果你所存數(shù)據(jù)長度差異較大，可以使用varchar或者nvarchar。如果你想較好的支持多語言的話，最好使用nvarchar。使用nvarchar可以減少字符轉(zhuǎn)換問題，防止某些情況下亂碼的出現(xiàn)。

說了這么多，大家可能都暈了。列個表供大家參考。 Char(n) Varchar(n) Nvarchar(n) N 最大值 8000 8000 4000 數(shù)據(jù)長度固定（不足用空格填充）可變（實際數(shù)據(jù)長度）可變（實際數(shù)據(jù)長度）可存儲最多英文（數(shù)字） 8000 8000 4000 最多漢字?jǐn)?shù) 4000 4000 4000 英文（數(shù)字）所占字節(jié) 1 1 2 漢字所占字節(jié) 2 2 2 檢索速度快慢慢在去年的一個網(wǎng)站項目中，我使用了sql server數(shù)據(jù)庫，數(shù)據(jù)庫排序規(guī)則為Chinese_PRC_CI_AS.其中部分字段使用varchar型。

我在本機瀏覽數(shù)據(jù)庫中數(shù)據(jù)正常，頁面數(shù)據(jù)顯示正常。但是當(dāng)我將數(shù)據(jù)庫導(dǎo)入到服務(wù)器以后，在客戶端發(fā)現(xiàn)頁面從數(shù)據(jù)庫中讀取的數(shù)據(jù)顯示全是亂碼。我通過查詢分析器連接到服務(wù)器，發(fā)現(xiàn)數(shù)據(jù)庫中的漢字也全變成了亂碼。 我估計服務(wù)器端sql server為英文版，于是將服務(wù)器數(shù)據(jù)庫中varchar型字段都改為nvarchar型，亂碼問題解決。但是同時我又發(fā)現(xiàn)一個奇怪的現(xiàn)象。

比如數(shù)據(jù)庫中有兩個記錄。 表名： ComputerInfo Computer computerType 成都家具廠 私營 合肥家具廠 私營 其中Computer字段為nvarchar型。我用 select * from ComputerInfo where Computer like ‘%成都%’ 返回的記錄數(shù)總是0.奇怪了，明明數(shù)據(jù)庫中有數(shù)據(jù)的嘛。我查閱了大量的資料以后，終于解決了問題。只需要把查詢語句改為select * from ComputerInfo where Computer like N‘%成都%’ 即可。在字符前加N表示將其轉(zhuǎn)化為unicode字符。原文出自：http://www.cnblogs.com/shuang121/archive/2011/03/19/1988794.html

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com