【MOGDB/openGauss与PostgreSQL关于GBK字符集问题】

最近，在验证不同字符集数据类型存储数据位数的时候发现：
PG12不支持server_encoding=GBK。以及MOGDB/openGauss 2.0.1 build d97c0e8a支持 server_encoding=GBK。

 测试过程一开始以为MOGDB/openGauss对于server_encoding=GBK的支持有问题，但之前的文章有读者看完后给予了我反馈和纠正，经过我进一步测试，以及和社区研发人员的沟通，发现确实是我的疏忽，忽视了输入终端的字符编码影响，在这里对给予反馈的朋友表示感谢。

下边的文章进行了部分补充以及纠正：

开始的时候是想验证一下PostgreSQL里不同字符集 varchar varying（5）是不是都能存五个汉字，因此进行了如下测试，

 

UTF-8字符集时候varchar不加括号的话可插入的值就是变长的

在测试GBK字符集的时候，发现PostgreSQL是不支持server_encoding=GBK的，如下是PG12的官方文档

然后想到了MOGDB/openGauss这边，虽然MOGDB/openGauss据说是基于PG-9.2.4为基础研发的，但平时使用的时候就发现了他在一些方面做了优化，弥补了PG本身的不足，又进行了如下的测试，

上边这个报错，可以看到 server_encoding,client_encoding都是GBK的。

但是为什么插入还报错了呢，其实字符集涉及到三个因素 ，数据库服务端、数据库客户端、输入终端（包括文件），我忽视了输入终端的字符编码，例如xshell，crt等等本身也有终端的输入字符变编码，所以导致了上边的现象。

文本编码修改为GBK后进行相同测试，发现数据正常插入进去了，果然是输入终端的字符编码原因导致的。

通过实际的验证其实发现openGauss对于GBK的支持还是可以的。之前分析问题的时候去翻了翻源码，偶然发现在一部分的注释上写着这么一段话，翻译过来大概意思是：openGauss数据库在将GBK更改为数据库编码时，并没有真正考虑需要更改的代码的每个方面。

后续和openGauss社区的研发人员进行了一些沟通，经过反馈和验证，发现openGauss随着版本的迭代对于GBK的支持其实已经比较成熟了，代码部分也进行了大量改动，实际上仅仅是注释部分没有及时更新。而我此前的测试失败的问题也如评论的朋友所说，是我输入终端字符编码的问题。

支持server_encoding=GBK，其实是openGauss相比PostgreSQL的一大优势，因为在PostgreSQL中服务端完全不支持GBK字符集。

但是作为一款开源软件，个人比较希望社区之后在更新代码的同时也及时更新注释部分，否则大量的代码，结合表意不明和陈旧的注释，代码的易读性就差了。在用户进行阅读和分析的时候，可能会一头雾水，甚至在分析问题的时候，根据注释内容产生错误的判断。