因为历史遗留问题，好多现场都被生僻字折磨的死去活来，当然我也经历过这个问题，网上搜索了下，看到的解决方案也是乱七八糟，感觉解决方案都多少有点问题，首先需要先明确一点，生僻字为什么乱码？核心原因就是gbk字符集下并没有对应汉字的编码。
官方解决方案连接： Oracle 租户 GBK 字符集生僻字显示乱码-OceanBase数据库使用指南
从数据库原理角度，个人分析，上述解决办法并不靠谱，往gbk字符集里面直接存储，底层的编码无论如何都是错误的，拿着错误的编码再进行转码分析，即使显示正常了，也不对。
1.首先我们要理解，数据库里面的数据是展示给谁看的
数据库里存储的数据，正常情况下，我们是展示给前台界面查询的，我们后台字符界面查询数据都是不合理、不合规的。那么明确了这点，我们来继续解决生僻字问题。
2.那么如何解决gbk字符集下生僻字的问题呢？
1.我们要将编码存储正确
2.我们要将编码进行转储正确
3.如何将生僻字编码存储正确呢？
以"䶮"字为例，gbk编码下是没有这个汉字的，如果我们强制写到数据库中，那么不好意思，gbk字符集并不理解该数据，会胡乱进行转码操作，这样导致的问题就是底层存储的编码就是错误的，无论你怎么设置，你存储的编码都不正确，解析出来怎么可能正确呢？
“䶮"字在gbk编码下是不存在的，但是在gb18030字符集下是存在的，那么好了，我们就可以做如下方案，首先获取"䶮"字在gb18030下的正确编码，正确的编码就是"FE9F”,我们直接往底层插入正确的编码
ORACLE租户下的解决方案：
insert into t value(utl_raw.cast_to_varchar2(‘FE9F’)));
MySQL租户下的解决方案：
insert into t value(x’FE9F’);
4.前台界面如何展示呢？
到这里大家肯定有一个疑惑，你插入的编码格式，我数据库字符集是gbk，也不兼容，我在后台也没办法读取到正确的数据呀？如果有这个疑问，我们还是不理解数据库存储的数据是给谁展示的。后台数据是展示给前台人员的，我们仅需要前台获取正确就可以了
解决方案也比较简单，业务从数据库获取的jdbc连接串characterEncoding=GB18030既可
因为GB18030和gbk编码都是中文编码，他们两个字符集不需要来回通过character参数进行来回转换，直接获取出来就行了。