【YashanDB 知识库】GBK 库,生僻字插入 nvarchar2 字段后乱码问题
本文内容来自 YashanDB 官网,原文内容请见 https://www.yashandb.com/newsinfo/7764083.html?templateId=1718516
问题现象
如下 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 编码没有这种空白字符,导致转换失败。
版权声明: 本文为 InfoQ 作者【YashanDB】的原创文章。
原文链接:【http://xie.infoq.cn/article/a47fcaee6cacc1fbb95ff07b1】。文章转载请联系作者。
评论