首先我必须承认，我不是 Oracle 用户专家，所以我在理解基础知识时遇到了一些问题:D。我们的应用程序是一个带有 Nhibernate 数据库连接的 MVC 应用程序。问题在于，当我们尝试将“Ѽó”这样的字符保存到 NVARCHAR2 字段中时，它们会被保存为问号“?”。为了解决这个问题，我们在数据库中更改为不同的字符集。
这是我们安装时的 nls_database_parameters:
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET EE8ISO8859P2
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 10.2.0.4.0
最初的 NLS_CHARSET 是 EE8ISO8859P2，我们将其更改为:AL32UTF8(完美运行)。问题是 NLS_NCHAR_CHARACTERSET 不应该处理 nvarchar2 等字段的特殊字符吗？如果没有那么有人可以向我解释其目的吗？
编辑:NLS_LANG 设置为:POLISH_POLAND.AL32UTF8
最佳答案
国家字符集在早期使用，即在 Unicode 可用之前。主要思想是拥有通用字符集，用于存储 VARCHAR2/CHAR 的与语言无关的项目(包括任何源代码等)，并拥有特定于客户的，即特定于语言的国家字符集 NVARCHAR2/NCHAR。
在我看来，现在没有理由使用它，因为 AL32UTF8(或任何其他 Unicode 编码)无论如何都能够存储任何字符。
也许当您使用非西方语言时，AL16UTF16 或 AL32UTF32 等国家字符集在存储和效率方面稍微有利。
关于您的问题:国家字符集AL16UTF16能够存储任何Unicode字符，因此您的波兰语字符应该没有问题。但是，也许您的客户端应用程序(或所选字体)无法显示此类字符
关于oracle - NLS_NCHAR_CHARACTERSET解释，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26422688/