问题描述：

我有一个在 Oracle 数据库（Windows 或 Unix 操作系统）上运行的脚本。它提取数据，然后将其假脱机到 .txt 文件。

为了确保文件不变，在运行脚本时对数据进行哈希处理，然后在 Web 应用程序中重新计算该哈希值。这可以工作 9/10 次，但有时它会提供不匹配，即使文件是相同的，我将其隔离为编码问题。

为了确定文件使用的编码，该脚本将 3 个非 ASCII 字符写入文件，这些字符在不同的编码方案中编码不同。这些稍后会映射到后端。

--Encoding related information\nSPOOL &&file_desc/Encoding.txt\nSELECT ('\xe2\x82\xac'||';'||'\xc6\x92'||';'||'\xe2\x80\xb0') FROM sys.dual;\nSPOOL off\n

预期结果

在使用 UTF-8 编码的数据库上，应正确假脱机包含 NONASCII 字符的数据，并且 3 个 NONASCII 字符也应正确假脱机。

实际结果

当使用 .AL32UTF8 系统字符集（与 DB 相同）时，数据会正确假脱机，但用于编码的 3 个字符则不然。这使得我无法确定使用了哪种编码方案。

数据库具有以下字符集（从database_properties获得）：

NLS_CHARACTESET：AL32UTF8

NLS_NCHAR_CHARACTERSET：AL16UTF16

SQL-Developer 工作

使用 SQL-Developer 时（将编码设置为 UTF8 后）），我没有任何问题。日语和希腊字符都正确显示，并且用于编码的字符也正确显示，从而在稍后重新计算时导致成功的哈希匹配。

SQL*Plus 无法\xe2\x80\x99 工作

我也需要它在 SQL*Plus 中工作，但我\xe2\x80\x99 遇到了问题。我\xe2\x80\x99已经尝试了一系列不同的变体。DB是Oracle 18c Express版本：