如何選擇數(shù)據(jù)庫的字符集是一個有爭議的話題,字符集本身涉及的范圍很廣,它與應(yīng)用程序、客戶的本地環(huán)境、操作系統(tǒng)、服務(wù)器等關(guān)系很密切,因此要做出合適的選擇,需要明白這些因素之間的關(guān)系。另外對字符集的基本概念,ORACLE數(shù)據(jù)庫字符集的一些知識也需要了解。
隨著國內(nèi)的軟件產(chǎn)品逐步走向海外,對于多語言的支持已經(jīng)成為軟件的一個基本要求,采用UNICODE標(biāo)準(zhǔn)也逐漸成為通用的設(shè)計方案,此時ORACLE數(shù)據(jù)庫的字符集應(yīng)該如何選擇?很多人都有自己的見解,在網(wǎng)上也可以看到很多關(guān)于字符集的文章。這些文章有很多精華值得去學(xué)習(xí),但是另一方面還存在一些錯誤,尤其對UNICODE,存在一些概念不清的地方。
數(shù)據(jù)庫字符集的選擇并不存在絕對意義上的正確或錯誤,每種字符集都有它適用的環(huán)境。對于我們來說,了解得越多,越能幫助自己做出適當(dāng)?shù)剡x擇,而且可以采取措施去主動防范或規(guī)避可能出現(xiàn)的問題。反之,如果數(shù)據(jù)庫字符集選擇不恰當(dāng),會給后面的工作帶來很多的麻煩,需要花費很多時間和精力去解決問題,有些問題甚至?xí)绊懙娇蛻舻臉I(yè)務(wù)使用。本文希望可以給大家提供一些相對全面的知識,方便大家了解數(shù)據(jù)庫字符集的相關(guān)概念,因此有些繁瑣,請大家見諒。另外由于個人的局限,有何不妥之處還請大家不吝指正。
下面我們由淺入深,先由概念入手,再給出幾種常用的字符集設(shè)置建議,對一些可能遇到的問題做出分析,最后給出自己的建議。
1、字符集的一些基本知識
講到數(shù)據(jù)庫的字符集設(shè)置,首先需要對字符集的知識有些了解。以下是字符集的基本知識介紹:由于計算機只能存儲使用二進制數(shù)據(jù),因此對于一些字符或符號,需要對它們進行編碼,用編碼后的數(shù)值來表示這些字符。對于一組符號的編碼集合就是字符集。
字符集有很多種,最初的字符集是ASCII,它用一個字節(jié)中的7位來表示128個字符,第8位沒有使用。它包括大小寫字母、數(shù)字0-9、標(biāo)點符號、非打印字符(換行符、制表符等4個)以及控制字符(退格、響鈴等)等。由于ASCII支持的字符很有限,因此隨后又出現(xiàn)了很多的編碼方案,這些編碼方案大部分都是包括了ASCII的,它們只是做了擴展,這些擴展的內(nèi)容一般各不相同,因此說ASCII是一個比較基本的編碼,EBCDIC編碼是另一個比較基本的編碼,它的部分字符采用了和ASCII不同的編碼值,因此兩者是不兼容的基本編碼方案。采用EBCDIC編碼的比較少,目前主要是IBM的系統(tǒng)采用,如AS400及S390系統(tǒng),大部分的系統(tǒng)都是基于ASCII編碼的。
由于亞洲國家的字符集相對復(fù)雜一些,因此一般都使用了兩個及以上的字節(jié)進行編碼的方案。對于簡體中文,GB2312碼是國家1981年實施的編碼標(biāo)準(zhǔn),通行于大陸。新加坡等地也使用此編碼。GBK編碼是GB2312碼的擴展,是1995年發(fā)布的指導(dǎo)性規(guī)范,它在字匯一級支持ISO/IEC 10646-1 和GB13000-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還是我們目前最常用的簡體中文字符集。
由于編碼方案太多且彼此之間不兼容,存在互相之間存在沖突的情況,即對于同一個編碼數(shù)值,在兩種不同的編碼方案中代表的是兩個不同的字符。這樣對于一些WEB應(yīng)用來說,由于多種語言文字的同時使用及存儲,需要采用一種統(tǒng)一的字符集。為此,國際標(biāo)準(zhǔn)化組織(ISO)制定了ISO10646碼表,而Unicode協(xié)會制定了Unicode規(guī)范,這兩個體系剛開始時是獨立建立的,在1991年,雙方都認識到世界不需要兩個不兼容的字符集。于是它們開始合并雙方的工作成果,并為創(chuàng)立一個單一編碼表而協(xié)同工作。從Unicode2.0開始,Unicode項目采用了與ISO10646-1相同的字庫和字碼。目前兩個項目仍都存在,并獨立地公布各自的標(biāo)準(zhǔn)。Unicode協(xié)會現(xiàn)在的最新版本是2006年的Unicode5.0。ISO的最新標(biāo)準(zhǔn)是10646-3:2003。下面簡單介紹一下幾種常見的編碼方式:
UCS(UniversalCharacter Set)是按ISO-10646定義的字符集,有兩種最常用編碼方式:UCS-2和UCS-4。
UCS-2:使用0-65535之間的數(shù)表示一個unicode字符。UCS-2無法表示所有的unicode字符,只能表示其前65536個字符(稱為BasicMultilingual Plane,BMP)。我們一般經(jīng)常使用的UNICODE碼就是指這個編碼方案。
UCS-4:使用0-FFFFFFFF之間的數(shù)表示一個unicode字符,但為了和unicode體系兼容(unicode體系是一個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ī)則和計算機的實際編碼對應(yīng)起來的一個規(guī)則,UTF,英文為UCSTransformationFormat,即UCS轉(zhuǎn)換格式,目前常用的有UTF-8、UTF-16、UTF-32三種。(還有UTF-7在此就不介紹了)。正如名字所示,它們分別使用8位、16位、32位比特對UCS進行編碼。
UTF-8:一種變長的Unicode編碼方式,使用1到4個字節(jié)表示一個字符。這種方式的最大好處,是UTF-8保留了ASCII字符的編碼作為它的一部分,因此在ASCII表示的128個字符在UTF-8的編碼沒有變化,它的兼容性比較好。UTF-8在目前WEB應(yīng)用上使用很廣泛。
UTF-16:一種變長Unicode編碼方式,使用兩個或者四個字節(jié)表示一個字符。這種編碼方式比較節(jié)省空間,因為它把最常使用的字符都用兩個字節(jié)來表示,而那些不常用的字節(jié)則用兩個或四個字節(jié)來表示。但對于英文字符來說,它要用兩個字節(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ī)定,其它基本都是這種格式。
對于US7ASCII,表示區(qū)域是US,用7個比特位表示一個字符,標(biāo)準(zhǔn)的字符集名稱為ASCII。
對于中文字符集ZHS16GBK,表示簡體中文(ZHT為繁體中文),一個字符需要16位比特,標(biāo)準(zhǔn)的字符集名稱為GBK。而ZHS16CGB231280表示簡體中文,一個字符需要16位比特,標(biāo)準(zhǔn)的字符集名稱為GB231280,屬于我們前面提過的1981年發(fā)布的GB2312-80標(biāo)準(zhǔn)。雖然我們說,GBK編碼標(biāo)準(zhǔn)是GB2312編碼標(biāo)準(zhǔn)的擴展,但是數(shù)據(jù)庫字符集ZHS16GBK與ZHS16CGB231280之間卻不是嚴(yán)格的超集與子集的關(guān)系,主要是有些漢字的編碼在兩個字符集中的數(shù)值是不同的,因此它們進行字符集轉(zhuǎn)換時會出現(xiàn)問題。
在本文中,有時候使用的是標(biāo)準(zhǔn)字符集名稱,有時候又需要使用ORACLE字符集的名稱,因此希望大家明白兩者之間的對應(yīng)關(guān)系。
ORACLE數(shù)據(jù)庫有國家字符集(nationalcharacter set)與數(shù)據(jù)庫字符集(databasecharacterset)之分。兩者都是在創(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ù)庫版本范圍、采用的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)
AL24UTFFSS:是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相比,它采用的Unicode版本更新,在10g版本中使用的是Unicode4.01標(biāo)準(zhǔn),而UTF8因為兼容性的考慮,在10g版本中用的是Unicode3.0標(biāo)準(zhǔn)。
AL16UTF16:是ORACLE第一種采用UTF-16編碼方式的字符集,從ORACLE9開始使用,是作為缺省的國家字符集使用,它不能被用作數(shù)據(jù)庫的字符集。這是因為數(shù)據(jù)庫的字符集決定了SQL與PL/SQL源碼的編碼方式,對于UTF-16這種使用固定的兩個字節(jié)來表示英文字母的編碼方案來說,確實不適于用作數(shù)據(jù)庫的字符集,ORACLE目前采用的數(shù)據(jù)庫字符集都是基
于ASCII或EBCDID作為子集的編碼方案。
從以上幾種字符集的介紹來看,Unicode字符集一般使用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ù)類型是字符集選擇的首要考慮目標(biāo)。
由于數(shù)據(jù)庫的主要功能在于存儲數(shù)據(jù),因此要保證數(shù)據(jù)的正確性。采用何種數(shù)據(jù)庫字符集需要看存儲數(shù)據(jù)是何種類型的。對于只存儲英文信息的數(shù)據(jù)庫等來說,一般采用US7ASCII或WE8ISO8859P1等單字節(jié)的字符集就比較合適,在性能和空間上也是最優(yōu),如果采用ZHS16GBK編碼,雖然可以使用,但從數(shù)據(jù)庫字符集本身的含義來說,屬于不恰當(dāng)?shù)倪x擇。同樣,存儲了中文信息的數(shù)據(jù)庫,如果采用單字節(jié)的字符集,也是不合適的。在這種情況下,數(shù)據(jù)庫的字符集雖然是US7ASCII或WE8ISO8859P1編碼,但里面存儲的數(shù)據(jù)編碼實際上卻是另外的編碼格式,這種不一致的情況很容易引起問題,建議不要這樣使用。ORACLE提供了很多種類的字符集供客戶選擇,就是要滿足各種文字不同的編碼需要。
3.2、字符集的選擇需要優(yōu)先考慮應(yīng)用程序的需要。
目前出于國際化的需要,軟件需要可以對不同的語言文字進行處理,尤其一個系統(tǒng)中需要容納多種語言文字的時候,一般都會采用Unicode這樣的通用解決方案,即使會有一些空間和運行效率的損失也是值得的。此時數(shù)據(jù)庫字符集建議可以采用AL32UTF8或UTF8編碼,一種比較理想的模式就是由程序負責(zé)編碼格式的轉(zhuǎn)換,而數(shù)據(jù)庫只提供一個透明的數(shù)據(jù)存儲。
上圖中,客戶在應(yīng)用程序中輸入數(shù)據(jù),此時數(shù)據(jù)的編碼格式是由客戶操作系統(tǒng)的區(qū)域及語言設(shè)置決定的,如在簡體中文XP的環(huán)境下,輸入的中文編碼屬于GBK編碼。在客戶輸入結(jié)束后,程序首先判斷客戶的本地環(huán)境,并把編碼轉(zhuǎn)換成UNICODE,并通過NET傳送到服務(wù)器端。由于客戶端與服務(wù)器數(shù)據(jù)庫的字符集均為UTF8格式,ORACLE在傳送過程中不會進行字符轉(zhuǎn)換,直接把數(shù)據(jù)按UTF8格式存儲到數(shù)據(jù)庫中。查詢時是一個反向的過程,應(yīng)用程序從數(shù)據(jù)庫中取出UTF8編碼的數(shù)據(jù),再由應(yīng)用程序根據(jù)客戶的本地環(huán)境,把UTF8編碼的數(shù)據(jù)轉(zhuǎn)換成客戶本地的編碼格式,最后把結(jié)果數(shù)據(jù)顯示給客戶。此方案的關(guān)鍵在于應(yīng)用程序要能很好的支持UNICODE編碼,編碼的轉(zhuǎn)換由應(yīng)用程序來負責(zé),數(shù)據(jù)庫只是提供了一個數(shù)據(jù)存儲功能。
對于部分程序來說,由于對UNICODE支持不夠,沒有提供編碼的轉(zhuǎn)換功能,則可以使用ORACLE提供的字符集轉(zhuǎn)換功能來實現(xiàn)同樣的目的。
從上圖可以看到,客戶在應(yīng)用程序中輸入數(shù)據(jù),此時數(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ù)庫自動進行轉(zhuǎn)換。由于數(shù)據(jù)庫的字符集為UTF8,是其它字符集的超集,因此在轉(zhuǎn)換過程中不會發(fā)生數(shù)據(jù)丟失的情況。對于英文的字符符號,在UTF8中使用單字節(jié)存儲,轉(zhuǎ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語句運行時就會報錯。對于返回的含中文的結(jié)果,SQL*PLUS也會顯示亂碼。
造成此錯誤的原因在于當(dāng)SQL語句中包含漢字等一些特殊字符時,由于這些字符的編碼屬于GBK,ORACLE沒有進行字符轉(zhuǎn)換,而是直接把SQL語句送到服務(wù)器上進行解析。此時服務(wù)器的字符集是UTF8,因此它按UTF8編碼格式對SQL語句中GBK編碼的字符解析時就會產(chǎn)生錯誤。如果把客戶端的NLS_LANG設(shè)置為本地環(huán)境的字符集,如ZHS16GBK,此時可以直接在SQL*PLUS中輸入包含中文的SQL語句,ORACLE在把SQL語句提交到服務(wù)器時會自動轉(zhuǎn)換成UTF8編碼格式,因此SQL語句可以正常運行。對于英文字母,由于它在UTF8中的編碼數(shù)值采用的還是ASCII的編碼數(shù)值,因此英文字母可以直接使用而不需要轉(zhuǎn)換,這就是如果SQL語句或輸出結(jié)果全是英文時不會出現(xiàn)錯誤的原因。
正確的做法是先把需要運行的SQL做成腳本文件,用代碼轉(zhuǎn)換工具把它轉(zhuǎn)換成UTF8編碼格式的文件,(注意!XP中的記事本是提供了代碼轉(zhuǎn)換功能的,可以在保存文件或選擇文件另存為的時候,彈出的對話框最后一項,編碼,選擇UTF8,再保存,即可把文件轉(zhuǎn)換成UTF8編碼格式)。完成后用IE打開這個腳本,選擇編碼-》UTF8,觀察此時SQL腳本是否含有亂碼或“?”符號。如果沒有,說明編碼格式已經(jīng)是UTF8了,此時在SQL*PLUS中運行這個腳本就不會產(chǎn)生錯誤了。運行結(jié)束后,輸出的結(jié)果中如果包含中文,需要把結(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ù)庫字符集選擇錯誤而引起的。我們前面講過,由于每種語言文字都有一些自己特殊的字符,甚至一些字符的寫法都有不同的講究,因此即使對于歐美國家來說,也不是可以隨便通用的。像西歐的字符集標(biāo)準(zhǔn)ISO8859-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)單獨使用是沒有問題的,因為兩者設(shè)置一致,因此ORACLE不會進行字符集的轉(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,此時必然會產(chǎn)生字符集的轉(zhuǎn)換。雖然數(shù)據(jù)庫字符集設(shè)置為US7ASCII,但我們知道,實際存儲的數(shù)據(jù)編碼是ZHS16GBK的??上RACLE不會知道,它會把存儲的ZHS16GBK編碼數(shù)據(jù)當(dāng)作US7ASCII編碼的數(shù)據(jù),按照US7ASCII轉(zhuǎn)換成ZHS16GBK的轉(zhuǎn)換算法進行轉(zhuǎn)換,可以想象,這種情況下,亂碼的產(chǎn)生是必然的。
結(jié)論是:如果要選擇一個非本地環(huán)境的數(shù)據(jù)庫字符集,在不需要考慮和其它系統(tǒng)的數(shù)據(jù)接口和數(shù)據(jù)交換的情況下,或者你有面對這種麻煩的心理準(zhǔn)備的話,那么這種選擇是可行的,但是別忘了數(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è)置字符集的超集,那么由于客戶端使用的字符是屬于數(shù)據(jù)庫字符集中的一部分,因此不會產(chǎn)生轉(zhuǎn)換時數(shù)據(jù)丟失及亂碼的情況。
例如:對于一個需要存儲簡體文信息的數(shù)據(jù)庫來說,它的字符集設(shè)置和客戶端NLS_LANG設(shè)置一般可以使用ZHS16GBK編碼。但是如果數(shù)據(jù)庫字符集選用了UTF8的話,也是可以的,因為ZHS16GBK編碼屬于UTF8的子集。ORACLE在數(shù)據(jù)庫與客戶端進行數(shù)據(jù)交換時自動進行編碼的轉(zhuǎn)換,在數(shù)據(jù)庫中實際存儲的也是UTF8編碼的數(shù)據(jù)。此時其它數(shù)據(jù)庫和此數(shù)據(jù)庫也可以正常的進行數(shù)據(jù)交換,因為ORACLE會自動進行數(shù)據(jù)的轉(zhuǎn)換。在實際使用中,遇到過繁體XP的字符集ZHT16MSWIN950轉(zhuǎn)換成AL32UTF8字符集時,一些特殊的字符和個別冷僻的漢字會變成亂碼。后來證實是XP需要安裝一個字庫補丁軟件,最后順利解決此問題。
結(jié)論:對于數(shù)據(jù)庫字符集為UTF8,而客戶端采用本地字符集的情況,最好進行測試驗證,因為UNICODE標(biāo)準(zhǔn)本身發(fā)展很快,一些客戶端的操作系統(tǒng)對UNICODE標(biāo)準(zhǔn)支持的力度不一致,有些操作系統(tǒng)支持不好,有些特殊字符在轉(zhuǎn)換后會產(chǎn)生亂碼。由于這個話題已經(jīng)超出了本文的范疇,在此就不詳細討論了。
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編碼的字符,而且它并不知道目前的字符采用了何種字符集,所以默認情況下,它使用缺省的代碼頁來解釋字符。因此,對于其它類型的編碼,需要先進行轉(zhuǎn)換,變成系統(tǒng)目前的缺省代碼頁支持的字符集才能正常使用。
WINDOWS中的缺省代碼頁是由控制面板設(shè)置中的語言及區(qū)域的選擇所決定的,屬于客戶本地化的環(huán)境設(shè)置。簡體中文WINDOWS的字符編碼就是GBK,它的缺省代碼頁是936。對于其它非WINDOWS的操作系統(tǒng),我們可以把它們目前缺省使用的字符集作為用戶的本地化環(huán)境設(shè)置。另外,我們使用的大部分工具,如寫字板,SQL*PLUS等,它們沒有提供編碼轉(zhuǎn)換功能,因此在客戶端直接輸入或查詢數(shù)據(jù)往往都會遇到亂碼的問題,必須由應(yīng)用程序或一些工具去做編碼的轉(zhuǎn)換,才能保證正常的使用。比如SQL*PLUS遇到的問題,我們在4.1節(jié)中已經(jīng)進行了詳細的論述。
5、最后的結(jié)論及建議:
以上不厭其煩的列舉了種種因為選用了不恰當(dāng)?shù)臄?shù)據(jù)庫字符集而出現(xiàn)的問題,最后總結(jié)歸納起來,以下幾點就是我個人的建議了:
1)一般情況下,建議優(yōu)先考慮客戶的本地化環(huán)境,選用本地通用的字符集作為數(shù)據(jù)庫的字符集和客戶端NLS_LANG的設(shè)置,使得數(shù)據(jù)庫、客戶端NLS_LANG、客戶端操作系統(tǒng)三者的字符集可以完全兼容,這樣出現(xiàn)的問題和麻煩最少。就簡體中文而言,目前最常用的字符集是ZHS16GBK,建議大家選用。
2)如果系統(tǒng)需要支持多語言,采用了UNICODE標(biāo)準(zhǔn),那么ORACLE數(shù)據(jù)庫字符集在版本9以上可以選用AL32UTF8,如果涉及到ORACLE8及8i的數(shù)據(jù)庫,字符集可以選用UTF8。
3)如果應(yīng)用程序完全支持UNICODE,可以根據(jù)客戶的本地化環(huán)境自動轉(zhuǎn)換編碼,則客戶端的NLS_LANG可以設(shè)置成和數(shù)據(jù)庫服務(wù)器端字符集完全一致。如果應(yīng)用程序不能自動進行編碼的轉(zhuǎn)換或需要在客戶端進行一些管理維護活動,則建議把客戶端的NLS_LANG設(shè)置成本地環(huán)境使用的字符集,由ORACLE來進行編碼的轉(zhuǎn)換工作。此時需要對客戶端的操作系統(tǒng)進行驗證測試,因為目前各個操作系統(tǒng)對UNICODE標(biāo)準(zhǔn)支持的程度不同,有時會出現(xiàn)一些特殊字符轉(zhuǎn)換不正常的情況。