我遇到了严重的字符编码问题。给出一些背景知识：
AMERICAN，WE8ISO8859P1和Unix NLS_LANG至AMERICAN_AMERICA.WE8ISO8859P1。在业务结束时：ÖZER İNŞAAT TAAHHÜT VE
最后：ÖZER ÝNÞAAT TAAHHÜT VE
如果您注意到土耳其字符İ和Ş正在转换为ISO 8859-1字符集。但是，所有设置（db和unix中的NLS参数）在两端都是相同的 - ISO8859-1（西欧）
通过一些研究，我可以理解 - 土耳其机器可以通过实时转换显示土耳其数据（DB NLS设置被本地NLS设置覆盖）。
现在，我有一个在我的数据库中运行的接口 - 有一些PL / SQL脚本（通过shell脚本运行）从数据库中提取一些数据并将它们假脱机到unix路径上的.csv文件。然后通过MFT（托管文件传输）将.csv文件传输到外部系统。
问题是 - Exract永远不会有任何土耳其人的性格。每个土耳其人的角色都被转换成西欧人物角色，并且像这样对待外部系统，这被视为数据转换/丢失的情况，我的生意真的很不开心。
有谁能告诉我 - 我怎么能保留所有土耳其人物？
P.S。 ：外部系统的字符集可以设置为ISP8859-9 charcterset。
非常感谢提前。
答案 0 :(得分：5)
如果您说您的数据库字符集是ISO-8859-1，即
SELECT parameter, value
FROM v$nls_parameters
WHERE parameter = 'NLS_CHARACTERSET'
返回value WE8ISO8859P1，您要将数据存储在CHAR，VARCHAR或VARCHAR2列中，问题是数据库字符set不支持完整的土耳其语字符集。如果某个字符不在ISO-8859-1 codepage layout中，则无法将其正确存储在由数据库字符集管理的数据库列中。如果要将土耳其数据存储在ISO-8859-1数据库中，则可以使用workaround characters代替（即用S代替Ş）。但是，如果要支持所有土耳其字符，则需要移动到支持所有这些字符的字符集 - ISO-8859-9或UTF-8相对常见。
但是，更改现有数据库的字符集是一件非常重要的事情。 “全球化支持指南”中有一章介绍了您使用的涵盖character set migration的任何Oracle版本。如果要移动到Unicode字符集（这通常是首选方法而不是坚持使用其中一个单字节ISO字符集），您可以利用Oracle Database Migration Assistant for Unicode。
此时，您通常会看到异议，即至少某些应用程序正在“正确”查看数据，因此数据库必须支持土耳其语字符。问题在于，如果你set up your NLS_LANG incorrectly，可以完全绕过字符集转换，这意味着一个字符在客户端上具有的任何二进制表示都会被持久化而不需要修改数据库。只要每个读取数据的进程都以相同和错误的方式配置其NLS_LANG，事情就会起作用。但是，您很快就会发现某些其他应用程序无法正确配置其NLS_LANG。例如，Java应用程序总是希望在内部将数据库中的数据转换为Unicode字符串。因此，如果您将数据错误地存储在数据库中，就像听起来一样，那么就无法让这些应用程序正确读取它们。如果您只是在shell脚本中使用SQL * Plus来生成文件，那么几乎可以肯定的是，您的客户端配置不正确，因此数据文件看起来是正确的。但是让现有的错误配置持续存在是一个非常糟糕的主意。你将来打开很多更大的问题（如果你还没有），不同的客户将不同的字符集中的数据插入到数据库中，这使得当你找到它时更难解开Oracle导出实用程序等工具损坏了导出的数据，或者您希望使用无法正确配置的工具来查看数据。你可以更早地纠正这个问题。
答案 1 :(得分：0)
只需将NLS_LANG参数设置为AMERICAN_AMERICA.WE8ISO8859P9就可以使用土耳其语。