由於曆史的原因,早期的oracle沒有中文字元集(如oracle6、oracle7、oracle7.1),但有的使用者從那時起就使用資料庫了, 並用US7ASCII字元集儲存了中文,或是有的使用者在建立資料庫時,不考慮清楚,隨意選擇一個預設的字元集,如WE8ISO8859P1或US7ASCII,而這兩個字元集都沒有漢字編碼,雖然有些時候選用這種字元集好象也能正常使用,但用這種字元集儲存漢字資訊從原則上說就是錯誤的,它會給資料庫的使用與維護帶來一系列的麻煩。正常情況下,要將漢字存入資料庫,資料庫字元集必須支援中文,而將資料庫字元集設定為US7ASCII等單一位元組字元集是不合適的。US7ASCII字元集只定義了128個符號,並不支援漢字。另外,如果在SQL*PLUS中能夠輸入中文,作業系統預設應該是支援中文的,但如果在NLS_LANG中的字元集設定為US7ASCII,顯然也是不正確的,它沒有反映用戶端的實際情況。但在實際應用中漢字顯示卻是正確的,這主要是因為Oracle檢查資料庫與用戶端的字元集設定是同樣的,那麼資料在客戶與資料庫之間的存取過程中將不發生任何轉換,但是這實際上導致了資料庫標識的字元集與實際存入的內容是不相符的。而在SELECT的過程中,Oracle同樣檢查探索資料庫與用戶端的字元集設定是相同的,所以它也將存入的內容原封不動地傳送到用戶端,而用戶端作業系統識別出這是漢字編碼所以能夠正確顯示。
在這個例子中,資料庫與用戶端都沒有設定成中文字元集,但卻能正常顯示中文,從應用的角度看好象沒問題。然而這裡面卻存在著極大的隱患,比如在應用length或substr等字串函數時,就可能得到意外的結果。
對於早期使用US7ASCII字元集資料庫的資料移轉到oracle8i/9i中(使用zhs16gbk),由於未經處理資料已經按照US7ASCII格式儲存,對於這種情況,可以通過使用Oracle8i的匯出工具,設定匯出字元集為US7ASCII,匯出後使用UltraEdit等工具開啟dmp檔案,修改第二、三字元,修改 0001 為0354,這樣就可以將US7ASCII字元集的資料正確匯入到ZHS16GBK的資料庫中。
總結一下在 .Net 中讀寫Oracle資料庫常用兩種方式:OracleClient和OleDb,其中OleDb的方式根據驅動程式的不同又有兩種。
1. OracleClient方式,是微軟專門針對Oracle資料庫開發的,僅在 .NET Framework 1.1 版中受支援。據說速度快、效能好,是推薦使用的方式。但根據我的經驗,當Oracle資料庫伺服器端採用英文字元集比如 US7ASCII 時,用戶端不管字元集如何設定,讀出的中文都是亂碼;若伺服器端用中文字元集比如 ZHS16GBK ,則無亂碼問題。
引用類庫:System.Data.OracleClient.dll。
命名空間:System.Data.OracleClient。
常用類:OracleConnection、OracleCommand、OracleDataAdapter、OracleTransaction、OracleDataReader等。
典型連接字串:“data source=oratest;user id=scott;password=tiger”(注意:可不指定 provider 驅動)。
2. OleDb方式,微軟和Oracle公司各自提供了OleDb的驅動程式,使用方法的差別很少。不管Oracle伺服器端用何字元集,讀寫中文均無亂碼問題。
相同之處
命名空間:System.Data.OleDb。
常用類:OleDbConnection、OleDbCommand、OleDbDataAdapter、OleDbTransaction、OleDbDataReader等。
不同之處
引用類庫:微軟的只需要System.Data.dll;若用Oracle的驅動,雖然也只要引入System.Data.dll,但前提是首先安裝Oracle針對.Net的資料訪問組件。 連接字串:與OracleClient方式相比,要添加一個provider,微軟為“provider=MSDAORA.1;”,Oracle為“provider='OraOleDb.Oracle';”。使用provider='OraOleDb.Oracle'能夠使用Oracle儲存圖片等大對象,provider=MSDAORA.1則不行。 set conn=server.createobject("adodb.connection")
dns="Provider=OraOLEDB.Oracle.1;Persist Security Info=True;User ID=user1;Password=pass1;Data Source=oradb"