oracle資料庫字符集為AMERICAN_AMERICA.us7ascii，delphi7讀取中文出來亂碼，如何解決，客戶的資料庫字符集不能更改，只能通過delphi轉碼，急急
uj5u.com熱心網友回復：
首先要確定是資料庫字符集為AMERICAN_AMERICA.us7ascii還是客戶端NLS_LANG設定為AMERICAN_AMERICA.us7ascii，如果是后者，這個設定只決定顯示，不影響資料庫中的實際存盤，可以改，不改也可以用rawtohex函式獲取原始編碼的資料：select rawtohex(xxx) from ...。如果是前者（用sqlplus客戶端工具連接資料庫，輸入select * from nls_database_parameters;看看輸出），那就比較麻煩了，US7ASCII是7位ASCII編碼，最高位是0，所以中文存進去的時候就資訊丟失了，讀出來也不可能正確。只能寫入之前先編碼，比如BASE64，讀出來之后再解碼。
uj5u.com熱心網友回復：
您好，非常感謝2樓的回復，服務器資料庫字符集就是AMERICAN_AMERICA.us7ascii，這個是確定的，我在客戶端的機器里設定環境變數NLS_LANG為SIMPLIFIED CHINESE_CHINA.US7ASCII后，通過PLSQL查詢是可以顯示中文了，但通過delphi不知道如何轉換，中文讀取出來都是亂碼uj5u.com熱心網友回復：
那你把NLS_LANG為SIMPLIFIED CHINESE_CHINA.UTF8，D7讀出來UTF8Decode再顯示。uj5u.com熱心網友回復：
好的，我試試看uj5u.com熱心網友回復：
edit2.text:=Utf8Decode(YlQuery_Data['payer']); 還是亂碼，我用的資料連接組件是unidac ,我這里設定 UniConnOracle.SpecificOptions.Values['Charset'] := 'SIMPLIFIED CHINESE_CHINA.UTF8'; 還是不行，uj5u.com熱心網友回復：
那應該就是資料寫入資料庫時就丟失資訊了，你只能先用兼容US7ASCII的編碼比如BASE64先編碼再寫入，讀取后先解碼再顯示。uj5u.com熱心網友回復：
但是通過plsql連接，直接查詢是可以顯示中文的，問了他們開發商說他們顯示也是沒問題，我們只能讀取他們的資料uj5u.com熱心網友回復：
那你別用D7了，換D2009+支持unicode的版本。uj5u.com熱心網友回復：
喔喔，我看看，不管怎樣，非常感謝您uj5u.com熱心網友回復：
這樣啊，那你可以用rawtohex函式獲取資料編碼看看，和已知資料比較一下。
uj5u.com熱心網友回復：
當資料庫是英文字符集時，他的原始編碼如果不是GBK，是很容易亂碼的，這時就如樓上所說，dump一下中文欄位，看看其原始編碼到底是什么 ，如果不是已知的編碼，那極有可能是存盤時發生了轉換，這時，只有你把環境設定為資料來源一致時，才能解決。這種情況是編碼丟失，但內容還能還原，即使是GBK編碼，DUMP出來也不是GBK。覺的沒幾種，一試便知uj5u.com熱心網友回復：
用PL改幾下NSL_LANG就能試出來uj5u.com熱心網友回復：
這是系統字符集的問題。根本的解決辦法，使用Delphi2010。
uj5u.com熱心網友回復：
我倒是覺得UniConnOracle.SpecificOptions.Values['Charset']應該設定成ASCII才對uj5u.com熱心網友回復：
換版本的醉了轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/44325.html
標籤：數據庫相關
上一篇：高分懸賞FTP問題