Java/C程序访问Oracle数据库，字符串中的字符不正确

我在Oracle中有以下字符串，十六进制转储就在它下面。如您所见，在第一个N之后，有一个伪字符0xA6。我的Oracle实例使用AL32UTF8作为字符编码

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和宫殿前的空格

FLOREN�A PALACE HOTEL LTDA

而在Java中，它的打印方式与Oracle相同

当我在Java程序中从Oracle中选择字符串时，就像Java正在吃0xA6和后面的两个字符，并将其作为一个字符计算。我假设Java认为它是一个UTF-8字符，是字符集，因此它使用a和0xA6之后的字符

在将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调用。例如，当我使用getBytes时，查看byte[]、char[]或string中的字节会显示0xA6、a和位置0xEF、0xBF、0xBD中的奇怪字节

---

/编辑0看起来像是数据损坏。原始数据可能是用ISO-8859编码的，而不是转换成UTF-8

在ISO-8859-1中，0xA6本身就是断开的竖线字符，这没有意义

但是,

在ISO-8859-2中，它相当于Unicode 0x015A拉丁文大写字母S，带有锐音符或Ś，看起来很可能。这使得整个弗洛伦皇宫酒店成为LTDA皇宫酒店

---

解决方案是用正确的UTF-8编码替换该字符，即0xc5 0x9a

在将字符串传递给Java之前，将字符串转换为您的_字符串“AL32UTF8”、“WE8ISO8859P2”。

为了子孙后代，在尝试实现上述建议之一的同时，我发现OJDBC驱动程序是罪魁祸首，因为它正在改变我的编码。为了保留编码以便删除坏字符，我使用了以下SQL

从选项卡中选择utl_raw.cast_to_raw col

---

然后，我遍历字节并压扁伪字符

你是怎么做的十六进制转储在顶部？从一个从数据库读取的程序，或者从数据库命令提示符本身读取？我正在使用SQLDeveloper并运行以下SQL：从my_Table中选择foo，dumpfoo，16如何检索/处理字符串，特别是在Java中；显示从数据库中提取代码到获取长度/打印代码的过程可能会有所帮助。还有，也许是你所在的地区。如果可行的话，一些可复制的代码会很好。您可以在StringBuffer中逐个字符地检查它，或者从数据库中以字节数组的形式检索它吗？如果JDBC被搞糊涂了，或者后来发生了什么事情，也许可以帮助隔离。数据库中是VARCHAR2还是NVARCHAR2？抱歉问了这么多问题，只是抛开想法。。。！我同意这是腐败。问题是，我需要Java程序中的字符串看起来与C程序中的字符串完全相同。我在两个程序之间存储和共享字符索引，这种不一致没有帮助。数据库中存储了非UTF8数据，告诉客户端代码它是UTF8。这将导致未定义的行为，具体取决于客户端的实现方式。如果驱动程序供应商对无效UTF8的处理方式进行了更改，则您无法编写保证现在或将来任何时候都能工作的代码。唯一真正的解决方案是修复数据编码问题。当使用WE8ISO8859P2时，我得到一个不支持的错误字符集。我试过WE8ISO8859P1和WE8ISO8859P15，它们都给了我一些东西。