oracle
全球支援(即
globalization support)
允許我們使用本地語言和格式來儲存和檢索資料。通過全球支援，
oracle
可以支援多種語言及字符集。
字符集在建立資料庫時指定，在建立後通常不能更改，所以在建立資料庫時能否選擇乙個正確的字符集就顯得尤為重要
.在建立資料庫時，我們可以指定字符集
(character set)
和國家字符集
(national character set)
。字符集用來儲存
:char, varchar2, clob, long
等型別資料
用來標示諸如表名、列名以及
pl/sql
變數等sql
和pl/sql
程式單元等
國家字符集用以儲存
:nchar, nvarchar2, nclob
等型別資料
oracle
的字符集命名遵循以下命名規則:
即:<
語<
位元位數
><
編比如: zhs·16
·gbk
需要說明的是，有些字符集命名違背了這個規範，
oracle8/oralce8i
中的utf-8
是第乙個打破這個命名規範的字符集
.我們可以看到一類字符集以
al開頭，如
:al16utf16 其中
al代表
all,
指適用於所有語言
(alllanguages)
，按照這個標準當年
utf-8
本應被命名為
al24utf8
。匯入匯出是我們常用的乙個資料遷移及轉化工具，因其匯出檔案具有平台無關性，所以在跨平台遷移中，最為常用。
在匯出操作時，非常重要的是客戶端的字符集設定，也就是客戶端的
nls_lang
設定。nls_lang
引數由以下部分組成
:nls_lang=_.
nls_lang
各部分含義如下
:language指定:
-oracle
訊息使用的語言
-日期中月份和日顯示
territory指定-
貨幣和數字格式
-地區和計算星期及日期的習慣
characterset:
-控制客戶端應用程式使用的字符集
通常設定或者等於客戶端(如
windows)
**頁或者對於
unicode
應用設定為
utf8
在windows
上檢視當前系統的**頁可以使用
chcp命令:
e:\>chcp
活動的**頁
: 936
**頁936
也就是中文字符集
gbk,
在microsoft
的官方站點上，我們可以遭到關於
936**頁的具體編碼規則,:
檢視客戶端
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
客戶端設定
,可以在登錄檔中更改
nls_lang,
具體鍵值位於
:hkey_local_machine\software\oracle\homexx\
xx指存在多個
oracle_home
時系統編號。
匯出使用的字符集將會記錄在匯出檔案中，當檔案匯入時，將會檢查匯出時使用的字符集設定，如果這個字符集不同於匯入客戶端的
nls_lang
設定，字符集將根據匯入客戶端
nls_lang
設定進行轉換，如果必要，在資料插入資料庫之前會進行進一步轉換。
通常在匯出時最好把客戶端字符集設定得和資料庫端相同，這樣可以避免在匯出時發生不必要的資料轉換，匯出檔案將和資料庫具有相同的字符集。
即使將來會把匯出檔案匯入到不同字符集的資料庫中，這樣做也可以把轉換延緩至匯入時刻。
當進行資料匯入時，主要存在以下兩種情況:1.
源資料庫和目標資料庫具有相同字符集設定
這時，只需要設定
nls_lang
等於資料庫字符集即可匯入
(前提是，匯出使用的是和源資料庫相同字符集，即三者相同)2.
源資料庫和目標資料庫字符集不同
如果我們匯出時候使用的
nls_lang
是和源資料庫相同的字符集，那麼匯入時就可以設定客戶端
nls_lang
等於匯出時使用的字符集，這樣轉換只發生在資料庫端，而且只發生一次。
通常在我們的現實環境中，存在
3個字符集設定。第一:
客戶端應用字符集第二:
客戶端nls_lang
引數設定第三:
伺服器端，資料庫字符集
(characterset)
設定我們說，乙個字元在客戶端應用(比如
sqlplus,cmd,notepad等)
中以怎樣的字元顯示取決於客戶端作業系統，客戶端能夠顯示怎樣的字元，我們就可以在應用中錄入這些字元，至於這些字元能否在資料庫中正常儲存，就和另外的兩個字符集設定緊密相關了。
在傳輸過程中，客戶端
nls_lang
主要用於進行轉換判斷
如果nls_lang
等於資料庫字符集，則不進行任何轉換直接把字元插入資料庫
如果不同則進行轉換，轉換主要有兩個任務
•如果存在對應關係，則把相應二進位制編碼經過對映後
(這一步對映以後，所代表的字元可能發生轉換
)傳遞給資料庫
•如果不存在對應關係，則傳遞乙個替換字元
(很多平台就是
?)資料庫字符集，在和客戶端
nls_lang
不同時，會把經過
nls_lang
轉換的字元進行進一步處理
•對於?
（即不存在對應關係的字元）直接以？形式存放入資料庫
•對於其他字元，在
nls_lang
和資料庫字符集之間進行轉換後存入。
以下我們來看一下最為常見的字符集及亂碼的產生:1.
當nls_lang
字符集與資料庫字符集不同，同時
nls_lang
不同於server
端字符集設定
在這種情況下，存在兩種可能
:•客戶端輸入的字元在
nls_lang
中沒有對應的字元，這時無法轉換，
nls_lang
使用替換字元替代這些無法對映的字元
(這一步轉換在
tts中完成
)，在很多字符集中這個替代字元就是」?」
•當客戶端的字元在
nls_lang
中對應了不同的字元時，傳遞給資料庫以後發生轉換，儲存的是字元，但是已經丟失了元資料，資料庫中的字元不再代表客戶端的輸入。而且這個過程不可逆，這也就是為什麼很多時候在客戶端輸入的是正常的編碼，查詢之後會得到未知字元的原因。
nls_lang
和資料庫字符集相同時
在這種情況下，資料庫端對客戶端傳遞過來的編碼不進行任何轉換
(這樣可以提高效能
)，直接儲存進入資料庫，那麼這時候就存在和上面同樣的問題，如果客戶端傳遞過來的字符集在資料庫中有正確的對應就可以正確儲存，如果沒有，就會被替換字元置換成？，亂碼就這樣產生了
如上圖所示，當
nls_lang
和資料庫字符集設定相同都為
utf8
時，客戶端的歐元符號的編碼
a4就不會經過任何轉換就插入到資料庫中，而在
utf8
的資料庫中，
a4代表的是乙個非法字元。
字符集更改鏈結
mysql字符集問題 mysql字符集問題
我們新建mysql資料庫的時候，需要指定資料庫的字符集，一般我們都是選擇utf8這個字符集，但是還會又乙個utf8mb4這個字符集，好像和utf8有聯絡，今天就來解析一下這兩者的區別。起源mysql在5.5.3之後增加了這個utf8mb4的編碼，mb4就是most bytes 4的意思，專門用來相容...
mysql字符集問題 mysql字符集問題
用show variables like char 檢視mysql的引數,結果應如下 mysql show variables like char variable name value character set client gbk character set connection gbk ch...
mysql字符集問題 MySql字符集問題
mysql字符集問題 xinjinlong 2010 11 14 22 10 47 閱讀 1334 上次說了一下c從mysql裡面讀取資料，這次在介紹一下如何把mysql的字符集設定為utf8 第一 檢視自己mysql的字符集 mysql show variables like character ...