以下的文章主要講述的是Oracle 8i中字符集亂碼的相關問題的分析以及其具體的解決辦法,其中包括Oracle 8i中字符集亂碼問題的詳細描述,以及相關問題的詳細分析,以下就是文章的具體描述。
一、問題描述
SQL Plus WorkSheet是一個窗口圖形界面的SQL語句編輯器,對於那些喜歡窗口界面而不喜歡字符界面的用戶,該工具相對SQL/PLUS受到了很大的歡迎。但從Oracle 8i以後,如果安裝Oracle 8i時選取的是別於英語的字符集,對於我們中國,通常會選取簡體中文字符集(ZHS16GBK),安裝成功後,運行SQL Plus WorkSheet程序,會出現所有的中文顯示以及查詢結果均為亂碼的情況。
二、問題分析
最初出現該問題,首先懷疑就是安裝時字符集設置有問題,也就是說沒有設置正確的簡體中文字符集。首先檢查數據庫字符集,在SQL/PLUS中,運行下面的SQL語句,檢查所連接數據庫的字符集:
- SQL> select userenv('language') from dual;
- USERENV('LANGUAGE')
- SIMPLIFIED CHINESE_CHINA.ZHS16GBK
查詢結果發現數據庫安裝時所選字符集為簡體中文ZHS16GBK,說明安裝時字符集設置完全正確。第二步開始懷疑是用戶客戶端字符集問題,檢查客戶端注冊表,打開注冊表編輯程序(RegEdit),在HKEY_LOCAL_MacHINE/SOFTWARE/ORACLE/NLS_LANG,發現Oracle客戶端字符集為AMERICAN_AMERICA.ZHS16GBK,設置也完全正確,可以排除是客戶端字符集設置錯誤的問題。
同時還有一個現象就是在同一個客戶端機器上SQL/PLUS中的查詢字符集顯示完全正常,這也說明不是字符集設置問題,而是系統程序SQL/Plus Worksheet的問題。
在Oracle 8i以前的版本中,從來沒有出現過這樣的情況,這應該和Oracle版本有關,我們知道Oracle 8i和它前面的版本一個顯著的區別就是大部分的Oracle系統程序,現在均采用Java驅動,其實這也就是產生Oracle 8i字符集亂碼問題的根本所在。
非Java驅動的程序,如SQL*Plus,有一個系統參數NLS_LANG,該參數在UNIX系統中設置在環境變量中,在Windows操作系統中設置在注冊表中,這個參數決定了客戶端應用程序的字符集。而對於基於Java應用的程序,如現在遇到的SQL*PLus Worksheet,NLS_LANG參數對這類程序是不起任何作用的。
三、解決方案
找到了問題產生的原因後,下面來討論如何解決該問題。對於Oracle Enterprise Manager中的所有工具,有一個配置文件名為dbaPPScfg.propertIEs,修改該文件即可解決上述問題。這個文件的位置在$Oracle_HOME\sysman\config目錄下,用任何的文本編輯器打開該文件,在這個文件裡面,找到這樣一項,
- # SQLPLUS_NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
去掉注釋符#,同時將其修改為SQLPLUS_NLS_LANG=AMERICAN_AMERICA.ZHS16GBK。
對於Windows操作系統,還需要修改一項,在文件中找到# SQLPLUS_SYSTEMROOT=c:\\WINNT40,去掉注釋符,將其修改為你所在機器的操作系統主目錄。如操作系統的主目錄在D盤的Winnt下,則將其修改為 SQLPLUS_SYSTEMROOT=d:\\WINNT。
對於後面一項的修改只對Windows操作系統進行,對UNIX操作系統則不需要。如果在Windows操作系統中不修改該項,在Oracle Enterprise Manager中,連接系統時,會提示如下的錯誤:
ORA-12560 TNS:protocol adapter error
或者
- ORA-12545 Connect failed because target host or object does not exist
修改完成後,保存文件,退出編輯。重新連接SQL PLUS Worksheet,Oracle 8i字符集亂碼問題得到解決,顯示正確的簡體中文字符集。