Oracle字符集問題

一．引言 ?

??? 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編碼)，iso8859-1 都應用于英文系列．
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編碼字符集。

下面介紹幾鐘常用的字符編碼集 ：　　

iso8859-1

　　屬于單字節編碼，最多能表示的字符范圍是0-255，應用于英文系列。比如，字母'a'的編碼為0x61=97。很明顯，iso8859-1編 碼表示的字符范圍很窄，無法表示中文字符。但是，由于是單字節編碼，和計算機最基礎的表示單位一致，所以很多時候，仍舊使用iso8859-1編碼來表 示。而且在很多協議上，默認使用該編碼。比如，雖然"中文"兩個字不存在iso8859-1編碼，以gb2312編碼為例，應該是"d6d0 cec4"兩個字符，使用iso8859-1編碼的時候則將它拆開為4個字節來表示："d6 d0 ce c4"（事實上，在進行存儲的時候，也是以字節為單位處理的）。而如果是UTF編碼，則是6個字節"e4 b8 ad e6 96 87"。很明顯，這種表示方法還需要以另一種編碼為基礎。

GB2312/GBK

　　這就是漢字的國標碼，專門用來表示漢字，是雙字節編碼，而英文字母和iso8859-1一致（兼容iso8859-1編碼）。其中gbk編碼能夠用來同時表示繁體字和簡體字，而gb2312只能表示簡體字，gbk是兼容gb2312編碼的。

???????? unicode

??????? 這是最統一的編碼，可以用來表示所有語言的字符，而且是定長雙字節（也有四字節的）編碼，包括英文字母在內。所以可以說它是不兼iso8859-1編碼 的，也不兼容任何編碼。不過，相對于iso8859-1編碼來說，uniocode編碼只是在前面增加了一個0字節，比如字母'a'為"00 61"。需要說明的是，定長編碼便于計算機處理（注意GB2312/GBK不是定長編碼），而unicode又可以用來表示所有字符，所以在很多軟件內部 是使用unicode編碼來處理的，比如java。

???????? UTF

???????? 考慮到unicode編碼不兼容iso8859-1編碼，而且容易占用更多的空間：因為對于英文字母，unicode也需要兩個字節來表示。所以 unicode不便于傳輸和存儲。因此而產生了utf編碼，utf編碼兼容iso8859-1編碼，同時也可以用來表示所有語言的字符，不過，utf編碼 是不定長編碼，每一個字符的長度從1-6個字節不等。另外，utf編碼自帶簡單的校驗功能。一般來講，英文字母都是用一個字節表示，而漢字使用三個字節。 注意，雖然說utf是為了使用更少的空間而使用的，但那只是相對于unicode編碼來說，如果已經知道是漢字，則使用GB2312/GBK無疑是最節省 的。不過另一方面，值得說明的是，雖然utf編碼對漢字使用3個字節，但即使對于漢字網頁，utf編碼也會比unicode編碼節省，因為網頁中包含了很 多的英文字符。

?

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.4.5查詢Oracle Server端字符集
???? SQL>select userenv(‘language’) from dual;

?

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 中略有不同。

3.4?查詢dmp文件的字符集

???? 用Oracle的exp工具導出的dmp文件也包含了字符集信息，dmp文件的第2和第3個字節記錄了dmp文件的字符集。如果dmp文件不大，比如只有 幾M或幾十M，可以用UltraEdit打開(16進制方式)，看第2第3個字節的內容，如0354，然后用以下SQL查出它對應的字符集:

???? SQL> select nls_charset_name(to_number('0354','xxxx')) from dual;
???? ZHS16GBK
????
???? 如果dmp文件很大，比如有2G以上(這也是最常見的情況)，用文本編輯器打開很慢或者完全打不開，可以用以下命令(在unix主機上):?
???? cat exp.dmp |od -x|head -1|awk '{print $2 $3}'|cut -c 3-6? ,然后用上述SQL也可以得到它對應的字符集
???
3.5 修改dmp文件字符集

????? dmp文件的第2第3字節記錄了字符集信息，因此直接修改dmp文件的第2第3字節的內容就可以‘騙’過oracle的檢查。這樣做理論上也僅是從子集到 超集可以修改，但很多情況下在沒有子集和超集關系的情況下也可以修改，我們常用的一些字符集，如 US7ASCII，WE8ISO8859P1，ZHS16CGB231280，ZHS16GBK基本都可以改。因為改的只是dmp文件，所以影響不大。

　　具體的修改方法比較多，最簡單的就是直接用UltraEdit修改dmp文件的第2和第3個字節。比如想將dmp文件的字符集改為ZHS16GBK，可以用以下SQL查出該種字符集對應的16進制代碼:

SQL> select to_char(nls_charset_id('ZHS16GBK'), 'xxxx') from dual;

　　0354

　　然后將dmp文件的2、3字節修改為0354即可。

四．亂碼問題

?

??? 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），通過這個工具我們可以測試在數據遷移過程中由于字符集轉換可能帶來的問題，然后根據測試結果，確定數據遷移過程中最佳字符集解決方案。

?

轉至：http://www.fish888.com/

Oracle字符集問題