1、字符集的一些基本知識(shí)
字符集有很多種,最初的字符集是ASCII,由于ASCII支持的字符很有限,因此隨后又出現(xiàn)了很多的編碼方案,這些編碼方案大部分都是包括了ASCII的。EBCDIC編碼是另一個(gè)比較基本的編碼,它的部分字符采用了和ASCII不同的編碼值,因此兩者是不兼容的基本編碼方案。采用EBCDIC編碼的比較少,目前主要是IBM 的系統(tǒng)采用,如AS400及S390系統(tǒng),大部分的系統(tǒng)都是基于ASCII編碼的。
由于亞洲國(guó)家的字符集相對(duì)復(fù)雜一些,因此一般都使用了兩個(gè)及以上的字節(jié)進(jìn)行編碼的方案。對(duì)于簡(jiǎn)體中文,GB2312碼是國(guó)家1981年實(shí)施的編碼標(biāo)準(zhǔn),通行于大陸。新加坡等地也使用此編碼。GBK編碼是GB2312碼的擴(kuò)展,是1995年發(fā)布的指導(dǎo)性規(guī)范,它在字匯一級(jí)支持 ISO/IEC 10646-1 和GB 13000-1 的全部中日韓 (CJK) 漢字(20902字)。目前最新的漢字字符集是2000年的GB18030,它是取代GBK1.0的正式國(guó)家標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)收錄了27484個(gè)漢字,同時(shí)還收錄了藏文、蒙文、維吾爾文等主要的少數(shù)民族文字。目前簡(jiǎn)體WINDOWS的缺省內(nèi)碼還是GBK。
由于編碼方案太多且彼此之間不兼容,存在互相之間存在沖突的情況,即對(duì)于同一個(gè)編碼數(shù)值,在兩種不同的編碼方案中代表的是兩個(gè)不同的字符。這樣對(duì)于一些WEB應(yīng)用來(lái)說(shuō),由于多種語(yǔ)言文字的同時(shí)使用及存儲(chǔ),需要采用一種統(tǒng)一的字符集。為此,國(guó)際標(biāo)準(zhǔn)化組織(ISO)制定了ISO 10646碼表,而Unicode協(xié)會(huì)制定了Unicode規(guī)范,這兩個(gè)體系剛開(kāi)始時(shí)是獨(dú)立建立的,在1991年,雙方都認(rèn)識(shí)到世界不需要兩個(gè)不兼容的字符集。于是它們開(kāi)始合并雙方的工作成果,并為創(chuàng)立一個(gè)單一編碼表而協(xié)同工作。從Unicode2.0開(kāi)始,Unicode項(xiàng)目采用了與ISO 10646-1相同的字庫(kù)和字碼。目前兩個(gè)項(xiàng)目仍都存在,并獨(dú)立地公布各自的標(biāo)準(zhǔn)。Unicode協(xié)會(huì)現(xiàn)在的最新版本是2006年的Unicode 5.0。
2、ORACLE數(shù)據(jù)庫(kù)的字符集
ORACLE的字符集名字一般由以下部分組成:語(yǔ)言或區(qū)域、表示一個(gè)字符的比特位數(shù)、標(biāo)準(zhǔn)字符集名稱(chēng)(可選項(xiàng),S或C,表示服務(wù)器或客戶端)。ORACLE字符集UTF8與UTFE不符合此規(guī)定,其它基本都是這種格式。
set nls_lang=AMERICAN_AMERICA.UTF8
set nls_lang=SIMPLIFIED CHINESE_AMERICA.UTF8
對(duì)于US7ASCII,表示區(qū)域是US,用7個(gè)比特位表示一個(gè)字符,標(biāo)準(zhǔn)的字符集名稱(chēng)為ASCII。
對(duì)于中文字符集ZHS16GBK,表示簡(jiǎn)體中文(ZHT為繁體中文),一個(gè)字符需要16位比特,標(biāo)準(zhǔn)的字符集名稱(chēng)為GBK。而ZHS16CGB231280表示簡(jiǎn)體中文,一個(gè)字符需要16位比特,標(biāo)準(zhǔn)的字符集名稱(chēng)為GB231280,屬于我們前面提過(guò)的1981年發(fā)布的GB2312-80標(biāo)準(zhǔn)。雖然我們說(shuō),GBK編碼標(biāo)準(zhǔn)是GB2312編碼標(biāo)準(zhǔn)的擴(kuò)展,但是數(shù)據(jù)庫(kù)字符集ZHS16GBK與ZHS16CGB231280之間卻不是嚴(yán)格的超集與子集的關(guān)系,主要是有些漢字的編碼在兩個(gè)字符集中的數(shù)值是不同的,因此它們進(jìn)行字符集轉(zhuǎn)換時(shí)會(huì)出現(xiàn)問(wèn)題。
在本文中,有時(shí)候使用的是標(biāo)準(zhǔn)字符集名稱(chēng),有時(shí)候又需要使用ORACLE字符集的名稱(chēng),因此希望大家明白兩者之間的對(duì)應(yīng)關(guān)系。
ORACLE數(shù)據(jù)庫(kù)有國(guó)家字符集(national character set)與數(shù)據(jù)庫(kù)字符集(database character set)之分。兩者都是在創(chuàng)建數(shù)據(jù)庫(kù)時(shí)需要設(shè)置的。國(guó)家字符集主要是用于NCHAR、NVARCHAR、NCLOB類(lèi)型的字段數(shù)據(jù),而數(shù)據(jù)庫(kù)字符集使用很廣泛,它用于:CHAR、VARCHAR、CLOB、LONG類(lèi)型的字段數(shù)據(jù);表名、列名、PL/SQL中的變量名;輸入及保存在數(shù)據(jù)庫(kù)的SQL和PL/SQL的源碼。
ORACLE支持的Unicode字符集有以下幾種,下面的列表給出了字符集的名稱(chēng)、對(duì)應(yīng)的數(shù)據(jù)庫(kù)版本范圍、采用的Unicode的版本。
AL24UTFFSS:是ORACLE第一種支持Unicode的字符集,從7.2版本開(kāi)始使用,但是它支持的Unicode版本為1.1,因此從9i開(kāi)始就不支持此字符集了。
UTF8:是ORACLE從ORACLE8開(kāi)始使用的屬于UTF-8編碼的字符集,從ORACLE8.0到ORACLE8.16,Unicode版本為2.1,而ORACLE817到10g,采用的Unicode標(biāo)準(zhǔn)為3.0
UTFE:用于EBCDIC碼平臺(tái)上的數(shù)據(jù)庫(kù)Unicode字符集。因此它屬于專(zhuān)用系統(tǒng)使用的字符集,其它屬性與UTF8基本相同。
AL32UTF8:是從ORACLE9開(kāi)始使用的屬于UTF-8編碼的字符集,與UTF8相比,它采用的Unicode版本更新,在10g版本中使用的是Unicode 4.01標(biāo)準(zhǔn),而UTF8因?yàn)榧嫒菪缘目紤],在10g版本中用的是Unicode 3.0標(biāo)準(zhǔn)。
AL16UTF16:是ORACLE第一種采用UTF-16編碼方式的字符集,從ORACLE9開(kāi)始使用,是作為缺省的國(guó)家字符集使用,它不能被用作數(shù)據(jù)庫(kù)的字符集。這是因?yàn)閿?shù)據(jù)庫(kù)的字符集決定了SQL與PL/SQL源碼的編碼方式,對(duì)于UTF-16這種使用固定的兩個(gè)字節(jié)來(lái)表示英文字母的編碼方案來(lái)說(shuō),確實(shí)不適于用作數(shù)據(jù)庫(kù)的字符集,ORACLE目前采用的數(shù)據(jù)庫(kù)字符集都是基于ASCII或EBCDID作為子集的編碼方案。
3、如何選擇合適的數(shù)據(jù)庫(kù)字符集
3.1、數(shù)據(jù)庫(kù)需要存儲(chǔ)的數(shù)據(jù)類(lèi)型是字符集選擇的首要考慮目標(biāo)。
對(duì)于只存儲(chǔ)英文信息的數(shù)據(jù)庫(kù)等來(lái)說(shuō),一般采用US7ASCII或WE8ISO8859P1等單字節(jié)的字符集就比較合適,在性能和空間上也是最優(yōu),
同樣,存儲(chǔ)了中文信息的數(shù)據(jù)庫(kù),如果采用單字節(jié)的字符集,也是不合適的。在這種情況下,數(shù)據(jù)庫(kù)的字符集雖然是US7ASCII或WE8ISO8859P1編碼,但里面存儲(chǔ)的數(shù)據(jù)編碼實(shí)際上卻是另外的編碼格式,這種不一致的情況很容易引起問(wèn)題,建議不要這樣使用。ORACLE提供了很多種類(lèi)的字符集供客戶選擇,就是要滿足各種文字不同的編碼需要。
3.2、字符集的選擇需要優(yōu)先考慮應(yīng)用程序的需要。
目前出于國(guó)際化的需要,軟件需要可以對(duì)不同的語(yǔ)言文字進(jìn)行處理,尤其一個(gè)系統(tǒng)中需要容納多種語(yǔ)言文字的時(shí)候,一般都會(huì)采用Unicode這樣的通用解決方案,即使會(huì)有一些空間和運(yùn)行效率的損失也是值得的。此時(shí)數(shù)據(jù)庫(kù)字符集建議可以采用AL32UTF8或UTF8編碼,一種比較理想的模式就是由程序負(fù)責(zé)編碼格式的轉(zhuǎn)換,而數(shù)據(jù)庫(kù)只提供一個(gè)透明的數(shù)據(jù)存儲(chǔ),
客戶在應(yīng)用程序中輸入數(shù)據(jù),此時(shí)數(shù)據(jù)的編碼格式是由客戶操作系統(tǒng)的區(qū)域及語(yǔ)言設(shè)置決定的,如在簡(jiǎn)體中文XP的環(huán)境下,輸入的中文編碼屬于GBK編碼。在客戶輸入結(jié)束后,程序首先判斷客戶的本地環(huán)境,并把編碼轉(zhuǎn)換成UNICODE,并通過(guò)NET傳送到服務(wù)器端。由于客戶端與服務(wù)器數(shù)據(jù)庫(kù)的字符集均為UTF8格式,ORACLE在傳送過(guò)程中不會(huì)進(jìn)行字符轉(zhuǎn)換,直接把數(shù)據(jù)按UTF8格式存儲(chǔ)到數(shù)據(jù)庫(kù)中。查詢(xún)時(shí)是一個(gè)反向的過(guò)程,應(yīng)用程序從數(shù)據(jù)庫(kù)中取出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)用程序來(lái)負(fù)責(zé),數(shù)據(jù)庫(kù)只是提供了一個(gè)數(shù)據(jù)存儲(chǔ)功能。
對(duì)于部分程序來(lái)說(shuō),由于對(duì)UNICODE支持不夠,沒(méi)有提供編碼的轉(zhuǎn)換功能,則可以使用ORACLE提供的字符集轉(zhuǎn)換功能來(lái)實(shí)現(xiàn)同樣的目的??蛻粼趹?yīng)用程序中輸入數(shù)據(jù),此時(shí)數(shù)據(jù)的編碼格式是由客戶操作系統(tǒng)的區(qū)域及語(yǔ)言設(shè)置決定的,如在簡(jiǎn)體中文XP的環(huán)境下,輸入的中文編碼屬于GBK編碼。在客戶輸入結(jié)束后,程序直接把數(shù)據(jù)并通過(guò)NET傳送到服務(wù)器端。由于客戶端與服務(wù)器數(shù)據(jù)庫(kù)的字符集不一致,因此ORACLE會(huì)把客戶端的編碼轉(zhuǎn)換成UTF8格式,再把數(shù)據(jù)按UTF8格式存儲(chǔ)到數(shù)據(jù)庫(kù)中。這種方案的優(yōu)點(diǎn)就是程序可以不用支持UNICODE,由ORACLE數(shù)據(jù)庫(kù)自動(dòng)進(jìn)行轉(zhuǎn)換。由于數(shù)據(jù)庫(kù)的字符集為UTF8,是其它字符集的超集,因此在轉(zhuǎn)換過(guò)程中不會(huì)發(fā)生數(shù)據(jù)丟失的情況。對(duì)于英文的字符符號(hào),在UTF8中使用單字節(jié)存儲(chǔ),轉(zhuǎn)換的工作量很小,可以忽略,而對(duì)于一些亞洲字符集,在UTF8中一般需要兩到三個(gè)字節(jié)存儲(chǔ),需要的數(shù)據(jù)庫(kù)空間增加,而且轉(zhuǎn)換的工作量也相對(duì)大一些,性能會(huì)有一些損失。
4、與字符集相關(guān)的問(wèn)題分析
4.1、在UTF8環(huán)境下運(yùn)行SQL語(yǔ)句報(bào)錯(cuò)的問(wèn)題:
SQL*PLUS工具不提供編碼自動(dòng)轉(zhuǎn)換的功能,當(dāng)數(shù)據(jù)庫(kù)字符集為UTF8,客戶端的NLS_LANG如果也是UTF8,那么在SQL*PLUS中運(yùn)行SQL語(yǔ)句時(shí),語(yǔ)句全是英文,不會(huì)出現(xiàn)問(wèn)題,如果語(yǔ)句包含了中文或其它一些特殊字符,SQL語(yǔ)句運(yùn)行時(shí)就會(huì)報(bào)錯(cuò)。對(duì)于返回的含中文的結(jié)果,SQL*PLUS也會(huì)顯示亂碼。造成此錯(cuò)誤的原因在于當(dāng)SQL語(yǔ)句中包含漢字等一些特殊字符時(shí),由于這些字符的編碼屬于GBK,ORACLE沒(méi)有進(jìn)行字符轉(zhuǎn)換,而是直接把SQL語(yǔ)句送到服務(wù)器上進(jìn)行解析。此時(shí)服務(wù)器的字符集是UTF8,因此它按UTF8編碼格式對(duì)SQL語(yǔ)句中GBK編碼的字符解析時(shí)就會(huì)產(chǎn)生錯(cuò)誤。如果把客戶端的NLS_LANG設(shè)置為本地環(huán)境的字符集,如ZHS16GBK,此時(shí)可以直接在SQL*PLUS中輸入包含中文的SQL語(yǔ)句,ORACLE在把SQL語(yǔ)句提交到服務(wù)器時(shí)會(huì)自動(dòng)轉(zhuǎn)換成UTF8編碼格式,因此SQL語(yǔ)句可以正常運(yùn)行。對(duì)于英文字母,由于它在UTF8中的編碼數(shù)值采用的還是ASCII的編碼數(shù)值,因此英文字母可以直接使用而不需要轉(zhuǎn)換,這就是如果SQL語(yǔ)句或輸出結(jié)果全是英文時(shí)不會(huì)出現(xiàn)錯(cuò)誤的原因。正確的做法是先把需要運(yùn)行的SQL做成腳本文件,用代碼轉(zhuǎn)換工具把它轉(zhuǎn)換成UTF8編碼格式的文件,(注意!XP中的記事本是提供了代碼轉(zhuǎn)換功能的,可以在保存文件或選擇文件另存為的時(shí)候,彈出的對(duì)話框最后一項(xiàng),編碼,選擇UTF8,再保存,即可把文件轉(zhuǎn)換成UTF8編碼格式)。完成后用IE打開(kāi)這個(gè)腳本,選擇編碼-》UTF8,觀察此時(shí)SQL腳本是否含有亂碼或“?”符號(hào)。如果沒(méi)有,說(shuō)明編碼格式已經(jīng)是UTF8了,此時(shí)在SQL*PLUS中運(yùn)行這個(gè)腳本就不會(huì)產(chǎn)生錯(cuò)誤了。運(yùn)行結(jié)束后,輸出的結(jié)果中如果包含中文,需要把結(jié)果SPOOL輸出到一個(gè)文件中,然后用代碼轉(zhuǎn)換工具把這個(gè)結(jié)果文件由UTF8轉(zhuǎn)換成本地編碼格式,再用寫(xiě)字板打開(kāi),才能看到正常顯示的漢字。由于IE具有代碼轉(zhuǎn)換功能,因此也可以不用代碼轉(zhuǎn)換工具,直接在IE中打開(kāi)輸出的結(jié)果文件,選擇UTF8編碼,也能正常顯示含中文的結(jié)果文件。
4.2、數(shù)據(jù)庫(kù)出現(xiàn)亂碼的問(wèn)題:
數(shù)據(jù)庫(kù)出現(xiàn)亂碼的問(wèn)題主要和客戶的本地化環(huán)境,客戶端NLS_LANG設(shè)置,服務(wù)器端的數(shù)據(jù)庫(kù)字符集設(shè)置這三者有關(guān),如果它們的設(shè)置不一致或者某個(gè)設(shè)置錯(cuò)誤,就會(huì)很容易出現(xiàn)亂碼,下面我們簡(jiǎn)要介紹以下幾種情況:
4.2.1、數(shù)據(jù)庫(kù)字符集設(shè)置不當(dāng)引起的亂碼:
例如:一個(gè)存儲(chǔ)簡(jiǎn)體中文字符的數(shù)據(jù)庫(kù),它的字符集選用了US7ASCII,當(dāng)它的客戶端NLS_LANG也選用US7ASCII時(shí),這個(gè)系統(tǒng)單獨(dú)使用是沒(méi)有問(wèn)題的,因?yàn)閮烧咴O(shè)置一致,因此ORACLE不會(huì)進(jìn)行字符集的轉(zhuǎn)換,客戶輸入的GBK碼被直接在數(shù)據(jù)庫(kù)中存儲(chǔ)起來(lái),當(dāng)查詢(xún)數(shù)據(jù)時(shí),實(shí)際客戶端取出來(lái)的數(shù)據(jù)也是GBK的編碼,因此顯示也是正常的。但當(dāng)其它的系統(tǒng)需要從這個(gè)數(shù)據(jù)庫(kù)取數(shù)據(jù),或者它的數(shù)據(jù)要EXP出來(lái),IMP到其它數(shù)據(jù)庫(kù)時(shí),問(wèn)題就會(huì)開(kāi)始出現(xiàn)了。其它系統(tǒng)的字符集一般是ZHS16GBK,或者其它系統(tǒng)客戶端的NLS_LANG設(shè)置為ZHS16GBK,此時(shí)必然會(huì)產(chǎn)生字符集的轉(zhuǎn)換。雖然數(shù)據(jù)庫(kù)字符集設(shè)置為US7ASCII,但我們知道,實(shí)際存儲(chǔ)的數(shù)據(jù)編碼是ZHS16GBK的。可惜ORACLE不會(huì)知道,它會(huì)把存儲(chǔ)的ZHS16GBK編碼數(shù)據(jù)當(dāng)作US7ASCII編碼的數(shù)據(jù),按照US7ASCII轉(zhuǎn)換成ZHS16GBK的轉(zhuǎn)換算法進(jìn)行轉(zhuǎn)換,可以想象,這種情況下,亂碼的產(chǎn)生是必然的。
4.2.2、數(shù)據(jù)庫(kù)字符集與客戶端NLS_LANG設(shè)置不同引起的亂碼:
例如:對(duì)于一個(gè)需要存儲(chǔ)簡(jiǎn)體文信息的數(shù)據(jù)庫(kù)來(lái)說(shuō),它的字符集設(shè)置和客戶端NLS_LANG設(shè)置一般可以使用ZHS16GBK編碼。但是如果數(shù)據(jù)庫(kù)字符集選用了UTF8的話,也是可以的,因?yàn)閆HS16GBK編碼屬于UTF8的子集。ORACLE在數(shù)據(jù)庫(kù)與客戶端進(jìn)行數(shù)據(jù)交換時(shí)自動(dòng)進(jìn)行編碼的轉(zhuǎn)換,在數(shù)據(jù)庫(kù)中實(shí)際存儲(chǔ)的也是UTF8編碼的數(shù)據(jù)。此時(shí)其它數(shù)據(jù)庫(kù)和此數(shù)據(jù)庫(kù)也可以正常的進(jìn)行數(shù)據(jù)交換,因?yàn)镺RACLE會(huì)自動(dòng)進(jìn)行數(shù)據(jù)的轉(zhuǎn)換。在實(shí)際使用中,遇到過(guò)繁體XP的字符集ZHT16MSWIN950轉(zhuǎn)換成AL32UTF8字符集時(shí),一些特殊的字符和個(gè)別冷僻的漢字會(huì)變成亂碼。后來(lái)證實(shí)是XP需要安裝一個(gè)字庫(kù)補(bǔ)丁軟件,最后順利解決此問(wèn)題。
4.2.3、客戶端NLS_LANG與本地化環(huán)境不同引起的亂碼:
一般情況下,客戶端NLS_LANG與本地化環(huán)境采用了不同的字符集會(huì)出現(xiàn)亂碼,除非本地化環(huán)境的字符集是客戶端NLS_LANG設(shè)置字符集的子集。如果把客戶端NLS_LANG設(shè)置為UTF8就屬于這種情況,由于目前還沒(méi)有可以直接使用UNICODE字符集的操作系統(tǒng),因此客戶本地化環(huán)境使用的字符集只能是某種語(yǔ)言支持的字符集,它屬于UTF8的子集。下面我們就著重討論這種情況。
雖然目前WINDOWS的內(nèi)核是支持UNICODE的,但是WINDOWS并不支持直接顯示UNICODE編碼的字符,而且它并不知道目前的字符采用了何種字符集,所以默認(rèn)情況下,它使用缺省的代碼頁(yè)來(lái)解釋字符。因此,對(duì)于其它類(lèi)型的編碼,需要先進(jìn)行轉(zhuǎn)換,變成系統(tǒng)目前的缺省代碼頁(yè)支持的字符集才能正常使用。
WINDOWS中的缺省代碼頁(yè)是由控制面板設(shè)置中的語(yǔ)言及區(qū)域的選擇所決定的,屬于客戶本地化的環(huán)境設(shè)置。簡(jiǎn)體中文WINDOWS的字符編碼就是GBK,它的缺省代碼頁(yè)是936。對(duì)于其它非WINDOWS的操作系統(tǒng),我們可以把它們目前缺省使用的字符集作為用戶的本地化環(huán)境設(shè)置。另外,我們使用的大部分工具,如寫(xiě)字板,SQL*PLUS等,它們沒(méi)有提供編碼轉(zhuǎn)換功能,因此在客戶端直接輸入或查詢(xún)數(shù)據(jù)往往都會(huì)遇到亂碼的問(wèn)題,必須由應(yīng)用程序或一些工具去做編碼的轉(zhuǎn)換,才能保證正常的使用。
NLS_LANG 參數(shù)組成
NLS_LANG參數(shù)由以下部分組成:
NLS_LANG=<Language>_<Territory>.<Clients Characterset>
NLS_LANG各部分含義如下:
LANGUAGE指定:
-Oracle消息使用的語(yǔ)言
-日期中月份和日顯示
TERRITORY指定
-貨幣和數(shù)字格式
-地區(qū)和計(jì)算星期及日期的習(xí)慣
CHARACTERSET:
-控制客戶端應(yīng)用程序使用的字符集
通常設(shè)置或者等于客戶端(如Windows)代碼頁(yè)
或者對(duì)于unicode應(yīng)用設(shè)置為UTF8
在Windows上查看當(dāng)前系統(tǒng)的代碼頁(yè)可以使用chcp命令:
E:\>chcp
活動(dòng)的代碼頁(yè): 936
代碼頁(yè)936也就是中文字符集 GBK,在Microsoft的官方站點(diǎn)上,我們可以遭到關(guān)于936代碼頁(yè)的具體編碼規(guī)則,請(qǐng)參考以下鏈接:
http://www.microsoft.com/globaldev/reference/dbcs/936.htm
2. 查看 NLS_LANG 的方法
Windows使用:
echo %NLS_LANG%
如:
E:\>echo %NLS_LANG%
AMERICAN_AMERICA.ZHS16GBK
Unix使用:
env|grep NLS_LANG
如:
/opt/oracle>env|grep NLS_LANG
NLS_LANG=AMERICAN_CHINA.ZHS16GBK
Windows客戶端設(shè)置,可以在注冊(cè)表中更改NLS_LANG,具體鍵值位于:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMExx\
xx指存在多個(gè)ORACLE_HOME時(shí)系統(tǒng)編號(hào)。
3. 查看數(shù)據(jù)庫(kù)當(dāng)前字符集參數(shù)設(shè)置
SELECT * FROM v$nls_parameters;
4. 查看數(shù)據(jù)庫(kù)可用字符集參數(shù)設(shè)置
SELECT * FROM v$nls_valid_values;
5. 客戶端 NLS_LANG 的設(shè)置方法
Windows:
# 常用中文字符集
set NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
# 常用unicode字符集
set NLS_LANG=american_america.AL32UTF8
可以通過(guò)修改注冊(cè)表鍵值永久設(shè)置
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMExx\NLS_LANG
Unix:
# 常用unicode字符集
export NLS_LANG=american_america.AL32UTF8
# 常用中文字符集
export
可以編輯 bash_profile 文件進(jìn)行永久設(shè)置
vi .bash_profile
export NLS_LANG="SIMPLIFIED CHINESE_CHINA.ZHS16GBK"
or export NLS_LANG="Simplified Chinese_china".ZHS16GBK# 使 bash_profile 設(shè)置生效source .bash_profile