1、選擇ORACLE數(shù)據(jù)庫字符集如何選擇數(shù)據(jù)庫的字符集是一個有爭議的話題，字符集本身涉及的范圍專門廣，它與應(yīng)用程序、客戶的本地環(huán)境、操作系統(tǒng)、服務(wù)器等關(guān)系專門緊密，因此要做出合適的 選擇，需要明白這些因素之間的關(guān)系。另外對字符集的差不多概念，ORACLE數(shù)據(jù)庫字符集的一些知識也需要了解。 隨著國內(nèi)的軟件產(chǎn)品逐步走向海外，關(guān)于多語言的支持差不多成為軟件的一個差不多要求，采納UNICODE標(biāo)準(zhǔn)也逐漸成為通用的設(shè)計方案，現(xiàn)在ORACLE數(shù)據(jù) 庫的字符集應(yīng)該如何選擇？專門多人都有自己的見解，在網(wǎng)上也能夠看到專門多關(guān)于字符集的文章。這些文章有專門多精華值得去學(xué)習(xí)，然而另一方面還存在一些錯誤，尤 其對UNIC

2、ODE，存在一些概念不清的地點。 數(shù)據(jù)庫字符集的選擇并不存在絕對意義上的正確或錯誤，每種字符集都有它適用的環(huán)境。關(guān)于我們來講，了解得越多，越能關(guān)心自己做出適當(dāng)?shù)剡x擇，而且能夠采取 措施去主動防范或規(guī)避可能出現(xiàn)的問題。反之，假如數(shù)據(jù)庫字符集選擇不恰當(dāng)，會給后面的工作帶來專門多的苦惱，需要花費專門多時刻和精力去解決問題，有些問題甚 至?xí)璧K到客戶的業(yè)務(wù)使用。本文希望能夠給大伙兒提供一些相對全面的知識，方便大伙兒了解數(shù)據(jù)庫字符集的相關(guān)概念，因此有些繁瑣，請大伙兒見諒。另外由于個人的 局限，有何不妥之處還請大伙兒不吝指正。下面我們由淺入深，先由概念入手，再給出幾種常用的字符集設(shè)置建議，對一些可能遇到的

3、問題做出分析，最后給出自己的建議。 1、字符集的一些差不多知識 講到數(shù)據(jù)庫的字符集設(shè)置，首先需要對字符集的知識有些了解。以下是字符集的差不多知識介紹：由于計算機(jī)只能存儲使用二進(jìn)制數(shù)據(jù)，因此關(guān)于一些字符或符號，需要對它們進(jìn)行編碼，用編碼后的數(shù)值來表示這些字符。關(guān)于一組符號的編碼集合確實是字符集。 字符集有專門多種，最初的字符集是ASCII，它用一個字節(jié)中的7位來表示128個字符，第8位沒有使用。它包括大小寫字母、數(shù)字0-9、標(biāo)點符號、非打印 字符（換行符、制表符等4個）以及操縱字符（退格、響鈴等）等。由于ASCII支持的字符專門有限，因此隨后又出現(xiàn)了專門多的編碼方案，這些編碼方案大部分都 是包括

4、了ASCII的，它們只是做了擴(kuò)展，這些擴(kuò)展的內(nèi)容一般各不相同，因此講ASCII是一個比較差不多的編碼，EBCDIC編碼是另一個比較差不多的編 碼，它的部分字符采納了和ASCII不同的編碼值，因此兩者是不兼容的差不多編碼方案。采納EBCDIC編碼的比較少，目前要緊是IBM 的系統(tǒng)采納，如AS400及S390系統(tǒng)，大部分的系統(tǒng)差不多上基于ASCII編碼的。 由于亞洲國家的字符集相對復(fù)雜一些，因此一般都使用了兩個及以上的字節(jié)進(jìn)行編碼的方案。關(guān)于簡體中文，GB2312碼是國家1981年實施的編碼標(biāo)準(zhǔn)，通 行于大陸。新加坡等地也使用此編碼。GBK編碼是GB2312碼的擴(kuò)展，是1995年公布的指導(dǎo)性規(guī)范，

5、它在字匯一級支持 ISO/IEC 10646-1 和GB 13000-1 的全部中日韓 (CJK) 漢字(20902字)。目前最新的漢字字符集是2000年的GB18030，它是取代GBK1.0的正式國家標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)收錄了27484個漢字，同時還 收錄了藏文、蒙文、維吾爾文等要緊的少數(shù)民族文字。目前簡體WINDOWS的缺省內(nèi)碼依舊GBK，能夠通過GB18030升級包升級到GB18030。不 過GB18030相對GBK增加的字符，一般人是專門難用到的，因此GBK依舊我們目前最常用的簡體中文字符集。 由于編碼方案太多且彼此之間不兼容，存在互相之間存在沖突的情況，即關(guān)于同一個編碼數(shù)值，在兩種不同的編碼

6、方案中代表的是兩個不同的字符。如此關(guān)于一些 WEB應(yīng)用來講，由于多種語言文字的同時使用及存儲，需要采納一種統(tǒng)一的字符集。為此，國際標(biāo)準(zhǔn)化組織(ISO)制定了ISO 10646碼表，而Unicode協(xié)會制定了Unicode規(guī)范，這兩個體系剛開始時是獨立建立的，在1991年，雙方都認(rèn)識到世界不需要兩個不兼容的字 符集。因此它們開始合并雙方的工作成果，并為創(chuàng)立一個單一編碼表而協(xié)同工作。從Unicode2.0開始，Unicode項目采納了與ISO 10646-1相同的字庫和字碼。目前兩個項目仍都存在，并獨立地公布各自的標(biāo)準(zhǔn)。Unicode協(xié)會現(xiàn)在的最新版本是2006年的Unicode 5.0。ISO的

7、最新標(biāo)準(zhǔn)是10646-3:2003。下面簡單介紹一下幾種常見的編碼方式： UCS(Universal Character Set)是按ISO-10646定義的字符集，有兩種最常用編碼方式： UCS-2和UCS-4。 UCS-2：使用0-65535之間的數(shù)表示一個unicode字符。UCS-2無法表示所有的unicode字符，只能表示其前65536個字符（稱為 Basic Multilingual Plane，BMP）。我們一般經(jīng)常使用的UNICODE碼確實是指那個編碼方案。 UCS-4:使用0-FFFFFFFF之間的數(shù)表示一個unicode字符，但為了和unicode體系兼容(unicode體

8、系是一個20bit系 統(tǒng)），ISO-10646表示所有定義的字符將不超過10FFFF。UCS-4能夠表示所有的unicode字符。Unix 下使用 UCS-2/UCS-4會導(dǎo)致特不嚴(yán)峻的問題，因為有一些專門的字符, 比如 0 或 /, 它們在文件名和其他C的庫函數(shù)參數(shù)里都有特不的含義，C語言使用0作為字符串結(jié)尾，而Unicode里恰恰有專門多字符都有一個字節(jié)為0，如此一 來，C語言的字符串函數(shù)將無法正常處理Unicode，除非把世界上所有用C寫的程序以及他們所用的函數(shù)庫全部換掉 。 為了解決那個問題，因此產(chǎn)生了將Unicode編碼規(guī)則和計算機(jī)的實際編碼對應(yīng)起來的一個規(guī)則，UTF,英文為UCS

9、Transformation Format，即UCS轉(zhuǎn)換格式，目前常用的有UTF-8、UTF-16、UTF-32三種。（還有UTF-7在此就不介紹了）。正如名字所示，它們分不 使用8位、16位、32位比特對UCS進(jìn)行編碼。 UTF-8：一種變長的Unicode編碼方式，使用1到4個字節(jié)表示一個字符。這種方式的最大好處，是UTF8保留了ASCII字符的編碼作為它的一 部分，因此在ASCII表示的128個字符在UTF-8的編碼沒有變化，它的兼容性比較好。UTF-8在目前WEB應(yīng)用上使用專門廣泛。 UTF-16:一種變長Unicode編碼方式，使用兩個或者四個字節(jié)表示一個字符。這種編碼方式比較節(jié)約空

10、間，因為它把最常使用的字符都用兩個字節(jié)來表示，而那些不常用的字節(jié)則用兩個或四個字節(jié)來表示。但關(guān)于英文字符來講，它要用兩個字節(jié)來編碼。 UTF-32:一種固定長度的Unicode編碼方式，使用四個字節(jié)表示一個字符，它適用在內(nèi)存專門充足，需要定長的編碼場合。 2、ORACLE數(shù)據(jù)庫的字符集 ORACLE的字符集名字一般由以下部分組成：語言或區(qū)域、表示一個字符的比特位數(shù)、標(biāo)準(zhǔn)字符集名稱（可選項，S或C，表示服務(wù)器或客戶端）。ORACLE字符集UTF8與UTFE不符合此規(guī)定，其它差不多差不多上這種格式。 關(guān)于US7ASCII，表示區(qū)域是US，用7個比特位表示一個字符，標(biāo)準(zhǔn)的字符集名稱為ASCII。 關(guān)

11、于中文字符集ZHS16GBK，表示簡體中文（ZHT為繁體中文），一個字符需要16位比特，標(biāo)準(zhǔn)的字符集名稱為GBK。而 ZHS16CGB231280表示簡體中文，一個字符需要16位比特，標(biāo)準(zhǔn)的字符集名稱為GB231280，屬于我們前面提過的1981年公布的 GB231280標(biāo)準(zhǔn)。盡管我們講，GBK編碼標(biāo)準(zhǔn)是GB2312編碼標(biāo)準(zhǔn)的擴(kuò)展，然而數(shù)據(jù)庫字符集ZHS16GBK與ZHS16CGB231280之 間卻不是嚴(yán)格的超集與子集的關(guān)系，要緊是有些漢字的編碼在兩個字符集中的數(shù)值是不同的，因此它們進(jìn)行字符集轉(zhuǎn)換時會出現(xiàn)問題。 在本文中，有時候使用的是標(biāo)準(zhǔn)字符集名稱，有時候又需要使用ORACLE字符集的名稱

12、，因此希望大伙兒明白兩者之間的對應(yīng)關(guān)系。 ORACLE數(shù)據(jù)庫有國家字符集（national character set）與數(shù)據(jù)庫字符集(database character set)之分。兩者差不多上在創(chuàng)建數(shù)據(jù)庫時需要設(shè)置的。國家字符集要緊是用于NCHAR、NVARCHAR、NCLOB類型的字段數(shù)據(jù)，而數(shù)據(jù)庫字符集使用專門 廣泛，它用于：CHAR、VARCHAR、CLOB、LONG類型的字段數(shù)據(jù)；表名、列名、PL/SQL中的變量名；輸入及保存在數(shù)據(jù)庫的SQL和PL /SQL的源碼。 ORACLE支持的Unicode字符集有以下幾種，下面的列表給出了字符集的名稱、對應(yīng)的數(shù)據(jù)庫版本范圍、采納的Un

13、icode的版本。 字符集 對應(yīng)的數(shù)據(jù)庫版本范圍 Unicode的版本 字符集 對應(yīng)的數(shù)據(jù)庫版本范圍 Unicode的版本 AL24UTFFSS 7.2-8.1 1.1 UTF8 8.0-10g 2.1 (8.0-8.1.6) 3.0 (8.1.7-10g) UTFE 8.0-10g 2.1 (8.0-8.1.6) 3.0 (8.1.7-10g) AL32UTF8 9.0-10g 3.0 (9.0) 3.1 (9.2) 3.2 (10.1) 4.01(10.2) AL16UTF16 9.0-10g 3.0 (9.0) 3.1 (9.2) 3.2 (10.1) 4.01(10.2) AL24UT

14、FFSS：是ORACLE第一種支持Unicode的字符集，從7.2版本開始使用，然而它支持的Unicode版本為1.1，因此從9i開始就不支持此字符集了。 UTF8:是ORACLE從ORACLE8開始使用的屬于UTF-8編碼的字符集，從ORACLE8.0到ORACLE8.16，Unicode版本為2.1，而ORACLE817到10g，采納的Unicode標(biāo)準(zhǔn)為3.0 UTFE：用于EBCDIC碼平臺上的數(shù)據(jù)庫Unicode字符集。因此它屬于專用系統(tǒng)使用的字符集，其它屬性與UTF8差不多相同。 AL32UTF8：是從ORACLE9開始使用的屬于UTF-8編碼的字符集，與UTF8相比，它采納的Un

15、icode版本更新，在10g版本中使用的是 Unicode 4.01標(biāo)準(zhǔn)，而UTF8因為兼容性的考慮，在10g版本中用的是Unicode 3.0標(biāo)準(zhǔn)。 AL16UTF16：是ORACLE第一種采納UTF-16編碼方式的字符集，從ORACLE9開始使用，是作為缺省的國家字符集使用，它不能被用作數(shù)據(jù) 庫的字符集。這是因為數(shù)據(jù)庫的字符集決定了SQL與PL/SQL源碼的編碼方式，關(guān)于UTF16這種使用固定的兩個字節(jié)來表示英文字母的編碼方案來講， 確實不適于用作數(shù)據(jù)庫的字符集，ORACLE目前采納的數(shù)據(jù)庫字符集差不多上基于ASCII或EBCDID作為子集的編碼方案。 從以上幾種字符集的介紹來看，Unic

16、ode字符集一般使用UTF8和AL32UTF8。假如數(shù)據(jù)庫版本都在9i及其以上，不需要考慮ORACLE8的數(shù) 據(jù)庫，建議使用AL32UTF8字符集，它采納的Unicode標(biāo)準(zhǔn)要比UTF8采納的Unicode標(biāo)準(zhǔn)更新，支持的字符也更多一些。假如要考慮 ORACLE8數(shù)據(jù)庫，建議使用UTF8字符集，它的兼容性好，在ORACLE8及8I數(shù)據(jù)庫上使用AL32UTF8字符集容易出現(xiàn)問題。 3、如何選擇合適的數(shù)據(jù)庫字符集 前面我們介紹了字符集的一些概念，并對ORACLE數(shù)據(jù)庫的常用幾個字符集有了一些了解，下面就具體對數(shù)據(jù)庫字符集的選擇闡述一些個人的觀點： 3.1、數(shù)據(jù)庫需要存儲的數(shù)據(jù)類型是字符集選擇的首要

17、考慮目標(biāo)。 由于數(shù)據(jù)庫的要緊功能在于存儲數(shù)據(jù)，因此要保證數(shù)據(jù)的正確性。采納何種數(shù)據(jù)庫字符集需要看存儲數(shù)據(jù)是何種類型的。關(guān)于只存儲英文信息的數(shù)據(jù)庫等來講，一般 采納US7ASCII或WE8ISO8859P1等單字節(jié)的字符集就比較合適，在性能和空間上也是最優(yōu)，假如采納ZHS16GBK編碼，盡管能夠使用，但 從數(shù)據(jù)庫字符集本身的含義來講，屬于不恰當(dāng)?shù)倪x擇。同樣，存儲了中文信息的數(shù)據(jù)庫，假如采納單字節(jié)的字符集，也是不合適的。在這種情況下，數(shù)據(jù)庫的字符集 盡管是US7ASCII或WE8ISO8859P1編碼，但里面存儲的數(shù)據(jù)編碼實際上卻是另外的編碼格式，這種不一致的情況專門容易引起問題，建議不要如此 使

18、用。ORACLE提供了專門多種類的字符集供客戶選擇，確實是要滿足各種文字不同的編碼需要。 3.2、字符集的選擇需要優(yōu)先考慮應(yīng)用程序的需要。 目前出于國際化的需要，軟件需要能夠?qū)Σ煌恼Z言文字進(jìn)行處理，尤其一個系統(tǒng)中需要容納多種語言文字的時候，一般都會采納Unicode如此的通用解決方 案，即使會有一些空間和運行效率的損失也是值得的?，F(xiàn)在數(shù)據(jù)庫字符集建議能夠采納AL32UTF8或UTF8編碼，一種比較理想的模式確實是由程序負(fù)責(zé)編碼 格式的轉(zhuǎn)換，而數(shù)據(jù)庫只提供一個透明的數(shù)據(jù)存儲； 客戶在應(yīng)用程序中輸入數(shù)據(jù)，現(xiàn)在數(shù)據(jù)的編碼格式是由客戶操作系統(tǒng)的區(qū)域及語言設(shè)置決定的，如在簡體中文XP的環(huán)境下，輸入的中

19、文編碼屬于GBK編碼。在客 戶輸入結(jié)束后，程序首先推斷客戶的本地環(huán)境，并把編碼轉(zhuǎn)換成UNICODE，并通過NET傳送到服務(wù)器端。由于客戶端與服務(wù)器數(shù)據(jù)庫的字符集均為UTF8 格式，ORACLE在傳送過程中可不能進(jìn)行字符轉(zhuǎn)換，直接把數(shù)據(jù)按UTF8格式存儲到數(shù)據(jù)庫中。查詢時是一個反向的過程，應(yīng)用程序從數(shù)據(jù)庫中取出UTF8編 碼的數(shù)據(jù)，再由應(yīng)用程序依照客戶的本地環(huán)境，把UTF8編碼的數(shù)據(jù)轉(zhuǎn)換成客戶本地的編碼格式，最后把結(jié)果數(shù)據(jù)顯示給客戶。此方案的關(guān)鍵在于應(yīng)用程序要能專門 好的支持UNICODE編碼，編碼的轉(zhuǎn)換由應(yīng)用程序來負(fù)責(zé)，數(shù)據(jù)庫只是提供了一個數(shù)據(jù)存儲功能。 關(guān)于部分程序來講，由于對UNICODE

20、支持不夠，沒有提供編碼的轉(zhuǎn)換功能，則能夠使用ORACLE提供的字符集轉(zhuǎn)換功能來實現(xiàn)同樣的目的。 客戶在應(yīng)用程序中輸入數(shù)據(jù)，現(xiàn)在數(shù)據(jù)的編碼格式是由客戶操作系統(tǒng)的區(qū)域及語言設(shè)置決定的，如在簡體中文XP的環(huán)境下，輸入的中文編碼屬于GBK編碼。在客 戶輸入結(jié)束后，程序直接把數(shù)據(jù)并通過NET傳送到服務(wù)器端。由于客戶端與服務(wù)器數(shù)據(jù)庫的字符集不一致，因此ORACLE會把客戶端的編碼轉(zhuǎn)換成UTF8格 式，再把數(shù)據(jù)按UTF8格式存儲到數(shù)據(jù)庫中。這種方案的優(yōu)點確實是程序能夠不用支持UNICODE，由ORACLE數(shù)據(jù)庫自動進(jìn)行轉(zhuǎn)換。由于數(shù)據(jù)庫的字符集 為UTF8，是其它字符集的超集，因此在轉(zhuǎn)換過程中可不能發(fā)生數(shù)據(jù)丟

21、失的情況。關(guān)于英文的字符符號，在UTF8中使用單字節(jié)存儲，轉(zhuǎn)換的工作量專門小，能夠忽 略，而關(guān)于一些亞洲字符集，在UTF8中一般需要兩到三個字節(jié)存儲，需要的數(shù)據(jù)庫空間增加，而且轉(zhuǎn)換的工作量也相對大一些，性能會有一些損失。 4、與字符集相關(guān)的問題分析 4.1、在UTF8環(huán)境下運行SQL語句報錯的問題： 我們前面講過，SQL*PLUS工具不提供編碼自動轉(zhuǎn)換的功能，當(dāng)數(shù)據(jù)庫字符集為UTF8，客戶端的NLS_LANG假如也是UTF8，那么在 SQL*PLUS中運行SQL語句時，語句全是英文，可不能出現(xiàn)問題，假如語句包含了中文或其它一些專門字符，SQL語句運行時就會報錯。關(guān)于返回的含中文 的結(jié)果，SQL

22、*PLUS也會顯示亂碼。造成此錯誤的緣故在于當(dāng)SQL語句中包含漢字等一些專門字符時，由于這些字符的編碼屬于GBK，ORACLE沒有進(jìn)行字符轉(zhuǎn)換，而是直接把SQL語句送到 服務(wù)器上進(jìn)行解析。現(xiàn)在服務(wù)器的字符集是UTF8，因此它按UTF8編碼格式對SQL語句中GBK編碼的字符解析時就會產(chǎn)生錯誤。假如把客戶端的 NLS_LANG設(shè)置為本地環(huán)境的字符集，如ZHS16GBK，現(xiàn)在能夠直接在SQL*PLUS中輸入包含中文的SQL語句，ORACLE在把SQL語句 提交到服務(wù)器時會自動轉(zhuǎn)換成UTF8編碼格式，因此SQL語句能夠正常運行。關(guān)于英文字母，由于它在UTF8中的編碼數(shù)值采納的依舊ASCII的編碼數(shù) 值

23、，因此英文字母能夠直接使用而不需要轉(zhuǎn)換，這確實是假如SQL語句或輸出結(jié)果全是英文時可不能出現(xiàn)錯誤的緣故。 正確的做法是先把需要運行的SQL做成腳本文件，用代碼轉(zhuǎn)換工具把它轉(zhuǎn)換成UTF8編碼格式的文件，（注意！XP中的記事本是提供了代碼轉(zhuǎn)換功能的，能夠 在保存文件或選擇文件另存為的時候，彈出的對話框最后一項，編碼，選擇UTF8，再保存，即可把文件轉(zhuǎn)換成UTF8編碼格式）。完成后用IE打開那個腳 本，選擇編碼UTF8，觀看現(xiàn)在SQL腳本是否含有亂碼或“？”符號。假如沒有，講明編碼格式差不多是UTF8了，現(xiàn)在在SQL*PLUS中運行那個腳 本就可不能產(chǎn)生錯誤了。運行結(jié)束后，輸出的結(jié)果中假如包含中文，

24、需要把結(jié)果SPOOL輸出到一個文件中，然后用代碼轉(zhuǎn)換工具把那個結(jié)果文件由UTF8轉(zhuǎn)換成 本地編碼格式，再用寫字板打開，才能看到正常顯示的漢字。由于IE具有代碼轉(zhuǎn)換功能，因此也能夠不用代碼轉(zhuǎn)換工具，直接在IE中打開輸出的結(jié)果文件，選擇 UTF8編碼，也能正常顯示含中文的結(jié)果文件。 4.2、數(shù)據(jù)庫出現(xiàn)亂碼的問題： 數(shù)據(jù)庫出現(xiàn)亂碼的問題要緊和客戶的本地化環(huán)境，客戶端NLS_LANG設(shè)置，服務(wù)器端的數(shù)據(jù)庫字符集設(shè)置這三者有關(guān)，假如它們的設(shè)置不一致或者某個設(shè)置錯誤，就會專門容易出現(xiàn)亂碼，下面我們簡要介紹以下幾種情況： 4.2.1、數(shù)據(jù)庫字符集設(shè)置不當(dāng)引起的亂碼： 這種錯誤是由于數(shù)據(jù)庫字符集選擇錯誤而引起

25、的。我們前面講過，由于每種語言文字都有一些自己專門的字符，甚至一些字符的寫法都有不同的講究，因此即使關(guān)于 歐美國家來講，也不是能夠隨便通用的。像西歐的字符集標(biāo)準(zhǔn)ISO 8859-1是8位編碼，它就有自己的一些專門符號，這些字符在US7ASCII編碼中找不到對應(yīng)的編碼值。假如需要使用這些專門符號，就必須選用本地字 符集或者是它的超集的字符集。假如選用的字符集兩者都不是，那么在數(shù)據(jù)庫存儲的數(shù)據(jù)實際編碼和數(shù)據(jù)庫字符集的設(shè)置就產(chǎn)生了不一致，專門容易產(chǎn)生亂碼。例如：一個存儲簡體中文字符的數(shù)據(jù)庫，它的字符集選用了US7ASCII，當(dāng)它的客戶端NLS_LANG也選用US7ASCII時，那個系統(tǒng)單獨使用是沒

26、有問題的，因為兩者設(shè)置一致，因此ORACLE可不能進(jìn)行字符集的轉(zhuǎn)換，客戶輸入的GBK碼被直接在數(shù)據(jù)庫中存儲起來，當(dāng)查詢數(shù)據(jù)時，實際客戶端取出來的數(shù) 據(jù)也是GBK的編碼，因此顯示也是正常的。但當(dāng)其它的系統(tǒng)需要從那個數(shù)據(jù)庫取數(shù)據(jù)，或者它的數(shù)據(jù)要EXP出來，IMP到其它數(shù)據(jù)庫時，問題就會開始出現(xiàn) 了。其它系統(tǒng)的字符集一般是ZHS16GBK，或者其它系統(tǒng)客戶端的NLS_LANG設(shè)置為ZHS16GBK，現(xiàn)在必定會產(chǎn)生字符集的轉(zhuǎn)換。盡管數(shù)據(jù)庫字 符集設(shè)置為US7ASCII，但我們明白，實際存儲的數(shù)據(jù)編碼是ZHS16GBK的。惋惜ORACLE可不能明白，它會把存儲的ZHS16GBK編碼數(shù)據(jù)當(dāng) 作US7ASC

27、II編碼的數(shù)據(jù)，按照US7ASCII轉(zhuǎn)換成ZHS16GBK的轉(zhuǎn)換算法進(jìn)行轉(zhuǎn)換，能夠想象，這種情況下，亂碼的產(chǎn)生是必定的。結(jié)論是：假如要選擇一個非本地環(huán)境的數(shù)據(jù)庫字符集，在不需要考慮和其它系統(tǒng)的數(shù)據(jù)接口和數(shù)據(jù)交換的情況下，或者你有面對這種苦惱的心理預(yù)備的話，那么這種選擇是可行的，然而不忘了數(shù)據(jù)庫字符集一定要和客戶端的NLS_LANG保持一致。 4.2.2、數(shù)據(jù)庫字符集與客戶端NLS_LANG設(shè)置不同引起的亂碼： 由于ORACLE提供了字符集的轉(zhuǎn)換功能，因此數(shù)據(jù)庫字符集與客戶端NLS_LANG設(shè)置不同是能夠同意的，前提條件是數(shù)據(jù)庫的字符集必須是客戶端 NLS_LANG設(shè)置字符集的超集，那么由于客戶

28、端使用的字符是屬于數(shù)據(jù)庫字符集中的一部分，因此可不能產(chǎn)生轉(zhuǎn)換時數(shù)據(jù)丟失及亂碼的情況。 例如：關(guān)于一個需要存儲簡體文信息的數(shù)據(jù)庫來講，它的字符集設(shè)置和客戶端NLS_LANG設(shè)置一般能夠使用ZHS16GBK編碼。然而假如數(shù)據(jù)庫字符集選 用了UTF8的話，也是能夠的，因為ZHS16GBK編碼屬于UTF8的子集。ORACLE在數(shù)據(jù)庫與客戶端進(jìn)行數(shù)據(jù)交換時自動進(jìn)行編碼的轉(zhuǎn)換，在數(shù)據(jù)庫 中實際存儲的也是UTF8編碼的數(shù)據(jù)。現(xiàn)在其它數(shù)據(jù)庫和此數(shù)據(jù)庫也能夠正常的進(jìn)行數(shù)據(jù)交換，因為ORACLE會自動進(jìn)行數(shù)據(jù)的轉(zhuǎn)換。在實際使用中，遇到過 繁體XP的字符集ZHT16MSWIN950轉(zhuǎn)換成AL32UTF8字符集時，一

29、些專門的字符和個不冷僻的漢字會變成亂碼。后來證實是XP需要安裝一個字 庫補(bǔ)丁軟件，最后順利解決此問題。 結(jié)論：關(guān)于數(shù)據(jù)庫字符集為UTF8，而客戶端采納本地字符集的情況，最好進(jìn)行測試驗證，因為UNICODE標(biāo)準(zhǔn)本身進(jìn)展專門快，一些客戶端的操作系統(tǒng)對 UNICODE標(biāo)準(zhǔn)支持的力度不一致，有些操作系統(tǒng)支持不行，有些專門字符在轉(zhuǎn)換后會產(chǎn)生亂碼。由于那個話題差不多超出了本文的范疇，在此就不詳細(xì)討論了。 4.2.3、客戶端NLS_LANG與本地化環(huán)境不同引起的亂碼： 一般情況下，客戶端NLS_LANG與本地化環(huán)境采納了不同的字符集會出現(xiàn)亂碼，除非本地化環(huán)境的字符集是客戶端NLS_LANG設(shè)置字符集的子集。假如 把客戶端NLS_LANG設(shè)置為UTF8就屬于這種情況，由于目前還沒有能夠直接使用UNICODE字符集的操作系統(tǒng)，因此客戶本地化環(huán)境使用的字符集只 能是某種語言支持的字符集，它屬于UTF8的子集。下面我們就著重討論這種情況。 盡管目前WINDOWS的內(nèi)核是支持UNICODE的，然而WINDOWS并不支持直接顯示UNICODE編碼的字符,而且它并不明白目前的字符采納了何 種字符集，因此默認(rèn)