oracle中的數(shù)據(jù)庫亂碼的原因與解決

2019-11-18 12:04:38

字體：大中小

供稿：網(wǎng)友

　　“在SQL*Plus中用insert插進的都是中文的，為什么一存入服務(wù)器后，再select出的就是???”
　　
　　“有的時候，服務(wù)器數(shù)據(jù)先導(dǎo)出，重裝服務(wù)器，再導(dǎo)入數(shù)據(jù)，結(jié)果，發(fā)生數(shù)據(jù)查詢成???”
　　
　　……
　　
　　這些問題，一般是因為字符集設(shè)置不對造成的。
　　
　　很久以來，字符集一直是困擾著眾多Oracle愛好者的問題，筆者從事Oracle數(shù)據(jù)庫治理和應(yīng)用已經(jīng)幾年了，經(jīng)常接到客戶的類似上面提到的有關(guān)數(shù)據(jù)庫字符集的“告急”和“求救”，在此我們就這個問題做一些分析和探討。
　　
　　首先，我們要明確什么是字符集？字符集是一個字節(jié)數(shù)據(jù)的解釋的符號集合,有大小之分,有相互的包括關(guān)系,如us7ascii就是zhs16gbk的子集,從us7ascii到zhs16gbk不會有數(shù)據(jù)解釋上的問題,不會有數(shù)據(jù)丟失,Oracle對這種問題也要求從子集到超集的導(dǎo)出受支持,反之不行。在所有的字符集中utf8應(yīng)該是最大,因為它基于unicode,雙字節(jié)保存字符(也因此在存儲空間上占用更多)。
　　
　　其次，一旦數(shù)據(jù)庫創(chuàng)建后，數(shù)據(jù)庫的字符集是不能改變的。因此，在設(shè)計和安裝之初考慮使用哪一種字符集是十分重要的。數(shù)據(jù)庫字符集應(yīng)該是操作系統(tǒng)本地字符集的一個超集。存取數(shù)據(jù)庫的客戶使用的字符集將決定選擇哪一個超集，即數(shù)據(jù)庫字符集應(yīng)該是所有客戶字符集的超集。
　　
　　在實際應(yīng)用中，和字符集問題關(guān)系最大的恐怕就是eXP/imp了。在做exp/imp時，假如Client 和Server的nls_lang設(shè)置是一樣的，一般就沒有問題的。但是，要在兩個不同字符集的系統(tǒng)之間導(dǎo)數(shù)據(jù)就經(jīng)常會有這樣或那樣的問題，如，導(dǎo)出時數(shù)據(jù)庫的顯示正常，是中文，當(dāng)導(dǎo)入到其他系統(tǒng)時，就成了亂碼，這也是一類常見問題。
　　
　　現(xiàn)在，介紹一些與字符集有關(guān)的NLS_LANG參數(shù)，
　　
　　NLS_LANG格式：
　　NLS_LANG = language_territory.charset
　　
　　有三個組成部分（語言、地域和字符集），每個成分控制了NLS子集的特性。其中：language 指定服務(wù)器消息的語言。
　　
　　territory 指定服務(wù)器的日期和數(shù)字格式。
　　
　　charset 指定字符集
　　
　　例如：　
　　AMERICAN_AMERICA.US7SCII
　　
　　AMERICAN _ AMERICA. ZHS16GBK
　　
　　
　　還有一些子集可以更明確定義NLS_LANG參數(shù)：　
　　DICT.BASE 數(shù)據(jù)字典基本表版本
　　
　　DBTIMEZONE 數(shù)據(jù)庫時區(qū)
　　
　　NLS_LANGUAGE 語言
　　
　　NLS_TERRITORY 地域
　　
　　NLS_CURRENCY 本地貨幣字符
　　
　　NLS_ISO_CURRENCY ISO貨幣字符
　　
　　NLS_NUMERIC_CHARACTERS 小數(shù)字符和組分隔開
　　
　　NLS_CHARACTERSET 字符集
　　
　　NLS_CALENDAR 日歷系統(tǒng)
　　
　　NLS_DATE_FORMAT 缺省的日期格式
　　
　　NLS_DATE_LANGUAGE 缺省的日期語言
　　
　　NLS_SORT 字符排序序列
　　
　　NLS_TIME_FORMAT 時間格式
　　
　　NLS_TIMESTAMP_FORMAT 時間戳格式
　　
　　……
　　通過PRops$動態(tài)性能視圖，我們可以查看數(shù)據(jù)庫的字符集信息：　
　　$> sqlplus internal
　　
　　SQL> desc props$
　　
　　Name Type Nullable Default Comments
　　
　　NAME VARCHAR2(30)
　　
　　VALUE$ VARCHAR2(4000) Y
　　
　　COMMENT$ VARCHAR2(4000) Y
　　
　　SQL> set arraysize 1
　　
　　SQL> col value$ format a40
　　
　　SQL> select name,value$ from props$ where name=‘NLS_CHARACTERSET’;
　　
　　NAME VALUE$
　　
　　NLS_CHARACTERSET ZHS16GBK
　　
　　SQL> select * from sys.props$;
　　
　　NAME VALUE$
　　
　　DICT.BASE 2
　　
　　DBTIMEZONE 0:00
　　
　　NLS_LANGUAGE AMERICAN
　　
　　NLS_TERRITORY AMERICA
　　
　　NLS_CURRENCY $
　　
　　NLS_ISO_CURRENCY AMERICA
　　
　　NLS_NUMERIC_CHARACTERS .,
　　
　　NLS_CHARACTERSET ZHS16GBK
　　
　　NLS_CALENDAR GREGORIAN
　　
　　NLS_DATE_FORMAT DD-MON-RR
　　
　　NLS_DATE_LANGUAGE AMERICAN
　　
　　NLS_SORT BINARY
　　
　　NLS_TIME_FORMAT HH.MI. SSXFF AM
　　
　　NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
　　
　　NLS_TIME_TZ_FORMAT HH.MI.
　　
　　SSXFF AM TZH:TZM
　　
　　NLS_TIMESTAMP_TZ_FORMAT DD-MON- RR HH.MI. SSXFF AM TZH:TZM
　　
　　NLS_DUAL_CURRENCY $
　　
　　NLS_COMP BINARY
　　
　　NLS_NCHAR_CHARACTERSET ZHS16GBK
　　
　　NLS_RDBMS_VERSION 8.1.6.0.0
　　
　　NAME VALUE$
　　
　　GLOBAL_DB_NAME SCPDB1
　　
　　EXPORT_VIEWS_VERSION 8
　　
　　22 rows selected
　　
　　SQL>
　　
　　從結(jié)果可以看出：　
　　NLS_LANG = AMERICAN _ AMERICA. ZHS16GBK
　　
　　雖然，數(shù)據(jù)庫的字符集是在create database的時候指定的，以后不答應(yīng)改變，但在一個已經(jīng)建立好的數(shù)據(jù)庫上，我們可以通過修改SYS.PROPS$來修改主要是對應(yīng)客戶端的顯示，與存儲無關(guān)。
　　
　　如：
　　
　　SQL> conn / as sysdba
　　
　　Connected.
　　
　　SQL> SQL> select * from sys.props$
　　
　　2 WHERE NAME=‘NLS_LANGUAGE’;
　　
　　NAME VALUE$
　　
　　NLS_LANGUAGE AMERICAN
　　
　　SQL>
　　
　　SQL> UPDATE sys.PROPS$ SET VALUE$=‘SIMPLIFIED CHINESE’
　　
　　2 WHERE NAME=‘NLS_LANGUAGE’;
　　
　　1 row updated
　　
　　SQL>
　　
　　SQL> select * from sys.props$
　　
　　2 WHERE NAME=‘NLS_LANGUAGE’;
　　
　　NAME VALUE$
　　
　　NLS_LANGUAGE SIMPLIFIED CHINESE
　　
　　SQL>
　　
　　通常出現(xiàn)問題的原因，可分為三種：　
　　1. 服務(wù)器指定字符集與客戶字符集不同，而與加載數(shù)據(jù)字符集一致。
　　
　　解決方法：對于這種情況，只需要設(shè)置客戶端字符集與服務(wù)器端字符集一致就可以了，具體操作如下：
　　
　　* 查看當(dāng)前字符集：
　　
　　SQL> select * from sys.props$
　　
　　2 WHERE NAME=‘NLS_CHARACTERSET’;
　　
　　NAME VALUE$
　　
　　
　　NLS_CHARACTERSET ZHS16GBK
　　
　　SQL>
　　
　　可以看出，現(xiàn)在服務(wù)器端Oracle數(shù)據(jù)庫的字符集為‘ZHS16GBK’
　　
　　* 根據(jù)服務(wù)器的字符集在客戶端作相應(yīng)的配置或者安裝Oracle的客戶端軟件時指定：
　　
　　假如還沒安裝客戶端，那么在安裝客戶端時，指定與服務(wù)器相吻合的字符集即可；假如已經(jīng)安裝好了客戶端，并且客戶端為 sql*net 2.0 以下版本，進入Windows的系統(tǒng)目錄，編輯oracle.ini文件，用US7ASCII替換原字符集，重新啟動計算機，設(shè)置生效；否則，假如，客戶端為 sql*net 2.0 以上版本，在Win98 下運行REGEDIT,第一步選HKEY_LOCAL_MACHINE,第二步選擇SOFTWARE，第三步選擇 Oracle，第四步選擇 NLS_LANG，鍵入與服務(wù) 器端相同的字符集
　　
　　（本例為：HKEY_LOCAL_MACHINE/
　　
　　SOFTWARE/ORACLE/NLS_LANG ：AMERICAN _ AMERICA. ZHS16GBK）。
　　
　　 假如是UNIX客戶端，則：　
　　SQL> conn / as sysdba
　　
　　Connected.
　　
　　SQL> SQL> UPDATE sys.PROPS$ SET VALUE$=‘SIMPLIFIED CHINESE’
　　
　　2 WHERE NAME=‘NLS_LANGUAGE’;
　　
　　1 row updated
　　
　　SQL> COMMIT;
　　
　　Commit complete
　　
　　SQL>
　　2. 服務(wù)器指定字符集與客戶字符集相同,與加載數(shù)據(jù)字符集不一致。
　　
　　解決方法：強制加載數(shù)據(jù)字符集與服務(wù)器端字符集一致。要做到這一點，可以通過重新創(chuàng)建數(shù)據(jù)庫，并選擇與原卸出數(shù)據(jù)一致的字符集，然后IMP數(shù)據(jù)，這種情況僅僅適用于空庫和具有同一種字符集的數(shù)據(jù)。
　　
　　解決這類問題，也可以先將數(shù)據(jù)加載到具有相同字符集的服務(wù)器上，然后用轉(zhuǎn)換工具卸出為foxbase 格式或 access格式數(shù)據(jù)庫，再用轉(zhuǎn)換工具轉(zhuǎn)入到不同字符集的Oracle數(shù)據(jù)庫中，這樣就避免了Oracle字符集的困擾。目前數(shù)據(jù)庫格式轉(zhuǎn)換的工具很多,像power builder5.0以上版本提供的pipeline及Microsoft Access數(shù)據(jù)庫提供的數(shù)據(jù)導(dǎo)入/導(dǎo)出功能等。
　　
　　3. 服務(wù)器指定字符集與客戶字符集不同,與輸入數(shù)據(jù)字符集不一致。
　　
　　對于這種情況，目前為止都還沒有太好的解決方法。
　　
　　通過上面的了解，我們知道，導(dǎo)致在后期使用數(shù)據(jù)庫時出現(xiàn)種種關(guān)于字符集的問題，多半是由于在數(shù)據(jù)庫設(shè)計、安裝之初沒有很好地考慮到以后的需要，所以，我們完全可以通過在服務(wù)器上和客戶端使用相同的字符集來避免由此類問題引出的麻煩

上一篇：Bugzero的安裝過程和碰到的花絮

下一篇：實戰(zhàn)Visual Basic.Net對話框