Question

我正在使用dblink到8i数据库从10g数据库查询。

select col1, col2 ... from table@my_dblink_to_8i

8i charset是IW8ISO8859P8

10g字符集是WE8MSWIN1252

这些数据显得非常简陋。我已经尝试过所有我能想到的变化

to_char(col1)
cast(col1 as nchar(4))
cast(col1 as nvarchar2(4))
cast(col1 as char(4))
cast(col1 as varchar2(4))
convert(col1, 'WE8MSWIN1252', 'IW8ISO8859P8')
convert(convert(col1,'UTF8','IW8ISO8859P8'),'WE8MSWIN1252','UTF8')

全部以gibrish或

返回

ORA-12704: character set mismatch
ORA-02063: preceding line from OTHERDB

有什么建议吗？

我可以转换为中间字符集吗？

Answer 1

是的，这是一个有时会发生的已知问题。我记得第一次使用两个相同的Oracle 7版本之间的数据库链接来体验它，然后在使用Oracle 8.1.5时再次看到它。

它无法永远解决。对于非美国字符，Oracle开发似乎没有像美国字符一样密集测试。

您可以尝试的第一件事是检查正在使用的Oracle 8i的EXACT版本。检查服务器版本是否为8.1.7或更高版本（例如8.1.7.4）。 8.1.5存在已知问题，我想回忆一下这是第一个做AL32UTF8的版本。

同时检查SQL * Net客户端安装的版本（如果您使用单独的安装，我不这么认为）。它必须是8.1.7或更新。

同时检查字符在两个字符集中是否可用。它们大致相同，但并非完全相同。我认为8859P8是一个没有Europ支持的国际，而MSWIN1252则是微软的支持。

检查其间所有节点上的NLS_LANG，并正确配置数据库字符集。确保它们是正确的。您可以将临时节点更改为AL32UTF8。 SQL * net不进行字符转换，但是当客户端和服务器说出相同的字符集时也没有检查，因此字符集设置中的错误可能会沉睡多年。

经过测试后，您可能想尝试转换为AL32UTF而不是UTF8（我认为它已经可以使用8，不知道确定，但可能只支持9i的主流）。

作为最后的手段，请自行进行角色转换。使用过程将二进制文件传输给调用者，并在接收10g数据库上进行转换。

或使用像Kettle这样的ETL工具，将文本文件作为临时或类似文件归档。

我希望这能回答你的问题。如果没有，请帮助我一些乱码的样本（传输us7ascii文本，更高级的文本，以及跨dblink调用的varchar2参数的结果）。如果是，请告诉我。你有一个有趣的问题！

从db链接查询时Charset不匹配

1 个答案: