本文内容来自YashanDB官网，原文内容请见 GBK库，生僻字插入nvarchar2字段后乱码问题-YashanDB

问题现象

如下SQL，插入的人名中有两个GBK生僻字“ ”和“ ”，GBK编码中没有这两个字符。

插入后，客户端utf8编码，显示为乱码。用gbk和

问题的风险及影响

客户端和服务端编码不同，服务端是gbk时，gbk生僻字，插入不正常。

问题影响的版本

23.2.4.14及之前版本

问题发生原因

gbk生僻字，客户端转换数据为gbk编码时，生僻字转换失败，发送给服务端存储的数据缺失，导致显示问题。

解决方法及规避方式

1、终端是utf8，这样可以输入生僻字。yasql用gbk编码，同服务端编码一样，就不会转码。用insert语句发送，之后同样的编码能正常查询显示出数据。

2、使用yasdb client库接口，yacBindParameter接口提供了utf16编码插入数据方式。如下图所示，只要不是gbk编码就能正常显示生僻字：

问题分析和处理过程

分析过程：

客户端是utf8，服务端是gbk编码的情况。

1、服务端收到客户端的数据，如下图

C1D9 GBK(临) 193 217

BAA3 GBK(海) 186 163

3F 生僻字 丢失 为63

2、insert时，yasdb中数据的字符

4E34 utf16（临）78 52

6D77 utf16（ 海）109 119

3F

3 、 客户终端与客户端编码不同时，存储的数据是否有问题呢？如客户终端编码为utf8，yasql为gbk、yasdb为gbk。

nvarchar2类型， 服务端中会再做转换，这里就出现了这个问题。utf8的终端，gbk的yasql，gbk的服务器情况下，插入汉字后， 数据是utf8编码，但是当成gbk编码转换成utf16，导致存储的数据不对。

如下例：

yasdb接收的数据：

yasql客户端同服务端编码相同，则不做转换，直接发送输入数据到服务端。所以下图显示的是utf8编码的'艳梅'数据

39 232 137 179 230 162 133 39 接收到的是utf8编码的 '艳梅' 

yasdb存储的数据：

yasdb存放的就是上面的编码。0x79(121) 0x94(148) 0x46(107) 0xB8(134) ，存储的不是'艳梅'的utf16编码，而是'艳梅'utf8编码当成gbk编码转换后的utf16编码。

所以当终端是utf8时，yasql和yasdb是gbk时，存储在nvarchar2字段上的数据其实是错误的。所以如果数据要正确存储，yasql插入时，终端和yasql的编码必须相同。

结论：

所以在用yasql插入数据时，要保证终端与yasql的编码相同，否则数据可能存储的有问题。

经验总结

yasql编码转换过程：

1、yasql insert插入时，数据编码转换过程

输入的数据 (客户终端编码) →（转换)数据为 服务端编码（gbk）(如果yasql客户端同服务端编码相同，则不做转换，直接发送输入数据到服务端。) → 发送数据到服务端

服务端接收到数据后 ：nvarchar2类型，在服务端转换为utf16le编码。

2、yasql select查询时，数据编码转换过程

服务端(GBK) ->(发送数据) 客户端（UTF8） → (转换数据编码gbk->utf8）yasql客户端编码 → 终端同yasql客户端编码一致才能正常显示出来。

如果客户端是gbk，nvarchar2类型的编码转换：UTF16 → gbk

相关问题单

1、服务端gbk，nvarchar2插入gbk不识别的生僻字，插入后乱码问题

22.2.12.100 GBK库nvarchar列无法存放中文生僻字

2、服务端gbk，客户端utf8，exp导出报错转换失败，YAS-00218 string conversion failed

数据库使用GBK字符集，exp导出成csv报错

exp导出时，如上图，“世纪春城”前面两个空白字符不是空格，而是gbk的空白字，utf8编码没有这种空白字符，导致转换失败。