sql - 在 sql 中将西欧字符集转换为土耳其语

Question

我遇到了一个严重的字符编码问题。给出一些背景:

1. 我有土耳其语业务用户，他们使用土耳其语在 Unix 屏幕上输入一些数据。
2. 我的数据库 NLS 参数设置为 AMERICAN，WE8ISO8859P1，Unix NLS_LANG 设置为 AMERICAN_AMERICA.WE8ISO8859P1。
3. 土耳其企业能够在 UNIX 屏幕和 TOAD 上看到所有土耳其语字符，而我却不能。我只能在西欧字符集中看到它们。

在业务端:ÖZER İNŞAAT TAAHHÜT VE
在我们这边:ÖZER ÝNÞAAT TAAHHÜT VE

如果您注意到土耳其字符 İ 和 Ş 正在转换为 ISO 8859-1 字符集。但是，两端的所有设置(db 和 unix 中的 NLS 参数)都是相同的 - ISO8859-1(西欧)

通过一些研究，我可以理解 - 土耳其机器可以通过实时转换来显示土耳其语数据(本地 NLS 设置会覆盖 DB NLS 设置)。

现在，我有一个在我的数据库中运行的接口(interface) - 有一些 PL/SQL 脚本(通过 shell 脚本运行)从数据库中提取一些数据并将它们假脱机到 unix 路径上的 .csv 文件。然后该 .csv 文件通过 MFT(托管文件传输)传输到外部系统。

问题是- Exract 从来不包含任何土耳其字符。每个土耳其字符都被转换成西欧字符集，并像这样进入外部系统，这被视为数据转换/丢失的情况，我的业务真的很不开心。

谁能告诉我 - 我怎样才能保留所有土耳其语字符？

附言: 外部系统的字符集可以设置为ISP8859-9字符集。

非常感谢。

Answer 1

如果你说你的数据库字符集是 ISO-8859-1，即

SELECT parameter, value
  FROM v$nls_parameters
 WHERE parameter = 'NLS_CHARACTERSET'

返回 WE8ISO8859P1 的 value 并且您将数据存储在 CHAR、VARCHAR 或 中>VARCHAR2 列，问题是数据库字符集不支持完整的土耳其语字符集。如果字符不在 ISO-8859-1 codepage layout 中，它不能正确存储在由数据库字符集控制的数据库列中。如果您想将土耳其语数据存储在 ISO-8859-1 数据库中，您可能会使用 workaround characters相反(即用 S 代替 Ş)。但是，如果您想要支持所有土耳其语字符，则需要转向支持所有这些字符的字符集——ISO-8859-9 或 UTF-8 都比较常见。

然而，更改现有数据库的字符集并非易事。无论您使用何种版本的 Oracle，全局化支持指南中都有一章涵盖 character set migration .如果你想移动到 Unicode 字符集(这通常是首选方法，而不是坚持使用单字节 ISO 字符集之一)，你可以潜在地利用 Oracle Database Migration Assistant for Unicode .

在这一点上，您通常会看到反对意见，即至少某些应用程序“正确”地看到了数据，因此数据库必须支持土耳其语字符。问题是如果你 set up your NLS_LANG incorrectly , 完全绕过字符集转换是可能的，这意味着一个字符在客户端上的任何二进制表示都可以在不修改数据库的情况下持久化。只要读取数据的每个进程都以相同且错误的方式配置它们的 NLS_LANG，事情就可能看起来正常。但是，您很快就会发现其他一些应用程序无法完全正确地配置它们的 NLS_LANG。例如，Java 应用程序总是希望在内部将数据库中的数据转换为 Unicode 字符串。因此，如果您将数据错误地存储在数据库中(听起来确实如此)，则无法让这些应用程序正确读取它。如果您只是在 shell 脚本中使用 SQL*Plus 来生成文件，那么几乎可以肯定的是，您的客户端配置不正确，以至于数据文件看起来是正确的。但是让现有的错误配置持续存在将是一个非常糟糕的主意。当您发现不同的客户端将不同字符集的数据插入数据库时​​，您会在未来面临更多更大的问题(如果您还没有遇到) Oracle 导出实用程序等工具损坏了导出的数据，或者当您想使用无法正确配置的工具来查看数据时。尽早纠正问题会更好。