Oracle NLS语言问题

我对Oracle10g中的UTF8有一个奇怪的问题。db字符集是US7ASCII，我不知道供应商系统是如何进行插入的，他们不会共享他们的代码-我只是试图为报表提取数据

我可以通过使用rawtohexcolumn返回字段来提取它们，然后使用单独的程序在java/c中将十六进制转换为unicode

通过更改注册表，任何应用程序中的驱动程序都应该可以这样做，但现在我尝试在查询w/SQL*Plus中执行此操作，并且得到了各种错误的结果

AMERICAN_AMERICA.US7ASCII
Keratry, Émile

AMERICAN_AMERICA.AL32UTF8
Keratry, E��mile

AMERICAN_AMERICA.US8PC437
Keratry, E■■mile

Correct
Keratry, Émile

转储：

---

正确地返回变音符号是可能的，但我被难住了。有人有什么想法吗？

情况如下：

您有一个US7ASCII数据库，存储重音拉丁字母的UTF-8代码。应用程序通过OCI将这些代码传递给NLS_LANG并将其设置为.US7ASCII或根本不设置来存储这些数据。从Oracle NLS的角度来看，这是一个糟糕的应用程序，但这不是问题所在

一个有趣的方面是，您所展示的示例数据以Unicode非规范化形式存储，其中重音字母ÉE acute存储为大写U+0045拉丁大写字母E，例如通常的ASCII E，后面是Unicode字符U+301组合的锐重音。这种形式是正确的Unicode，但它不如通常的组合形式常见，在这种组合形式中，É存储为自己的组合代码U+00C9，拉丁文大写字母E加上锐音符。某些设备可能无法将这两个字符正确显示为一个重音字母

要获取报告的数据，请使用NLS_LANG=.US7ASCII将其从SQL*Plus假脱机到文件，但关闭终端输出。命令提示符US Windows在OEM代码页437 US8PC437中工作，它将无法显示从该假脱机获得的UTF-8代码。在为UTF-8配置的web浏览器中查看假脱机文件时，应该能够正确地查看数据。记事本或记事本++也应该能够正确显示我在Win10上检查过的文件

---

请注意，将NLS_LANG设置为除.US7ASCII以外的任何值都会使Oracle尝试从US7ASCII转换为指定的字符集。这显然会使错误存储的UTF-8代码变成垃圾。

当您说db字符集是AMERICAN.AMERICA.US7ASCII时，您的意思是什么？AMERICAN_AMERICA.US7ASCII是有效的NLS_语言，但这是与数据库字符集无关的客户端设置。数据库字符集将以v$nls_参数形式存在。US7ASCII将是一个有效的数据库字符集，但这意味着数据库不支持128个7位ASCII字符以外的数据。NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15有什么好处？您正在更改注册表，因此您的客户端和sqlplus位于WIndows上。您可以尝试设置环境变量吗？DB是US7ASCII。它当然支持128个7位字符之外的数据，因为原始十六进制在其中。我只设置ENV变量-更改注册表似乎不会影响SQL*PLUS:AMERICAN_AMERICA.WE8ISO8859P15 Keratry，E┐┐米尔：那么，列的数据类型是什么，即国家字符集？是原始列值的转储还是在您尝试转换它之后？varchar2列不支持7位ASCII之外的数据-尽管可以将不支持的值放入其中-但nvarchar2可能会。但您让它听起来像是原始数据，这会很奇怪。varchar2，原始列值的转储。将UTF8放入7位ASCII varchar2列中肯定有一些技巧，因为如果您将其从原始数据转换为十六进制，然后将其转换为unicode，它将正确显示。

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