Oracle字符集運(yùn)用中易出現(xiàn)的問題分析
以下的文章主要介紹的是Oracle字符集相關(guān)的問題分析，如果你是Oracle字符集相關(guān)實(shí)際應(yīng)用方面的新手，你就可以通過以下的文章對Oracle字符集是如何正確使用的方法有一個更好的了解，以下就是文章的詳細(xì)內(nèi)容的介紹。
1、在UTF8環(huán)境下運(yùn)行SQL語句報(bào)錯的問題：
SQL*PLUS工具不提供編碼自動轉(zhuǎn)換的功能，當(dāng)數(shù)據(jù)庫字符集為UTF8，客戶端的NLS_LANG如果也是UTF8，那么在SQL*PLUS中運(yùn)行SQL語句時，語句全是英文，不會出現(xiàn)問題，如果語句包含了中文或其它一些特殊字符，SQL語句運(yùn)行時就會報(bào)錯。對于返回的含中文的結(jié)果，SQL*PLUS也會顯示亂碼。
造成此錯誤的原因在于當(dāng)SQL語句中包含漢字等一些特殊字符時，由于這些字符的編碼屬于GBK，ORACLE沒有進(jìn)行字符轉(zhuǎn)換，而是直接把SQL語句送到服務(wù)器上進(jìn)行解析。此時服務(wù)器的Oracle字符集是UTF8，因此它按UTF8編碼格式對SQL語句中GBK編碼的字符解析時就會產(chǎn)生錯誤。
如果把客戶端的NLS_LANG設(shè)置為本地環(huán)境的字符集，如ZHS16GBK，此時可以直接在SQL*PLUS中輸入包含中文的SQL語句，ORACLE在把SQL語句提交到服務(wù)器時會自動轉(zhuǎn)換成UTF8編碼格式，因此SQL語句可以正常運(yùn)行。
對于英文字母，由于它在UTF8中的編碼數(shù)值采用的還是ASCII的編碼數(shù)值，因此英文字母可以直接使用而不需要轉(zhuǎn)換，這就是如果SQL語句或輸出結(jié)果全是英文時不會出現(xiàn)錯誤的原因。正確的做法是先把需要運(yùn)行的SQL做成腳本文件，用代碼轉(zhuǎn)換工具把它轉(zhuǎn)換成UTF8編碼格式的文件。
（注意！XP中的記事本是提供了代碼轉(zhuǎn)換功能的，可以在保存文件或選擇文件另存為的時候，彈出的對話框***一項(xiàng)，編碼，選擇UTF8，再保存，即可把文件轉(zhuǎn)換成UTF8編碼格式）。
完成后用IE打開這個腳本，選擇編碼－》UTF8，觀察此時SQL腳本是否含有亂碼或“？”符號。如果沒有，說明編碼格式已經(jīng)是UTF8了，此時在SQL*PLUS中運(yùn)行這個腳本就不會產(chǎn)生錯誤了。
運(yùn)行結(jié)束后，輸出的結(jié)果中如果包含中文，需要把結(jié)果SPOOL輸出到一個文件中，然后用代碼轉(zhuǎn)換工具把這個結(jié)果文件由UTF8轉(zhuǎn)換成本地編碼格式，再用寫字板打開，才能看到正常顯示的漢字。由于IE具有代碼轉(zhuǎn)換功能，因此也可以不用代碼轉(zhuǎn)換工具，直接在IE中打開輸出的結(jié)果文件，選擇UTF8編碼，也能正常顯示含中文的結(jié)果文件。
數(shù)據(jù)庫出現(xiàn)亂碼的問題：
數(shù)據(jù)庫出現(xiàn)亂碼的問題主要和客戶的本地化環(huán)境，客戶端NLS_LANG設(shè)置，服務(wù)器端的數(shù)據(jù)庫Oracle字符集設(shè)置這三者有關(guān)，如果它們的設(shè)置不一致或者某個設(shè)置錯誤，就會很容易出現(xiàn)亂碼，下面我們簡要介紹以下幾種情況：
1、數(shù)據(jù)庫字符集設(shè)置不當(dāng)引起的亂碼：
例如：一個存儲簡體中文字符的數(shù)據(jù)庫，它的字符集選用了US7ASCII，當(dāng)它的客戶端NLS_LANG也選用US7ASCII時，這個系統(tǒng)單獨(dú)使用是沒有問題的，因?yàn)閮烧咴O(shè)置一致，因此ORACLE不會進(jìn)行字符集的轉(zhuǎn)換，客戶輸入的GBK碼被直接在數(shù)據(jù)庫中存儲起來，當(dāng)查詢數(shù)據(jù)時，實(shí)際客戶端取出來的數(shù)據(jù)也是GBK的編碼，因此顯示也是正常的。
但當(dāng)其它的系統(tǒng)需要從這個數(shù)據(jù)庫取數(shù)據(jù)，或者它的數(shù)據(jù)要EXP出來，IMP到其它數(shù)據(jù)庫時，問題就會開始出現(xiàn)了。其它系統(tǒng)的Oracle字符集一般是ZHS16GBK，或者其它系統(tǒng)客戶端的NLS_LANG設(shè)置為ZHS16GBK，此時必然會產(chǎn)生字符集的轉(zhuǎn)換。雖然數(shù)據(jù)庫字符集設(shè)置為US7ASCII，但我們知道，實(shí)際存儲的數(shù)據(jù)編碼是ZHS16GBK的。
可惜ORACLE不會知道，它會把存儲的ZHS16GBK編碼數(shù)據(jù)當(dāng)作US7ASCII編碼的數(shù)據(jù)，按照US7ASCII轉(zhuǎn)換成ZHS16GBK的轉(zhuǎn)換算法進(jìn)行轉(zhuǎn)換，可以想象，這種情況下，亂碼的產(chǎn)生是必然的。
2、數(shù)據(jù)庫字符集與客戶端NLS_LANG設(shè)置不同引起的亂碼：
例如：對于一個需要存儲簡體文信息的數(shù)據(jù)庫來說，它的字符集設(shè)置和客戶端NLS_LANG設(shè)置一般可以使用ZHS16GBK編碼。但是如果數(shù)據(jù)庫字符集選用了UTF8的話，也是可以的，因?yàn)閆HS16GBK編碼屬于UTF8的子集。ORACLE在數(shù)據(jù)庫與客戶端進(jìn)行數(shù)據(jù)交換時自動進(jìn)行編碼的轉(zhuǎn)換，在數(shù)據(jù)庫中實(shí)際存儲的也是UTF8編碼的數(shù)據(jù)。
此時其它數(shù)據(jù)庫和此數(shù)據(jù)庫也可以正常的進(jìn)行數(shù)據(jù)交換，因?yàn)镺RACLE會自動進(jìn)行數(shù)據(jù)的轉(zhuǎn)換。在實(shí)際使用中，遇到過繁體XP的字符集ZHT16MSWIN950轉(zhuǎn)換成AL32UTF8字符集時，一些特殊的字符和個別冷僻的漢字會變成亂碼。后來證實(shí)是XP需要安裝一個字庫補(bǔ)丁軟件，***順利解決此問題。
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)境使用的Oracle字符集只能是某種語言支持的字符集，它屬于UTF8的子集。下面我們就著重討論這種情況。
雖然目前WINDOWS的內(nèi)核是支持UNICODE的，但是WINDOWS并不支持直接顯示UNICODE編碼的字符,而且它并不知道目前的字符采用了何種字符集，所以默認(rèn)情況下，它使用缺省的代碼頁來解釋字符。因此，對于其它類型的編碼，需要先進(jìn)行轉(zhuǎn)換，變成系統(tǒng)目前的缺省代碼頁支持的字符集才能正常使用。
WINDOWS中的缺省代碼頁是由控制面板設(shè)置中的語言及區(qū)域的選擇所決定的，屬于客戶本地化的環(huán)境設(shè)置。簡體中文WINDOWS的字符編碼就是GBK，它的缺省代碼頁是936。對于其它非WINDOWS的操作系統(tǒng)，我們可以把它們目前缺省使用的Oracle字符集作為用戶的本地化環(huán)境設(shè)置。
另外，我們使用的大部分工具，如寫字板，SQL*PLUS等，它們沒有提供編碼轉(zhuǎn)換功能，因此在客戶端直接輸入或查詢數(shù)據(jù)往往都會遇到亂碼的問題，必須由應(yīng)用程序或一些工具去做編碼的轉(zhuǎn)換，才能保證正常的使用。
【編輯推薦】
