一．引言
ORACLE數據庫字符集，即Oracle全球化支持(Globalization Support)，或即國家語言支持（NLS）其作用是用本國語言和格式來存儲、處理和檢索數據。利用全球化支持，ORACLE為用戶提供自己熟悉的數據庫母語環境，諸如日期格式、數字格式和存儲序列等。Oracle可以支持多種語言及字符集，其中oracle8i支持48種語言、76個國家地域、229種字符集，而oracle9i則支持57種語言、88個國家地域、235種字符集。由于oracle字符集種類多，且在存儲、檢索、遷移oracle數據時多個環節與字符集的設置密切相關，因此在實際的應用中，數據庫開發和管理人員經常會遇到有關oracle字符集方面的問題。本文通過以下幾個方面闡述，對oracle字符集做簡要分析
二．字符集基本知識
2.1字符集
實質就是按照一定的字符編碼方案，對一組特定的符號，分別賦予不同數值編碼的集合。Oracle數據庫最早支持的編碼方案是US7ASCII。
Oracle的字符集命名遵循以下命名規則:
<Language><bit size><encoding>
即: <語言><比特位數><編碼>
比如: ZHS16GBK表示采用GBK編碼格式、16位（兩個字節）簡體中文字符集
2.2字符編碼方案
2.2.1 單字節編碼
（1）單字節7位字符集，可以定義128個字符，最常用的字符集為US7ASCII
（2）單字節8位字符集，可以定義256個字符，適合于歐洲大部分國家
例如：WE8ISO8859P1(西歐、8位、ISO標準8859P1編碼)
2.2.2 多字節編碼
（1）變長多字節編碼
某些字符用一個字節表示，其它字符用兩個或多個字符表示，變長多字節編碼常用于對亞洲語言的支持， 例如日語、漢語、印地語等
例如：AL32UTF8（其中AL代表ALL,指適用于所有語言）、zhs16cgb231280
（2）定長多字節編碼
每一個字符都使用固定長度字節的編碼方案，目前oracle唯一支持的定長多字節編碼是AF16UTF16，也是僅用于國家字符集
2.2.3 unicode編碼
Unicode是一個涵蓋了目前全世界使用的所有已知字符的單一編碼方案，也就是說Unicode為每一個字符提供唯一的編碼。UTF-16是unicode的16位編碼方式，是一種定長多字節編碼，用2個字節表示一個unicode字符，AF16UTF16是UTF-16編碼字符集。
UTF-8是unicode的8位編碼方式，是一種變長多字節編碼，這種編碼可以用1、2、3個字節表示一個unicode字符，AL32UTF8，UTF8、UTFE是UTF-8編碼字符集
2.3 字符集超級
當一種字符集（字符集A）的編碼數值包含所有另一種字符集（字符集B）的編碼數值，并且兩種字符集相同編碼數值代表相同的字符時，則字符集A是字符集B的超級，或稱字符集B是字符集A的子集。
Oracle8i和oracle9i官方文檔資料中備有子集-超級對照表（subset-superset pairs），例如：WE8ISO8859P1是WE8MSWIN1252的子集。由于US7ASCII是最早的Oracle數據庫編碼格式，因此有許多字符集是US7ASCII的超集，例如WE8ISO8859P1、ZHS16CGB231280、ZHS16GBK都是US7ASCII的超集。
2.4 數據庫字符集（oracle服務器端字符集）
數據庫字符集在創建數據庫時指定，在創建后通常不能更改。在創建數據庫時，可以指定字符集(CHARACTER SET)和國家字符集(NATIONAL CHARACTER SET)。
2.4.1字符集
(1)用來存儲CHAR, VARCHAR2, CLOB, LONG等類型數據
(2)用來標示諸如表名、列名以及PL/SQL變量等
(3)用來存儲SQL和PL/SQL程序單元等
2.4.2國家字符集：
(1)用以存儲NCHAR, NVARCHAR2, NCLOB等類型數據
(2)國家字符集實質上是為oracle選擇的附加字符集，主要作用是為了增強oracle的字符處理能力，因為NCHAR數據類型可以提供對亞洲使用定長多字節編碼的支持，而數據庫字符集則不能。國家字符集在oracle9i中進行了重新定義，只能在unicode編碼中的AF16UTF16和UTF8中選擇，默認值是AF16UTF16
2.4.3查詢字符集參數
可以查詢以下數據字典或視圖查看字符集設置情況
nls_database_parameters、props$、v$nls_parameters
查詢結果中NLS_CHARACTERSET表示字符集，NLS_NCHAR_CHARACTERSET表示國家字符集
2.4.4修改數據庫字符集
按照上文所說，數據庫字符集在創建后原則上不能更改。如果需要修改字符集，通常需要導出數據庫數據，重建數據庫，再導入數據庫數據的方式來轉換，或通過ALTER DATABASE CHARACTER SET語句修改字符集，但創建數據庫后修改字符集是有限制的，只有新的字符集是當前字符集的超集時才能修改數據庫字符集，例如UTF8是US7ASCII的超集，修改數據庫字符集可使用ALTER DATABASE CHARACTER SET UTF8。
2.5 客戶端字符集（NLS_LANG參數）
2.5.1客戶端字符集含義
客戶端字符集定義了客戶端字符數據的編碼方式，任何發自或發往客戶端的字符數據均使用客戶端定義的字符集編碼,客戶端可以看作是能與數據庫直接連接的各種應用，例如sqlplus,exp/imp等。客戶端字符集是通過設置NLS_LANG參數來設定的。
2.5.2 NLS_LANG參數格式
NLS_LANG=<language>_<territory>.<client character set>
Language:顯示oracle消息,校驗，日期命名
Territory：指定默認日期、數字、貨幣等格式
Client character set：指定客戶端將使用的字符集
例如：NLS_LANG=AMERICAN_AMERICA.US7ASCII
AMERICAN是語言，AMERICA是地區，US7ASCII是客戶端字符集
2.5.3客戶端字符集設置方法
1)UNIX環境
$NLS_LANG=“simplified chinese”_china.zhs16gbk
$export NLS_LANG
編輯oracle用戶的profile文件
2)Windows環境
編輯注冊表
Regedit.exe---HKEY_LOCAL_MACHINE---SOFTWARE---ORACLE—HOME0
2.5.4 NLS參數查詢
Oracle提供若干NLS參數定制數據庫和用戶機以適應本地格式，例如有NLS_LANGUAGE,NLS_DATE_FORMAT,NLS_CALENDER等，可以通過查詢以下數據字典或v$視圖查看。
NLS_DATABASE_PARAMETERS--顯示數據庫當前NLS參數取值，包括數據庫字符集取值
NLS_SESSION_PARAMETERS--顯示由NLS_LANG 設置的參數，或經過alter session 改變后的參數值（不包括由NLS_LANG 設置的客戶端字符集）
NLS_INSTANCE_PARAMETE--顯示由參數文件init<SID>.ora 定義的參數V$NLS_PARAMETERS--顯示數據庫當前NLS參數取值
2.5.5修改NLS參數
使用下列方法可以修改NLS參數
（1）修改實例啟動時使用的初始化參數文件
（2）修改環境變量NLS_LANG
（3）使用ALTER SESSION語句，在oracle會話中修改
（4）使用某些SQL函數
NLS作用優先級別：Sql function>alter session>環境變量或注冊表>參數文件>數據庫默認參數
三．導入/導出與字符集轉換
3.1 EXP/IMP
Export 和 Import 是一對讀寫Oracle數據的工具。Export 將 Oracle 數據庫中的數據輸出到操作系統文件中, Import 把這些文件中的數據讀到Oracle 數據庫中，由于使用exp/imp進行數據遷移時，數據從源數據庫到目標數據庫的過程中有四個環節涉及到字符集，如果這四個環節的字符集不一致，將會發生字符集轉換。
EXP
IMP
四個字符集是
（1）源數據庫字符集
（2）Export過程中用戶會話字符集（通過NLS_LANG設定）
（3）Import過程中用戶會話字符集（通過NLS_LANG設定）
（4）目標數據庫字符集
3.2導出的轉換過程
在Export過程中，如果源數據庫字符集與Export用戶會話字符集不一致，會發生字符集轉換，并在導出文件的頭部幾個字節中存儲Export用戶會話字符集的ID號。在這個轉換過程中可能發生數據的丟失。
例:如果源數據庫使用ZHS16GBK，而Export用戶會話字符集使用US7ASCII，由于ZHS16GBK是16位字符集,而US7ASCII是7位字符集，這個轉換過程中，中文字符在US7ASCII中不能夠找到對等的字符，所以所有中文字符都會丟失而變成“?? ”形式，這樣轉換后生成的Dmp文件已經發生了數據丟失。
因此如果想正確導出源數據庫數據，則Export過程中用戶會話字符集應等于源數據庫字符集或是源數據庫字符集的超集
3.3導入的轉換過程
（1）確定導出數據庫字符集環境
通過讀取導出文件頭，可以獲得導出文件的字符集設置
（2）確定導入session的字符集，即導入Session使用的NLS_LANG環境變量
（3）IMP讀取導出文件
讀取導出文件字符集ID，和導入進程的NLS_LANG進行比較
（4）如果導出文件字符集和導入Session字符集相同，那么在這一步驟內就不需要轉換，如果不同，就需要把數據轉換為導入Session使用的字符集。可以看出，導入數據到數據庫過程中發生兩次字符集轉換
第一次:導入文件字符集與導入Session使用的字符集之間的轉換，如果這個轉換過程不能正確完成，Import向目標數據庫的導入過程也就不能完成。
第二次:導入Session字符集與數據庫字符集之間的轉換。
然而,oracle8i的這種轉換只能在單字節字符集之間進行,oracle8i導入Session不支持多字節字符集之間的轉換，因此為了避免第一次轉換，導入Session使用的NLS_LANG與導出文件字符集相同，第二次轉換（通過SQL*Net）支持任何兩種字符集。以上情況在Oracle9i中略有不同
四．亂碼問題
oracle在數據存儲、遷移過程中經常發生字符亂碼問題，歸根到底是由于字符集使用不當引起。下面以使用客戶端sqlplus向數據庫插入數據和導入/導出（EXP/IMP）過程為例，說明亂碼產生的原因。
4.1使用客戶端sqlplus向數據庫存儲數據
這個過程存在3個字符集設置
（1）客戶端應用字符集
（2）客戶端NLS_LANG參數設置
（3）服務器端數據庫字符集(Character Set)設置
客戶端應用sqlplus中能夠顯示什么樣的字符取決于客戶端操作系統語言環境(客戶端應用字符集)，但在應用中錄入這些字符后，這些字符能否在數據庫中正常存儲，還與另外兩個字符集設置緊密相關，其中客戶端NLS_LANG參數主要用于字符數據傳輸過程中的轉換判斷。常見的亂碼大致有兩種情形：
（1）漢字變成問號“？”；
當從字符集A 轉換成字符集B時，如果轉換字符之間不存在對應關系，NLS_LANG使用替代字符“？”替代無法映射的字符
（2）漢字變成未知字符（雖然有些是漢字，但與原字符含義不同）
轉換存在對應關系，但字符集A 中的字符編碼與字符集B 中的字符編碼代表不同含義
4.2發生亂碼原因
亂碼產生是由于幾個字符集之間轉換不匹配造成，分以下幾種情況：
（注：字符集之間如果不存在子集、超集對應關系時的情況不予考慮，因為這種情況下字符集之間轉換必產生亂碼）
1）服務器端數據庫字符集與客戶端應用字符集相同，與客戶端NLS_LANG參數設置不同
如果客戶端NLS_LANG字符集是其它兩種字符集的子集，轉換過程將出現亂碼。
解決方法：將三種字符集設置成同一字符集，或NLS_LANG字符集是其它兩種字符集的超集
2）服務器端數據庫字符集與客戶端NLS_LANG參數設置相同，與客戶端應用字符集不同
如果客戶端應用字符集是其它兩種字符集的超集時，轉換過程將出現亂碼，但對于單字節編碼存儲中文問題，可參看本文第5章節的分析
3）客戶端應用字符集、客戶端NLS_LANG參數設置、服務器端數據庫字符集互不相同
此種情況較為復雜，但三種字符集之間只要有不能轉換的字符，則必產生亂碼
4.3導入/導出過程出現亂碼原因
這個過程存在4個字符集設置，在3.1章節中已分析
（1）源數據庫字符集
（2）EXP過程中NLS_LANG參數
（3）IMP過程中NLS_LANG參數
（4）目標數據庫字符集
出現亂碼原因
1）當源數據庫字符集不等于EXP過程中NLS_LANG參數，且源數據庫字符集是EXP過程中NLS_LANG的子集，才能保證導出文件正確，其他情況則導出文件字符亂碼
2）EXP過程中NLS_LANG字符集不等于IMP過程中NLS_LANG字符集，且EXP過程中NLS_LANG字符集是IMP過程中NLS_LANG字符集的子級, 才能保證第一次轉換正常，否則第一次轉換中出現亂碼。
3）如果第一次轉換正常，IMP過程中NLS_LANG字符集是目標數據庫字符集的子集或相同，才能保證第二次轉換正常，否則則第二次轉換中出現亂碼
五．單字節編碼存儲中文問題
由于歷史的原因，早期的oracle沒有中文字符集（如oracle6、oracle7、oracle7.1）,但有的用戶從那時起就使用數據庫了，并用US7ASCII字符集存儲了中文，或是有的用戶在創建數據庫時，不考慮清楚，隨意選擇一個默認的字符集，如WE8ISO8859P1或US7ASCII，而這兩個字符集都沒有漢字編碼，雖然有些時候選用這種字符集好象也能正常使用，但用這種字符集存儲漢字信息從原則上說就是錯誤的，它會給數據庫的使用與維護帶來一系列的麻煩。
正常情況下，要將漢字存入數據庫，數據庫字符集必須支持中文，而將數據庫字符集設置為US7ASCII等單字節字符集是不合適的。US7ASCII字符集只定義了128個符號，并不支持漢字。另外，如果在SQL*PLUS中能夠輸入中文，操作系統缺省應該是支持中文的，但如果在NLS_LANG中的字符集設置為US7ASCII，顯然也是不正確的，它沒有反映客戶端的實際情況。但在實際應用中漢字顯示卻是正確的，這主要是因為Oracle檢查數據庫與客戶端的字符集設置是同樣的，那么數據在客戶與數據庫之間的存取過程中將不發生任何轉換，但是這實際上導致了數據庫標識的字符集與實際存入的內容是不相符的。而在SELECT的過程中，Oracle同樣檢查發現數據庫與客戶端的字符集設置是相同的，所以它也將存入的內容原封不動地傳送到客戶端，而客戶端操作系統識別出這是漢字編碼所以能夠正確顯示。
在這個例子中，數據庫與客戶端都沒有設置成中文字符集，但卻能正常顯示中文，從應用的角度看好象沒問題。然而這里面卻存在著極大的隱患，比如在應用length或substr等字符串函數時，就可能得到意外的結果。
對于早期使用US7ASCII字符集數據庫的數據遷移到oracle8i/9i中（使用zhs16gbk），由于原始數據已經按照US7ASCII格式存儲，對于這種情況，可以通過使用Oracle8i的導出工具，設置導出字符集為US7ASCII，導出后使用UltraEdit等工具打開dmp文件，修改第二、三字符，修改 0001 為0354,這樣就可以將US7ASCII字符集的數據正確導入到ZHS16GBK的數據庫中。
六．結束語
為了避免在數據庫遷移過程中由于字符集不同導致的數據損失，oracle提供了字符集掃描工具（character set scanner），通過這個工具我們可以測試在數據遷移過程中由于字符集轉換可能帶來的問題，然后根據測試結果，確定數據遷移過程中最佳字符集解決方案。