Question

给出以下代码 Windows上的输出具有完整的8位字节，而在Mac上，字符串已被编码为7位ASCII，其外观类似于“替换”字样。关于编码。

MAC 25 50 44 46 2d 31 2e 33 0a 25 43 69 3f 3f 0a 35 20 30 20 6f 62 6a 0a 3c 3c 2f

WINDOWS 25 50 44 46 2d 31 2e 33 0a 25 c7 ec 8f a2 0a 35 20 30 20 6f 62 6a 0a 3c 3c 2f

我安装了相同版本的sqlalchemy，python，cx-oracle和即时客户端

我尝试过不同的convert_unicode / coerse_unicode类型标志无效

任何帮助将不胜感激

from sqlalchemy import Table, MetaData
from sqlalchemy import create_engine
from sqlalchemy.sql import select


if __name__ == '__main__':

  connection_string = 'oracle+cx_oracle://user:pw@db:1521/orcl'
  engine_args = {
    'echo': False,
    'convert_unicode': True,
    'coerce_to_unicode': True
  }
  src_engine = create_engine(connection_string, **engine_args)
  metadata = MetaData()

  table = Table('POLICY_CONTRACT', metadata, autoload=True, autoload_with=src_engine, schema='TROPICS_POLICY')
  s = select(table.columns)
  q = src_engine.execute(s)
  r = q.fetchone()

  for k in r.keys():
    v = r[k]
    if k == 'contract_content':
      v1 = " ".join(["{0:02x}".format(ord(x)) for x in v])
      print("{0} : {1} : {2}\n".format(k, type(v), v[:100]))

Answer 1

只是猜测，但您的Windows 客户端字符集在Windows设置和Mac设置之间可能会有所不同。当客户端字符集与数据要求不同时，可能会发生一些转换。来自Globalization Support Guide：

正确设置NLS_LANG可以从客户端正确转换   操作系统字符编码到数据库字符集。   当这些设置相同时，Oracle数据库会假定   发送或接收的数据编码为相同的字符集   数据库字符集，所以字符集验证或转换   可能无法执行。如果转换，这可能会导致数据损坏   必要的。

在从一个字符集转换为另一个字符集的过程中，Oracle数据库   期望客户端数据以指定的字符集进行编码   通过NLS_LANG参数。如果您将其他值放入字符串中   （例如，通过使用CHR或CONVERT SQL函数），然后   将值发送到数据库时，可能会损坏这些值，因为   它们没有正确转换。如果您已配置   环境正确，如果数据库字符集支持   整个人物数据库可以输入到   数据库，那么您不需要更改当前数据库   字符集。但是，如果您的企业变得更加全球化，那么   你有其他字符或新语言支持，那么你   可能需要选择具有更大角色保留曲目的字符集

您可以通过选中以下方式检查服务器设置：

select * from v$nls_parameters;

检查NLS_CHARACTERSET

在Windows客户端上，检查注册表是否有NLS_LANG条目（如果设置了env变量，则检查echo％NLS_LANG％）。在Unix / Linux上，尝试echo $ NLS_LANG。不确定Mac，但也许Unix方法也可以。（如果未设置，我认为默认为US7ASCII）

如果Mac与您的数据库服务器不同（我猜测Mac是US7ASCII），请先尝试导出不同的NLS_LANG，然后再运行查询。例如

export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1

更多细节here

Sqlalchemy CLOB在Windows和Mac上返回不同的结果

1 个答案: