varchar、nvarchar及在數據庫中使用unicode的意義
來(lái)源:轉載 日期:2007-3-1 21:52:45 閱讀:139 評論:0
一、varchar[(n)] 和nvarchar(n) 及使用unicode的意義
1.varchar[(n)]
長(cháng)度為 n 個(gè)字節的可變長(cháng)度且非 Unicode 的字符數據。n 必須是一個(gè)介于 1 和 8,000 之間的數值。存儲大小為輸入數據的字節的實(shí)際長(cháng)度，而不是 n 個(gè)字節。所輸入的數據字符長(cháng)度可以為零。varchar 在 SQL-92 中的同義詞為 char varying 或 character varying。
2.nvarchar(n)
包含 n 個(gè)字符的可變長(cháng)度 Unicode 字符數據。n 的值必須介于 1 與 4,000 之間。字節的存儲大小是所輸入字符個(gè)數的兩倍。所輸入的數據字符長(cháng)度可以為零。nvarchar 在 SQL-92 中的同義詞為 national char varying 和 national character varying。
3.什么是Unicode編碼
Unicode（統一碼、萬(wàn)國碼、單一碼）是一種在計算機上使用的字符編碼。它為每種語(yǔ)言中的每個(gè)字符設定了統一并且唯一的二進(jìn)制編碼，以滿(mǎn)足跨語(yǔ)言、跨平臺進(jìn)行文本轉換、處理的要求。1990年開(kāi)始研發(fā)，1994年正式公布。隨著(zhù)計算機工作能力的增強，Unicode也在面世以來(lái)的十多年里得到普及。
2006年6月的最新版本的 Unicode 是 2005年3月31日推出的Unicode 4.1.0 。另外，5.0 Beta已于2005年12月12日推出，以供各會(huì )員評價(jià)。
對于英文來(lái)說(shuō)，ascii碼0-127就足以代碼所有字符，對于中文而言，則必須使用兩個(gè)字節(byte)來(lái)代表一個(gè)字符，具第一個(gè)字節必須大于127(所以我們有許程序判斷中文都是以ascii碼大于127作為條件)
以上用兩個(gè)字節來(lái)表示一個(gè)中文的方式，在習慣上稱(chēng)為雙字節(即DBCS:Double-ByteCharacterSet)，而相對之下，英文的字符碼就稱(chēng)為單字節SBCS(Single-ByteCharacterSet)。
雖然雙字節(DBCS)足以解決中英文字符混合使用情況，但對于不同字符系統而言，必須經(jīng)過(guò)字符碼轉換，非常麻煩。例如：中英文混合情況，日文，韓文等等。
為解決這個(gè)問(wèn)題，Apple,Xerox,Microsoft,IBM,Novell,Borland...很多公司聯(lián)合起來(lái)制訂了一套可以適用于全世界所有國家的字符碼，就稱(chēng)為Unicode
Unicode的特點(diǎn)是：
不管哪一國的字符碼均以?xún)蓚€(gè)Byte表示，例如"A"在Unicode則是16進(jìn)制41和00的組合，即4100，高位41(轉換為Ascii碼即是65=A)，
WindowsNT/2000以Unicode來(lái)表示字符集，例如你可以看到MSSQLServer中產(chǎn)生的SQL文件可以選擇是以Unicode來(lái)保存還是以普通格式來(lái)保存，如果你以Unicode保存，則在95/98平臺許多軟件均無(wú)法正確讀出其格式。
同時(shí)你還可以注意到95/98中API定義，許多名稱(chēng)結尾是有一個(gè)A的，例如
WriteProfileStringA
而在NT/2000操作系統中，提供了兩套API，另外一個(gè)命令是WriteProfileStringW，以W結尾的API只適用于NT/2000。（在NT中使用以W結尾的API函數效率比A結尾的要快，因為省去了Unicode和DBCS/SBCS的轉換過(guò)程）
這樣我們經(jīng)常要用到的判斷字符串長(cháng)度的函數，在NT和95/98下執行結果不同，如下：(下面代碼適合于VB,ASP)
95/98中：
len("abc中國")返回7(因為每個(gè)中文作為兩個(gè)Ascii碼來(lái)看)
nt/2000中：
len("abc中國")返回5(因為每個(gè)字符都作為一個(gè)Unicode來(lái)看)
二、Unicode 的編碼和實(shí)現
大概來(lái)說(shuō)，Unicode 編碼系統可分為編碼方式和實(shí)現方式兩個(gè)層次。
1.編碼方式
Unicode 的編碼方式與 ISO 10646 的通用字元集(亦稱(chēng)[通用字符集])（Universal Character Set，UCS）概念相對應，目前的用于實(shí)用的 Unicode 版本對應于 UCS-2，使用16位的編碼空間。也就是每個(gè)字符占用2個(gè)字節。這樣理論上一共最多可以表示 216 個(gè)字符?；緷M(mǎn)足各種語(yǔ)言的使用。實(shí)際上目前版本的 Unicode 尚未填充滿(mǎn)這16位編碼，保留了大量空間作為特殊使用或將來(lái)擴展。
上述16位 Unicode 字符構成基本多文種平面（Basic Multilingual Plane, 簡(jiǎn)稱(chēng) BMP）。最新（但未實(shí)際廣泛使用）的 Unicode 版本定義了16個(gè)輔助平面，兩者合起來(lái)至少需要占據21位的編碼空間，比3字節略少。但事實(shí)上輔助平面字符仍然占用4字節編碼空間，與 UCS-4 保持一致。未來(lái)版本會(huì )擴充到 ISO 10646-1 實(shí)現級別3，即涵蓋 UCS-4 的所有字符。UCS-4 是一個(gè)更大的尚未填充完全的31位字符集，加上恒為0的首位，共需占據32位，即4字節。理論上最多能表示 231 個(gè)字符，完全可以涵蓋一切語(yǔ)言所用的符號。
BMP 字符的 Unicode 編碼表示為 U+hhhh，其中每個(gè) h 代表一個(gè)十六進(jìn)制數位。與 UCS-2 編碼完全相同。對應的4字節 UCS-4 編碼后兩個(gè)字節一致，前兩個(gè)字節的所有位均為0。
2.實(shí)現方式
Unicode 的實(shí)現方式不同于編碼方式。一個(gè)字符的 Unicode 編碼是確定的。但是在實(shí)際傳輸過(guò)程中，由于不同系統平臺的設計不一定一致，以及出于節省空間的目的，對 Unicode 編碼的實(shí)現方式有所不同。Unicode 的實(shí)現方式稱(chēng)為Unicode轉換格式（Unicode Translation Format，簡(jiǎn)稱(chēng)為 UTF）。
例如，如果一個(gè)僅包含基本7位ASCII字符的 Unicode 文件，如果每個(gè)字符都使用2字節的原 Unicode 編碼傳輸，其第一字節的8位始終為0。這就造成了比較大的浪費。對于這種情況，可以使用 UTF-8 編碼，這是一種變長(cháng)編碼，它將基本7位ASCII字符仍用7位編碼表示，占用一個(gè)字節（首位補0）。而遇到與其他 Unicode 字符混合的情況，將按一定算法轉換，每個(gè)字符使用1-3個(gè)字節編碼，并利用首位為0或1進(jìn)行識別。這樣對以7位ASCII字符為主的西文文檔就大大節省了編碼長(cháng)度（具體方案參見(jiàn)UTF-8）。類(lèi)似的，對未來(lái)會(huì )出現的需要4個(gè)字節的輔助平面字符和其他 UCS-4 擴充字符，2字節編碼的 UTF-16 也需要通過(guò)一定的算法進(jìn)行轉換。
再如，如果直接使用與 Unicode 編碼一致（僅限于 BMP 字符）的 UTF-16 編碼，由于每個(gè)址 加昧肆礁鱟紙冢 贛acintosh機和PC機上對字節順序的理解是不一致的。這時(shí)同一字節流可能會(huì )被解釋為不同內容，如編碼為 U+594E 的字符“奎”同編碼為 U+4E59 的“乙”就可能發(fā)生混淆。于是在 UTF-16 編碼實(shí)現方式中使用了大尾序（big-endian）、小尾序（little-endian）的概念，以及BOM（Byte Order Mark）解決方案。（具體方案參見(jiàn)UTF-16）
此外 Unicode 的實(shí)現方式還包括 UTF-7、Punycode、CESU-8、SCSU、UTF-32等，這些實(shí)現方式有些僅在一定的國家和地區使用，有些則屬于未來(lái)的規劃方式。目前通用的實(shí)現方式是 UTF-16小尾序（BOM）、UTF-16大尾序（BOM）和 UTF-8。在微軟公司W(wǎng)indows XP操作系統附帶的記事本中，“另存為”對話(huà)框可以選擇的四種編碼方式除去非 Unicode 編碼的 ANSI 外，其余三種“Unicode”、“Unicode big endian”和“UTF-8”即分別對應這三種實(shí)現方式。
目前輔助平面的工作主要集中在第二和第三平面的中日韓統一表意文字中，因此包括GBK、GB18030、Big5等簡(jiǎn)體中文、正體中文、日文、韓語(yǔ)以及越南字喃的各種編碼與 Unicode 的協(xié)調性被重點(diǎn)關(guān)注?？紤]到 Unicode 最終要涵蓋所有的字符，從某種意義而言，這些編碼方式也可視作 Unicode 的出現于其之前的既成事實(shí)的實(shí)現方式，如同ASCII及其擴展Latin-1一樣，后兩者的字符在16位 Unicode 編碼空間中的編碼第一字節各位全為0，第二字節編碼與原編碼完全一致。但上述東亞語(yǔ)言編碼與 Unicode 編碼的對應關(guān)系要復雜得多。
三、非 Unicode 環(huán)境
在非 Unicode 環(huán)境下，由于不同國家和地區采用的字符集不一致，很可能出現無(wú)法正常顯示所有字符的情況。微軟公司使用了代碼頁(yè)（Codepage）轉換表的技術(shù)來(lái)過(guò)渡性的部分解決這一問(wèn)題，即通過(guò)指定的轉換表將非 Unicode 的字符編碼轉換為同一字符對應的系統內部使用的 Unicode 編碼?？梢栽?#8220;語(yǔ)言與區域設置”中選擇一個(gè)代碼頁(yè)作為非 Unicode 編碼所采用的默認編碼方式，如936為簡(jiǎn)體中文GBK，950為正體中文Big5（皆指PC上使用的）。在這種情況下，一些非英語(yǔ)的歐洲語(yǔ)言編寫(xiě)的軟件和文檔很可能出現亂碼。而將代碼頁(yè)設置為相應語(yǔ)言中文處理又會(huì )出現問(wèn)題，這一情況無(wú)法避免。從根本上說(shuō)，完全采用統一編碼才是解決之道，但目前上無(wú)法做到這一點(diǎn)。 代碼頁(yè)技術(shù)現在廣泛為各種平臺所采用。UTF-7 的代碼頁(yè)是65000，UTF-8 的代碼頁(yè)是65001。
