达梦数据库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的编码详细情况.