oracle的字符集設置與亂碼

時間  2019-11-20
標籤 oracle 字符集 設置 亂碼 欄目 Oracle 简体版
原文   原文鏈接

字符集問題一直叫人頭疼，究其緣由仍是不能徹底明白其運做原理。sql

在整個運行環節中，字符集在3個環節中發揮做用：數據庫

1.軟件在操做系統上運做時的對用戶的顯示，此時採用操做系統定義的字符集進行顯示。咱們在系統I/O編程的時候常常要指定字符集，C#中的Text.Encoding=Encoding.Default實際上就是告訴編譯器，文本使用系統定義的默認字符集進行編碼。sqlplus也是運行在操做系統上的軟件，固然要使用系統所指定的字符集對外顯示內容。編程

2.數據向oracle服務端傳送前的通告。也就是sqlplus告訴服務器如今使用的字符集是什麼。windows

3.數據流到達服務器後，按照服務器所使用的字符集自動翻譯客戶端的數據，而後存儲進系統。bash

 

在客戶端sqlplus和服務端傳送數據，數據會按照服務端字符集進行翻譯，這個過程是自動完成的不須要人工干預。任什麼時候候，oracle服務端老是按照本身的字符集設置來存取數據，客戶端要想正確顯示從服務端讀取到的數據，也須要按照本地的字符集設置進行翻譯，這個過程也是自動的。服務器

 

服務器端須要採用合適的字符集進行數據存儲，這個很容易理解，ASCII字符集沒辦法用來存儲中文漢字，由於它根本沒有描述漢字所須要的編碼空間。session

 

問題經常存在於客戶端與服務端通信的過程當中，sqlplus做爲運行在操做系統上的軟件，不管是顯示仍是通信，必然使用操做系統所使用的字符集設置。不管sqlplus設置的字符集，做用只有一個，那就是通告服務器端，爲相互之間的字符集翻譯作準備。oracle

 

客戶端的字符集設置是在NLS_LANG環境變量中設置的，客戶讀端的字符集能夠和oracle客戶端設置得不同（原本人家就是自動翻譯的），可是客戶端字符集必定要和操做系統設置的字符集相匹配！app

 

考慮一下，sqlplus使用的是操做系統的字符集定義在顯示和發送數據（架設是TYPE_A），卻告訴oracle服務器本身使用的字符集是TYPE_B，oracle服務器會怎麼辦？它會將客戶端發送過來的TYPE_A數據看成TYPE_B字符集格式用自身的TYPE_C字符集進行翻譯，而後再存儲進系統，這就造成了亂碼。反向的過程相似，Oracle服務器發出的數據格式沒有疑問是TYPE_C，可是客戶端軟件認爲本身使用的編碼是TYPE_B並進行了翻譯，交給操做系統用TYPE_A字符集總的字符/編碼映射關係進行翻譯顯示，最終致使了沒法正確顯示。函數

 

一個現實的例子：RHEL5.8操做系統安裝了中文支持包之後，全部的語言環境都被設置成了zh_CN.UTF-8（經過LANG環境變量可知，也可經過locale命令查到）,數據庫服務器所使用的字符集爲ZHS16GBK,很明顯，這二者不一致，sqlplus在沒有設置NLS_LANG環境變量時，與數據庫保持一致，此時，從服務端取得的數據不須要翻譯，被sqlplus讀取並用zh_CN.UTF-8的字符/編碼映射關係進行翻譯顯示，全部的漢字變成了「？」。

 

根據上面的分析，要解決這一問題，要把sqlplus的字符集設置成和操做系統一致便可，操做系統設置的是zh_CN.UTF-8，但在.bash_profile裏面還不能直接將NLS_LANG設置爲zh_CN.UTF-8，由於這個zh_CN.UTF8是字符集的localeID而不是字符集的名稱，真正的名稱叫SIMPLIFIEDCHINESE_CHINA.AL32UTF8，若是設置成zh_CN.UTF8，oracle會報ORA-12705: Cannotaccess NLS data files or invalid environmentspecified錯誤。在.bash_profile裏面加入NLS_LANG="SIMPLIFIEDCHINESE_CHINA.AL32UTF8"; export NLS_LANG問題就解決了。

下表是locale ID與字符集名稱的對應關係：

Language

Locale ID

NLS_LANG

English (American)

en_US.UTF-8

AMERICAN_AMERICA.AL32UTF8

English (American)

en_US.ISO-8859-1

AMERICAN_AMERICA.WE8ISO8859P1

English (American)

en_US.ISO-8859-15

AMERICAN_AMERICA.WE8ISO8859P15

English (Australian)

en_AU.UTF-8

ENGLISH_AUSTRALIA.AL32UTF8

English (Australian)

en_AU.ISO-8859-1

ENGLISH_AUSTRALIA.WE8ISO8859P1

English (Australian)

en_AU.ISO-8859-15

ENGLISH_AUSTRALIA.WE8ISO8859P15

English (British)

en_GB.UTF-8

ENGLISH_UNITED KINGDOM.AL32UTF8

English (British)

en_GB.ISO-8859-1

ENGLISH_UNITED KINGDOM.WE8ISO8859P1

English (British)

en_GB.ISO-8859-15

ENGLISH_UNITEDKINGDOM.WE8ISO8859P15

English (Ireland)

en_IE.UTF-8

ENGLISH_IRELAND.AL32UTF8

English (Ireland)

en_IE.ISO-8859-1

ENGLISH_IRELAND.WE8ISO8859P1

English (Ireland)

en_IE.ISO-8859-15

ENGLISH_IRELAND.WE8ISO8859P15

German

de_DE.UTF-8

GERMAN_GERMANY.AL32UTF8

German

de_DE.ISO-8859-1

GERMAN_GERMANY.WE8ISO8859P1

German

de_DE.ISO-8859-15

GERMAN_GERMANY.WE8ISO8859P15

French

fr_FR.UTF-8

FRENCH_FRANCE.AL32UTF8

French

fr_FR.ISO-8859-1

FRENCH_FRANCE.WE8ISO8859P1

French

fr_FR.ISO-8859-15

FRENCH_FRANCE.WE8ISO8859P15

Italian

it_IT.UTF-8

ITALIAN_ITALY.AL32UTF8

Italian

it_IT.ISO-8859-1

ITALIAN_ITALY.WE8ISO8859P1

Italian

it_IT.ISO-8859-15

ITALIAN_ITALY.WE8ISO8859P15

Spanish

es_ES.UTF-8

SPANISH_SPAIN.AL32UTF8

Spanish

es_ES.ISO-8859-1

SPANISH_SPAIN.WE8ISO8859P1

Spanish

es_ES.ISO-8859-15

SPANISH_SPAIN.WE8ISO8859P15

Spanish (Mexico)

es_MX.UTF-8

MEXICAN SPANISH_MEXICO.AL32UTF8

Spanish (Mexico)

es_MX.ISO-8859-1

MEXICAN SPANISH_MEXICO.WE8ISO8859P1

Spanish (Mexico)

es_MX.ISO-8859-15

MEXICANSPANISH_MEXICO.WE8ISO8859P15

Portuguese (Brazilian)

pt_BR.UTF-8

BRAZILIANPORTUGUESE_BRAZIL.AL32UTF8

Portuguese (Brazilian)

pt_BR.ISO-8859-1

BRAZILIANPORTUGUESE_BRAZIL.WE8ISO8859P1

Portuguese (Brazilian)

pt_BR.ISO-8859-15

BRAZILIANPORTUGUESE_BRAZIL.WE8ISO8859P15

Japanese

ja_JP.EUC-JP

JAPANESE_JAPAN.JA16EUC

Japanese

ja_JP.UTF-8

JAPANESE_JAPAN.AL32UTF8

Korean

ko_KR.EUC-KR

KOREAN_KOREA.KO16KSC5601

Korean

ko_KR.UTF-8

KOREAN_KOREA.AL32UTF8

Chinese (simplified)

zh_CN.GB18030

SIMPLIFIEDCHINESE_CHINA.ZHS32GB18030

Chinese (simplified)

zh_CN.UTF-8

SIMPLIFIED CHINESE_CHINA.AL32UTF8

Chinese (traditional)

zh_TW.BIG5

TRADITIONALCHINESE_TAIWAN.ZHT16BIG5

Chinese (traditional)

zh_TW.UTF-8

TRADITIONAL CHINESE_TAIWAN

 

步驟能夠概括爲：1.找到操做系統使用的字符集，並按上表找到對應的字符集名稱。2.修改客戶端軟件的字符集NLS_LANG環境變量設置。

 

不一樣平臺的一些細節：

Windows（ 如簡體系統爲：ZHS16GBK，繁體系統爲：MSWIN950 ）

一、設置session變量

# 經常使用中文字符集
set NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK

# 經常使用unicode字符集
set NLS_LANG=american_america.AL32UTF8

二、能夠經過修改註冊表鍵值永久設置
HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/HOMExx/NLS_LANG

三、設置環境變量
NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
NLS_LANG=american_america.AL32UTF8


Unix/Linus:

一、設置session變量

# 經常使用unicode字符集
export NLS_LANG=american_america.AL32UTF8

# 經常使用中文字符集
export NLS_LANG="Simplified Chinese_china".ZHS16GBK

三、設置環境變量
能夠編輯 bash_profile文件進行永久設置
# vi .bash_profile
NLS_LANG="Simplified Chinese_china".ZHS16GBK
export NLS_LANG
# 使 bash_profile 設置生效
source .bash_profile

其餘：

一、查看sqlplus客戶編碼：
$ echo 

$NLS_LANG

二、查看系統編碼：
$ locale

三、查看數據庫字符集，執行以下查詢:
select userenv('language') from dual;


做者：hcling97    http://blog.sina.com.cn/hcling97

2013年5月15日

轉載請註明出處 


------------------------------------------------------------------------------------------------------------------------


萬國碼（Unicode）：包含了幾乎人類全部可用的字符，每一年還在不斷的增長，能夠看做是一種通用的字符集。它將全世界全部的字符統一化，統一編碼，不會再出現字符不兼容和字符轉換的問題。它有如下三種編碼方式：
  1. UTF-32編碼：固定使用4個字節來表示一個字符，存在空間利用效率的問題。
  2. UTF-16編碼：對相對經常使用的60000餘個字符使用兩個字節進行編碼，其他的使用4字節。
  3. UTF- 8編碼：兼容ASCII編碼；拉丁文、希臘文等使用兩個字節；包括漢字在內的其它經常使用字符使用三個字節；剩下的極少使用的字符使用四個字節。

Oracle字符集基本原理


在搞懂Oracle字符集基本原理以前，必定要先分清如下三個概念：

1. Oracle數據庫服務器字符集：即Oracle 以哪一種字符編碼存儲字符，能夠經過如下語句查出數據庫字符集的設置。
[sql] view plain copy
  1. SQL> select * from v$nls_parameters where parameter='NLS_CHARACTERSET';  
  2.   
  3. PARAMETER                      VALUE  
  4. ------------------------------ -----------------  
  5. NLS_CHARACTERSET               AL32UTF8  


2. 客戶端操做系統字符集：即客戶端操做系統以哪一種字符編碼存儲字符。

若是是Windows，可使用chcp命令得到代碼頁（code page）：

[sql] view plain copy
  1. C:\Users\xianzhu>chcp  
  2. Active code page: 936  


根據該代碼頁，到微軟的官方文檔《National Language Support (NLS) API Reference》找到其對應的字符集。

若是是Linux，字符集在/etc/sysconfig/i18n設置：

[plain] view plain copy
  1. LANG="zh_CN.GB2312" (指定當前操做系統的字符集)   
  2. SUPPORTED="zh_CN.GB2312"(指定當前操做系統支持的字符集)   
  3. SYSFONT="lat0-sun16"(指定當前操做系統的字體)  

 

3. 客戶端NLS_LANG參數：該參數用於向Oracle指示客戶端操做系統的字符集。


有了以上3個基本概念以後，我來闡述一下Oracle字符集轉換的基本原則：

  1. 設置客戶端的NLS_LANG爲客戶端操做系統的字符集
  2. 若是數據庫字符集等於NLS_LANG，數據庫和客戶端傳輸字符時不做任何轉換
  3. 若是它們倆不等，則須要在不一樣字符集間轉換，只有客戶端操做系統字符集是數據庫字符集子集的基礎上才能正確轉換，不然會出現亂碼。

幾種常見狀況分析

下面先看一個例子，再透過現象看本質，咱們會針對這個例子進行分析。

該例子以下：

[sql] view plain copy
  1. 1. 數據庫字符集爲Unicode（UTF-8編碼）  
  2. 咱們的數據庫版本是10.2.0.4.0，數據庫字符集是：  
  3. SQL> select * from v$nls_parameters where parameter='NLS_CHARACTERSET';  
  4.   
  5. PARAMETER                                VALUE  
  6. ---------------------------------------- ------------------------------  
  7. NLS_CHARACTERSET               AL32UTF8  
  8.   
  9. 2. 客戶端操做系統字符集爲代碼頁936（字符集爲ZHS16GBK）  
  10. 可使用chcp得到windows的代碼頁(code page)  
  11. C:\Documents and Settings\a105024\Desktop>chcp  
  12. Active code page: 936  
  13.   
  14. 3. 建立測試表  
  15. SQL> create table test(id number,var varchar2(30));  
  16.   
  17. Table created.  
  18.   
  19. 4. 插入數據  
  20. 這裏在同一個操做系統啓動兩個session，session1的NLS_LANG設爲和數據庫字符集同樣（即AL32UTF8）：  
  21. C:\Documents and Settings\a105024\Desktop>set nls_lang=Simplified Chinese_China.AL32UTF8  
  22. 鏈接數據庫並插入一條數據：  
  23. Session_1>insert into test values(1,'中國');  
  24.   
  25. 1 row created.  
  26.   
  27. Session_1>commit;  
  28.   
  29. Commit complete.  
  30.   
  31. session2的NLS_LANG設爲和客戶端操做系統同樣（即ZHS16GBK）：  
  32. C:\Documents and Settings\a105024\Desktop>set nls_lang=Simplified Chinese_China.ZHS16GBK  
  33. 鏈接數據庫並插入一條數據：  
  34. Session_2>insert into test values(2,'中國');  
  35.   
  36. 1 row created.  
  37.   
  38. Session_2>commit;  
  39.   
  40. Commit complete.  
  41.   
  42. 5. 執行查詢  
  43. 在session 1上執行查詢：  
  44. Session_1>select * from test;  
  45.   
  46.         ID VAR  
  47. ---------- ---------------------  
  48.          1 中國  
  49.          2 涓   浗  
  50. 在session 2上執行查詢：  
  51. Session_2>select * from test;  
  52.   
  53.         ID VAR  
  54. ---------- --------------------  
  55.          1 ？??  
  56.          2 中國  


上面例子看起來很詭異，session1和2都能正常顯示本身插入的字符串，又都不能正常顯示對方插入的字符串。爲了弄清楚，咱們首先得知道數據庫裏對這兩個字符串是怎麼存儲的。咱們可使用dump函數得到字符在數據庫的編碼:

[sql] view plain copy
  1. SQL> select id,dump(var,1016) from test;  
  2. ID DUMP(VAR,1016)  
  3. -- ------------------------------------------------------------  
  4.  1 Typ=1 Len=4 CharacterSet=AL32UTF8: d6,d0,b9,fa  
  5.  2 Typ=1 Len=6 CharacterSet=AL32UTF8: e4,b8,ad,e5,9b,bd  


根據AL32UTF8的編碼，「中國」兩字的正確編碼爲（都爲3個字節）：
中--e4,b8,ad
國--e5,9b,bd
所以session 1插入的字符串在數據庫中的編碼是錯誤的，session 2正確。這也是爲何必定要設置NLS_LANG爲客戶端操做系統的字符集。

可是根據上面實驗咱們能夠知道，數據庫中存儲正確，並不表明客戶端能正常顯示；一樣地，即時數據庫沒有正確存儲，有時候客戶端也可以正常顯示，這又是爲何呢？別急，請聽我慢慢道來：


場景1：session 1插入，session 1查詢，在數據庫中存儲錯誤，但顯示正確。
插入過程：
」中國「兩字在客戶端操做系統字符集ZHS16GBK中的編碼是」d6,d0,b9,fa"，因爲NLS_LANG和數據庫字符集相同，數據庫端對客戶端傳過來的字符編碼不進行任何轉換直接存入數據庫，所以數據庫中存儲的編碼也是「d6,d0,b9,fa」，
讀取過程：
數據庫端讀取的編碼是「d6,d0,b9,fa」，因爲NLS_LANG和數據庫字符集相同，客戶端對數據庫端傳過來的字符編碼不進行任何轉換直接顯示，編碼」d6,d0,b9,fa「在客戶端操做系統字符集ZHS16GBK對應的漢字爲「中國」。
從以上分析可知，雖然讀取時正確的，但那是由於負負得正，實際上數據庫中存儲是錯誤的，所以要特別當心這種狀況，在生成庫中要避免。其實只要對它進行length操做就能輕易揭開它的假面具：

[sql] view plain copy
  1. Session_1>select length(var) from test where id=1;  
  2.   
  3. LENGTH(VAR)  
  4. -----------  
  5.           3  


得出的長度竟然爲3！實際的長度只是2，這會帶來不少麻煩。

場景2：session 1插入，session 2查詢，在數據庫中存儲錯誤，顯示也錯誤。
插入過程和場景1同樣，這裏就再也不累述。
讀取過程：
數據庫端讀取的編碼是「d6,d0,b9,fa」，因爲NLS_LANG和數據庫字符集不一樣，客戶端對數據庫端傳過來的字符編碼進行轉換，數據庫端字符集AL32UTF8裏編爲「d6,d0,b9,fa」沒法在客戶端操做系統字符集ZHS16GBK裏找到對應的編碼，因此只好用?代替。


場景3：session 2插入，session 1查詢，在數據庫中存儲正確，但顯示錯誤。
插入過程：
」中國「兩字在客戶端操做系統字符集ZHS16GBK中的編碼是」d6,d0,b9,fa"，因爲NLS_LANG和數據庫字符集不一樣，Oracle會進行字符編碼轉換，也就是將字符集ZHS16GBK裏「中國」的編碼「d6,d0,b9,fa"轉換爲字符集"AL32UTF8"裏」中國「的編碼」e4,b8,ad,e5,9b,bd「。
讀取過程：
數據庫端讀取的編碼是」e4,b8,ad,e5,9b,bd「，因爲NLS_LANG和數據庫字符集相同，客戶端對數據庫端傳過來的字符編碼不進行任何轉換直接顯示，編碼」e4,b8,ad,e5,9b,bd「在客戶端操做系統字符集ZHS16GBK對應的漢字爲「涓   浗」（本來2個字符，如今變成了3個字符，由於ZHS16GBK的漢字以2個字節編碼）。


場景4：session 2插入，session 2查詢，在數據庫中存儲正確，顯示也正確。
插入過程和場景3相似。
讀取過程：

數據庫端讀取的編碼是」e4,b8,ad,e5,9b,bd「，因爲NLS_LANG和數據庫字符集不一樣，客戶端對數據庫端傳過來的字符編碼進行轉換，數據庫端字符集AL32UTF8裏」中國「兩字的編碼」e4,b8,ad,e5,9b,bd「轉換成客戶端操做系統字符集ZHS16GBK裏「中國」兩字的編碼「d6,d0,b9,fa"，並正常顯示。

這種狀況雖然通過了兩次轉換，都確實最正確、最推薦的方式。


附錄：Oracle 字符集超集和子集的對應關係可查看：http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/applocaledata.htm#sthref1988


結論：NLS_LANG只和客戶端操做系統的字符集相關，若是客戶端操做系統的字符集和數據庫字符集間沒法正確轉換，則應該首先改變客戶端終端的字符集，而不是簡單地把NLS_LANG設爲和數據庫字符集同樣。

來源：http://blog.csdn.net/dbanote/article/details/9158367，做者：朱顯傑

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程