專題實驗字符集全球化支援）

character set al32utf8

national character set al16utf16

這裡推薦使用 unicode 字符集, 這也是大趨勢, unicode協會的口號是, 給每個字元提供了乙個唯一的數字, 無論是什麼平台, 無論是什麼程式, 無論是什麼語言.

字符集, 是指我們輸入的字元所對應的乙個編碼, 字符集不同, 所對應的編碼就不同, 可以使用dump('你') 檢視當前的編碼, 編碼不同, 意味著有可能出現亂碼, 另外, 字符集等字元的顯示也有很重要的影響, 比如日期的顯示樣式等.

注: 建立資料庫以後想改變字符集是一件很困難的事情, 所以, 最好在建立資料庫以前就準備好.

client 端字符集, server 端字符集, 某些字符集之間可以發生轉換.( 子集-超集的關係才可以)

nls_lang=language_territory.charset :

language: 伺服器訊息語言

territory: 地區, 指定了伺服器的日期和數字等的格式

charset: 字符集

從nls_lang 的組成我們可以看出, 真正影響資料庫字符集的其實是第三部分, 所以兩個資料庫之間的字符集只要第三部分一樣就可以相互匯入匯出資料, 前面影響的只是提示資訊.

匯入匯出(imp/exp)是乙個常用的資料遷移及轉化工具, 因其匯出檔案具有平台無關性, 所以在跨平台遷移中, 最為常用, 在使用exp工具進行匯出操作時, 非常重要的時客戶端的字符集設定, 也就是客戶端的nls_lang設定

自己以前在客戶端執行乙個指令碼時, 指令碼的時間格式是英文格式, 但是客戶端的字符集是中文, 所以導致指令碼執行出錯. 修改了客戶端的字符集, 執行指令碼成功的經歷.

傳統的匯入匯出工具(imp/exp)是客戶端軟體, 同sqlplus一樣, 因此, 使用exp/imp工具將同樣按照nls_lang定義的方式呼叫字符集檔案, 並且在伺服器和客戶端之間根據設定進行字符集轉換:

通常在執行匯出操作時, 最好把客戶端字符集設定的和資料庫相同, 這樣同樣避免在匯出時發生不必要的資料轉換, 匯出檔案將和資料庫具有相同的字符集.

1） select * from nls_database_parameters;

2) server 端: select userenv('language') from dual;

3) client端: 主要是檢視 nsl_lang 這個引數.

3個字符集的設定

由於乙個字元在客戶端應用(sqlplus 等)中以怎樣的字元顯示取決於客戶作業系統, 客戶端能夠顯示怎樣的字元, 我們就可以在應用中錄入這些字元, 至於這些字元能否在資料庫中正常儲存, 就和另外兩個字符集設定緊密相關了(通常我們可以忽略應用程式的字符集, 這個字符集在應用程式安裝時, 已經被內在的決定, 並且會依據作業系統的相關設定進行選擇)

在傳輸過程中, 客戶端nls_lang主要用於轉換判斷, 如果客戶端nls_lang等於資料庫字符集, 則不進行任何轉換直接把字元插入資料庫, 如果不同則進行轉換, 轉換有以下兩種:

綜上:1. 客戶端應用字符集, 一般只要滿足輸入就可以了, 也就是說我們輸入的字元是我們本身的意願, 在windows平台如何檢視這個字符集, cmd 命令, 這個工具的字符集決定查詢結果在終端上輸出顯示, 當前這個cmd的字元**頁是936, 對應的時gbk字符集:

2. 客戶端nls_lang: 要麼選擇跟資料庫一樣 al32utf8, 要麼選擇 al32utf8的子集, 具體的集合關係(檢視本blog環境設定裡圖)

3. 資料庫字符集: 個人推薦 al32utf8

專題實驗字符集全球化支援）

mysql支援多少字符集 mysql字符集支援

mysql支援gbk字符集

mysql 字符集支援情況

專題實驗 字符集 全球化支援）

mysql支援多少字符集 mysql字符集支援

mysql支援gbk字符集

mysql 字符集支援情況

相關推薦

專題實驗字符集全球化支援）