凡是有但是-varchar和nvarchar的初步学习之一

凡是有但是-varchar和nvarchar的初步学习之一

---

背景

高应用开发, 在涉及到国内国外的问题时,重要的事情有两个:
时区转换, 字符集转换. 

时区转换虽然是很难理清楚, 各种规范不统一的事情
但是字符集转换更加扯淡. 

如果是一种数据库,一种字符集可能还好说
现在面临的是 多种数据库: 开源,商业,信创,分布式...
这时候就已经是一头雾水了.
自己虽然看了一阵子, 但是依旧是迷迷糊糊的.
所以想先总结一下, 希望后续能够慢慢的将内容夯实

---

varchar和nvarchar

数据库有varchar和nvarchar
其实一个比较重的区别是:
部分数据库 varchar 后面的数字指的是 这个字段能够存储的字节数.
nvarchar 后面的数字, 基本上指的是能够存储的字符数. 

这里就有一个 凡是有但是.
Mysql8数据库虽然有 varcahr和nvarcahr, 但是他计算长度限制是按照字符数来进行计算.
所以就引入了 mysql utf8mb3 和 utf8mb4 下数据库varcahr总长度限制的问题. 

另外神通数据库有这么一个参数, 可以指定varchar的长度限制.
DEFAULT_VARCHAR_LEN=1
会改变varchar的存储情况.

---

Oracle和MySQL的限制问题

SQLServer的限制: 注意我的排序规则是 chinese_prc_ci_as
varchar时:
消息 131，级别 15，状态 2，第 6 行
The size (8001) given to the column 'zhaobsh' exceeds the maximum allowed for any data type (8000).
nvarchar时:
消息 2717，级别 16，状态 2，第 7 行
The size (8000) given to the parameter 'zhaobsh' exceeds the maximum allowed (4000).

数据库会有一些底层的限制

Oracle数据库一开始与SQLServer的限制是一样的
也是在ZHS16GBK的字符集  varchar(8000) nvarchar(4000)
但是Oracle19c 时进行了一定程度的扩张:
32767 bytes if MAX_STRING_SIZE = EXTENDED
4000 bytes if MAX_STRING_SIZE = STANDARD

但是据说这个参数修改起来很麻烦:
数据库需要 startup UPGRADE 以升级模式启动，
然后才能修改参数，
alter system set MAX_STRING_SIZE = EXTENDED scope=spfile;
并且需要跑脚本 utl32k.sql,
然后关闭数据库再正常重启数据库。

注意这里面有一个深坑, 如果不改这个参数 oracle12c 以后可以创建一个 3万多长度的varchar列
但是插入数据时 就会被截断到 4000 / 80000 的长度.

---

关于字符编码

需要说明, 字符集是字符集, 字符编码格式是字符编码格式.
只不过国内的 GB2312 GBK GB18030 既是字符集,又是编码格式.
所以很多人有所混淆. 

unicode 是字符集, 用来进行全世界所有字符的展示
utf-8 是编码格式,用于计算机系统进行存储.
utf-16 utf-32 是另外两种编码格式, 不通电是针对字符长度的限制是不一样的.

---

字符编码的特点

广义的 Unicode 是一个标准，定义了一个字符集以及一系列的编码规则，
即 Unicode 字符集和 UTF-8、UTF-16、UTF-32 等等编码……

Unicode 字符集为每一个字符分配一个码位，例如「知」的码位是 30693，记作 U+77E5（30693 的十六进制为 0x77E5）。
UTF-8 顾名思义，是一套以 8 位为一个编码单位的可变长编码。会将一个码位编码为 1 到 4 个字节：

U+ 0000 ~ U+ 007F: 0XXXXXXX
U+ 0080 ~ U+ 07FF: 110XXXXX 10XXXXXX
U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX
U+10000 ~ U+1FFFF: 11110XXX 10XXXXXX 10XXXXXX 10XXXXXX

根据上表中的编码规则，之前的「知」字的码位 U+77E5 属于第三行的范围：

       7    7    E    5
    0111 0111 1110 0101    二进制的 77E5
--------------------------
    0111   011111   100101 二进制的 77E5
1110XXXX 10XXXXXX 10XXXXXX 模版（上表第三行）
11100111 10011111 10100101 代入模版
   E   7    9   F    A   5

这就是将 U+77E5 按照 UTF-8 编码为字节序列 E79FA5 的过程。反之亦然。

---

varchar与nvarchar解决的问题

varchar 应该只是按照数据库的字符集进行文件的存储, 只能够存储编码格式,字符集,排序规则内的字符
无法保存非自己字符集内的字符. 

nvarchar 则是将字符按照unicode 等格式进行保存.
这样的话, 能够保证非标准字符集支持的字符进行展示. 

一定程度下可以实现国际化多语的需求.

---

其他数据库的情况

PG数据库没有 nvarchar
他的字符类型就是 varchar char 还有 text
他应该默认使用utf8国际化支持, 然后 数字表示的是字符长度.

mysql数据库 有nvarchar的类型
但是他的varchar 也是按照字符进行存储, 理论上也是字符, 不是字节.
mysql的坑在于 utf8mb3和 utf8mb4 

国产数据库里面要看支付的字符集.
国产信创必须要支持GB18030字符集.
但是GB18030与UTF8应该不是严格意义上的子集和超集的关系
所以很多表现也与字符集有关系.

UTF8的出现其实比很多数据库的出现要晚一些.
SQLServer其实到了2019的版本才严格支持 utf8
因为微软的国际化做的其实比utf8要更久和更踏实, 其实sqlserver的历史包袱也是最大的.