訪問Oracle數據庫的Java/C＃程序，字符串中的字符串錯誤

我在Oracle中有以下字符串（十六進制轉儲正好在它下面）。正如你所看到的，在第一個「N」之後，有一個僞造的字符「0xA6」。我的Oracle實例使用AL32UTF8作爲字符編碼。訪問Oracle數據庫的Java/C＃程序，字符串中的字符串錯誤

FLOREN�PALACE HOTEL LTDA 
Typ=1 Len=26: 46,4c,4f,52,45,4e,a6,41,20,50,41,4c,41,43,45,20,48,4f,54,45,4c,20,4c,54,44,41

我有兩個服務應該處理這個字符串 - 一個在C＃中，另一個在Java中。我在C＃中處理這個字符串，它說長度是27.然後我嘗試在Java中處理這個字符串，它說長度是25.當我使用C＃打印時，它會打印（注意A和空格之前PALACE）

FLOREN�A PALACE HOTEL LTDA

而在Java中它打印與Oracle相同。

當我在Java程序中從Oracle中選擇字符串時，它就像是「吃」了0xA6及其後面的兩個字符並將其計爲一個字符。我認爲Java認爲它是一個UTF-8字符（這是字符集），所以它在「0xA6」之後消耗「A」和「」。

在將「A」和「」與「0xA6」進行分組時，是否有一種方法可以使Java不那麼激進？

讚賞任何建議，

編輯0

我看着那個獲取Oracle的串碼。我正在使用Oracle JDBC驅動程序。

Class.forName("oracle.jdbc.OracleDriver"); 
m_connection = DriverManager.getConnection(m_connectionString, m_username, m_password);

我的連接字符串是

jdbc:oracle:thin:@//192.168.0.18:1521/serviceName

對於真正從數據庫中獲取的字符串，我用的ResultSet的getBytes，的getString，getBinaryStream，getUnicodeStream方法調用。查看byte []，char []或字符串中的字節時，例如在使用getBytes時，會在0xA6，「A」和「」位置（0xEF，0xBF，0xBD）中顯示奇怪的字節。

/編輯0

來源

2013-02-22 mj_

你最近在做十六進制轉儲嗎？從一個從數據庫讀取的程序，或者從數據庫命令提示符本身？ – 2013-02-22 18:27:09

我正在使用SQLDeveloper並運行以下SQL：從my_table中選擇foo，dump（foo，16） – 2013-02-22 18:28:25

如何檢索/處理字符串，特別是在Java中;可能有助於將代碼從數據庫中拉出來，直到獲取長度/打印它。而且，也許是你的語言環境。一些可重複的代碼會很好，如果這是可行的。你可以在StringBuffer中通過char來檢查它是char還是從數據庫檢索它作爲一個字節數組？或許有助於隔離JDBC是否令人困惑，或者之後的事情。數據庫中是「VARCHAR2」還是「NVARCHAR2」？（對不起，很多問題，只是傾銷的想法...！） – 2013-02-22 19:20:12

看起來像數據損壞。原始數據可能在ISO-8859中編碼，而不是轉換爲UTF-8。

0xA6本身在ISO-8859-1是「斷豎線」 ¦性格，這沒有任何意義，

但，

在ISO-8859-2它相當於Unicode 0x015A（帶有急性的拉丁大寫字母S），或者看起來很可能是＆＃x015A。它使整個字符串FLOREN＆＃x015a; A PALACE HOTEL LTDA

的解決辦法是更換該字符用正確的UTF-8編碼，這將是0xc5 0x9a

來源

2013-02-22 19:21:34

我同意這是腐敗。問題是，我需要Java程序中的字符串與C＃程序中的字符串完全一樣。我在兩個程序中存儲和分享字符索引，這種錯位並沒有幫助。 – 2013-02-22 19:31:20

你有一個非UTF8數據存儲在一個數據庫中，告訴客戶端代碼是_is_ UTF8。這將導致未定義的行爲取決於客戶端如何實現。如果任何驅動程序供應商對UTF8的無效處理方式進行更改，則無法編寫代碼以保證現在可以正常工作，或者將來的任何時候。唯一真正的解決方案是修復數據編碼問題。 – 2013-02-22 19:35:06

它傳遞給之前轉換您的字符串convert(your_string, 'AL32UTF8', 'WE8ISO8859P2') Java的。

來源

2013-02-22 19:59:23

使用WE8ISO8859P2時，出現「不支持的字符集」錯誤。我試過WE8ISO8859P1和WE8ISO8859P15，這兩種都給了我一些東西。 – 2013-02-22 20:45:34

爲了後代的緣故，在嘗試實施上述建議之一時，我發現OJDBC驅動程序是罪魁禍首，正在改變對我的編碼。爲了保留編碼，我可以刪除不好的字符，我使用了下面的SQL。

從tab中選擇utl_raw.cast_to_raw（col）

然後我遍歷字節並壓扁僞造字符。

來源

2013-02-25 20:01:16

訪問Oracle數據庫的Java/C＃程序，字符串中的字符串錯誤

回答

相關問題