达梦数据库varchar和nvarchar的验证

测试SQL

create tablespace zhaobsh datafile '/opt/dmdbms/data/DAMENG/zhaobsh.dbf' size 128
# 需要注意 达梦数据库的大小限制为:
# 第1 行附近出现错误[-2422]:数据文件[/opt/dmdbms/data/DAMENG/zhaobsh.dbf]大小无效，取值范围为(128~67108863)M.
重建用户
create user zhaobsh identified by  Testxxxx default tablespace  zhaobsh ;
grant dba to zhaobsh ; 

重建表等信息:
create table zhaobsh (zhaobshvarchar varchar(30),zhaobshnvarchar nvarchar(30)) ;
insert into zhaobsh values ('123abc','123abc') ;
insert into zhaobsh values ('abcd赵1234','abcd赵1234') ;
insert into zhaobsh values ('abcde한국12345','abcde한국12345') ;
insert into zhaobsh values ('abcde한국12345',N'abcde한국12345') ;

分析数据文件

SELECT CHECKPOINT(100);

据说可以将脏数据落盘, 先执行一下, 不然可能数据库里面没有插入的数据

需要注意 现代数据库都是写入log就是落盘成功
数据文件的更改要等待checkpoint 或者是开启关闭数据库时进行. 

winhex的分析

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00080060                  86 00 32  33 61 62 63 86 31 32 33        ?23abc?23
00080070   61 62 63 01 00 00 00 00  00 FF FF FF FF 7F FF FF   abc       
00080080   F9 2E 00 00 00 00 00 2C  00 B2 00 62 63 64 D5 D4   ?     , ?bcd赵
00080090   31 32 33 34 8A 61 62 63  64 D5 D4 31 32 33 34 02   1234奱bcd赵1234 
000800A0   00 00 00 00 00 FF FF FF  FF 7F FF FF F9 2E 00 00         ?  
000800B0   00 00 00 3C 00 EE 00 62  63 64 65 83 36 84 33 82      < ?bcde???
000800C0   37 F4 30 31 32 33 34 35  92 61 62 63 64 65 83 36   7?12345抋bcde?
000800D0   84 33 82 37 F4 30 31 32  33 34 35 03 00 00 00 00   ???12345     
000800E0   00 FF FF FF FF 7F FF FF  F9 2E 00 00 00 00 00 3C     ?     <
000800F0   00 FF FF 62 63 64 65 83  36 84 33 82 37 F4 30 31    bcde????1
00080100   32 33 34 35 92 61 62 63  64 65 83 36 84 33 82 37   2345抋bcde???
00080110   F4 30 31 32 33 34 35                               ?12345

简要分析-ASCII

1. ASCII的编码
感觉达梦数据库比较奇怪, 他的行首的第一个信息应该是有一个其他的作用, 所以第一个我总是找不到在哪里. 
86 00 32 33 61 62 63 86 31 32 33 61 62 63  
感觉86 就像是一个风恶魔, 表示行的分割
但是第一列的00 我理解不太了. 
但是可以看到在ASCII 里面 varchar和 nvarchar 其实表示是一样的 都是一个字节一个汉字. 

简要分析-中文

B2 00 62 63 64 D5 D4 31 32 33 34 
8A 61 62 63 64 D5 D4 31 32 33 34
在中文的表现看来. varchar和nvarchar 其实是一直的
都是展示的 赵的 GBK的编码
赵	简体中文(GB2312、GBK)	gb2312	D5D4
需要注意 GB18030 和 GBK应该是兼容的:
赵	简体中文(GB18030)	GB18030	D5D4

说明 varchar 和 nvarchar 都是 ASCII 占用一个字节, 中文占用两个字节. 

简要分析-韩文

EE 00 62 63 64 65 83 36 84 33 82 37 F4 30 31 32 33 34 35 
92 61 62 63 64 65 83 36 84 33 82 37 F4 30 31 32 33 34 35

注意他存储的是: 
한국	简体中文(GB18030)	GB18030	83 36 84 33 82 37 F4 30

因为我选择的是 GB18030的数据库字符集 所以韩文明显存储的就是 GB18030的信息
需要说明的是
韩文是 四字节的 编码. 
所以 两个韩文其实使用了 8个字节进行存储

同事也说明. 
不管是varchar 和 nvarchar 在进行 韩文的存储时也是一样的. 

插入是增加 N 的效果

FF FF 62 63 64 65 83 36 84 33 82 37 F4 30 31 32 33 34 35 
92 61 62 63 64 65 83 36 84 33 82 37 F4 30 31 32 33 34 35

跟上面一个一样,其实达梦数据库不管带不带 N 都是一样的进行存储, 基本上是没有问题的. 

总结

感觉虽然达梦和Oracle的语法很像.
但是感觉他对varchar和nvarchar的处理与 MySQL是很相似的. 

多种使用方法下其实是一致的体验. 
GB18030其实也是一个很好的字符集, 至少东亚圈的部分显示都可以做到.
国际化更加深远的部分就不得而知了

过段时间学习下一年GB18030的编码详细情况.