我在oracle 10g中遇到了一个奇怪的UTF8问题。 db charset是US7ASCII，我不知道供应商系统如何进行插入（他们不会分享他们的代码） - 我只是想为报告提取数据
我可以通过返回带有rawtohex(column)的字段来提取它们，然后使用单独的程序将十六进制转换为java / c＃中的unicode。
这可以通过更改注册表在任何应用程序中与驱动程序一起使用，但现在我尝试在SQL * Plus的查询中执行此操作，并且我得到了各种错误的结果。
AMERICAN_AMERICA.US7ASCII
Keratry, Émile
AMERICAN_AMERICA.AL32UTF8
Keratry, E��mile
AMERICAN_AMERICA.US8PC437
Keratry, E■■mile
Correct
Keratry, Émile
转储：
Typ=1 Len=39: 75,101,114,97,116,114,121,44,32,69,204,129,109,105,108,101,44,32,9
9,111,109,116,101,32,100,101,44,32,49,56,51,50,45,49,57,48,52,46,32
必须正确地返回变音符号，但我很难过。有人有什么想法吗？
答案 0 :(得分：0)
情况如下：
您有一个US7ASCII数据库，其中存储带重音拉丁字母的UTF-8代码。应用程序通过将NLS_LANG设置为.US7ASCII或根本没有设置的OCI传递这些代码来存储此数据。从Oracle NLS的角度来看，这是一个糟糕的应用程序，但这不是这里的问题。
一个有趣的方面是，您显示的示例数据以Unicode非规范化格式存储，其中重音字母É（大写）存储为大写U+0045 LATIN CAPITAL LETTER E（例如，普通ASCII {{1 }}），后跟Unicode字符E。此格式是正确的Unicode，但比通常的组合格式（其中U+301 COMBINING ACUTE ACCENT作为其自己的组合代码É存储）不常见。某些设备可能无法将两个字符正确显示为一个重音字母。
要获取报告的数据，请使用U+00C9 LATIN CAPITAL LETTER E WITH ACUTE将其从SQL * Plus假脱机到文件中，然后关闭终端输出。命令提示符（US Windows）在OEM代码页437（NLS_LANG=.US7ASCII）中工作，它将无法显示从该线轴获取的UTF-8代码。在为UTF-8配置的Web浏览器中查看假脱机文件时，您应该能够正确看到数据。 Notepad或Notepad ++也应该能够正确显示文件（我已经在Win10上检查了它们）。
请注意，将US8PC437设置为NLS_LANG以外的任何值，将使Oracle尝试从US7ASCII转换为指定的字符集。显然，这将使（错误地）存储的UTF-8代码产生垃圾。