我有一个访问的数据从一个Oracle10分贝支持商业应用程序一个C＃.net应用程序。商业应用程序的数据库中的几个字段（声明为VARCHAR2（n））的包含特殊字符。 智能引号撇号，例如。商业客户端应用程序能够正确显示这些字符，但我的应用程序是显示他们作为一个倒置的问号。 Oracle的字符集是WE8ISO8859P1。

我的应用程序读取商业数据库使用System.Data.OracleClient.OracleDataAdapter，通过DataSet.Tables转换成表格。该tablerows被转换为对象，有问题的字段作为字符串存储。

如果我检查（在调试器）从数据库中读取后立即在DataSet中的数据，以及特殊字符已经显示不正确。我无法弄清楚如何检查数据为十六进制字节来看看什么是真正存在，我也不是一定就是我要寻找的。

我也注意到，蟾蜍显示的字符作为倒问号也是如此。

我们的申请的一个方面写入这些记录到在我们自己的数据库中的单独的表;时发生的特殊字符被修改，随后显示为框而不是颠倒的问号。

如果需要，我可以提供进一步的信息。感谢您的任何和所有帮助！

后记任何人正在浏览该主题：

波格丹是让我的答案（如它是）非常有帮助的，但他指出，你可能不会有相同的情况。

我们沟通与负责使用商业软件的团队。他们已经复制/粘贴从Word和Excel，这是怎样的特殊字符已经得到插入。

发生在远程数据库和我们的数据库的字符翻译的问题。主机数据库使用的字符集WE8ISO8859P1，这里我们使用WE8MSWIN1252。由于公司层面的关注，无论是修改字符集是不可行的现在。

我用SYS.UTL_RAW.CAST_TO_RAW（字段名）到源字段转换搜索BF（十六进制code在我们的字符集的倒问号）。这至少让我找出问题的记录和性格。然而，在远程记录许多不同的特殊字符会/可以转换为BF。例如，Word的连字符并不是简单的划线字，并同时获得翻译成倒问号。

转储（字段名）以某种方式转换为十进制字符codeS前的翻译，除非我也用SYS.UTL_RAW.CAST_TO_RAW在同一查询。这引起了惊人的头痛。转储（）本身可能是在确定具体pretranslated字符从源数据库是有用的。

最好的解决办法是使用相同的字符在两个DBS设置。因为这是不可能的是，我们已经手动替换源（远程）DB与非特殊当量（普通撇号或连字符）的特殊字符的所有实例。然而，由于商业软件不正确或旗特殊字符，我们可能会遇到在将来这个问题。因此，我们的更新应用程序将扫描的倒问号和发送通知给系统所有者有不良记录的ID。这一点，像许多其他公司的情况下，将不得不这样做。 ; - ）

再次感谢，波格丹！

I have a C#.Net application that accesses data from a commercial application backed by an Oracle 10 db. A couple of fields in the commercial app's database (declared as varchar2(n)) contain special characters. The "smart quote" apostrophe, for example. The commercial client app displays these characters correctly, but my application is displaying them as an inverted question mark. The Oracle character set is "WE8ISO8859P1".

My application reads the commercial database using System.Data.OracleClient.OracleDataAdapter, converted into a table via DataSet.Tables. The tablerows are converted into objects, and the fields in question are stored as strings.

If I examine (in the debugger) the data in the DataSet immediately after reading it from the db, and the special characters are already displayed incorrectly. I can't figure out how to examine the data as hex bytes to see what's really there, nor am I certain what I should be looking for.

I have also noted that Toad displays the characters as inverted question marks as well.

One aspect of our application writes these records to a separate table in our own database; when that occurs the special characters get modified, and subsequently display as boxes instead of upside-down question marks.

I can provide further information if needed. Thank you for any and all help!

Postscript for anyone browsing this thread:

Bogdan was very helpful in getting me to the "answer" (such as it is) but as he points out, you might not have identical circumstances.

We communicated with the team responsible for using the commercial software. They had been copying/pasting from Word and Excel, which is how the special characters had been getting inserted.

The problem occurred in the translation of the character between the remote database and our database. Host database uses character set WE8ISO8859P1, where ours uses WE8MSWIN1252. Due to corporate-level concerns, modifying either character set is not feasible right now.

I used SYS.UTL_RAW.CAST_TO_RAW(fieldname) to convert the source field to search for 'BF' (the hex code for an inverted question mark in our character set). This at least let me identify the problem record and character. HOWEVER, many different special characters on the remote records would/could be translated to BF. For example, Word's hyphens are not simple "dash" characters, and also get translated to the inverted question mark.

dump(fieldname) somehow converts to decimal character codes BEFORE the translation, UNLESS I also used the SYS.UTL_RAW.CAST_TO_RAW in the same query. This caused amazing headaches. dump() by itself could be useful in identifying specific pretranslated characters from the source db.

Best solution would be to use the same character set on both dbs. Since that's not possible for us, we have manually replaced all occurrences of the special character on the source (remote) db with non-special equivalents (regular apostrophe or hyphen). However, since the commercial software doesn't correct or flag special characters, we may run into this problem in the future. So, our update application will scan for the inverted question mark and send a notification to the system owner with the ID of the bad record. This, like so many other corporate situations, will have to do. ;-)

Thanks again, Bogdan!