也可能是原始数据导入的时候某个环节的字符集是gbk?

不是改UTF8就解决乱码了,重要的是字符集环境和数据要匹配,你先试下查询的时候转码,看看能不能解析出来,看看这个数据的字符集到底是个啥

select CONVERT(字段名, 'ZHS16GBK', 'AL32UTF8') from 表;
select CONVERT(字段名, 'AL32UTF8', 'ZHS16GBK') from 表;
复制

还有看看这个十六进制数据,分析下这几个字的字符集是啥

select utl_raw.cast_to_raw(字段名) from 表名
复制

再查个东西

select * from nls_session_parameters
复制

userenv 的language是数据库的字符集，不是会话的字符集

select utl_i18n.raw_to_char( UTL_I18N.string_to_raw('涓嬶級','ZHS16GBK'),'AL32UTF8') from dual
复制

原则上，和DB端字符集设置无关。一句话：NLS_LANG里的NLS_CHARCTERSET的设置，可以和DB端的NLS_CHARCTERSET不一致（因为与DB端交互时，系统会自动做字符集转换），但必须和OS的NLS_CHARCTERSET项一致，否则便会乱码。

连接DB的客户端，应该是WINDOWS。那么看这台WINDOWS在OS层面的NLS_LANG设置和环境变量里的NLS_LANG设置，是否一致就可以了。

Windows下，cmd窗口运行set NLS_LANG查看环境变量值，或者到注册表里查询NLS_LANG这一项的内容。这是环境变量设置。

Windows: cmd窗口敲chcp命令，得到字符集代码
例如：
C:\Users\Administrator>chcp
活动代码页: 936
代码936代表 中国 - 简体中文(GB2312)

查下OS层面的设置，和NLS_LANG环境变量是否一致。应该就是因为不一致，造成的乱码。