一、DUMP()函数
DUMP(w[,x[,y[,z]]])
【功能】返回数据类型、字节长度和在内部的存储位置.
【参数】
w为各种类型的字符串（如字符型、数值型、日期型……）
x为返回位置用什么方式表达，可为:8,10,16或17，分别表示：8/10/16进制和字符型，默认为10。
y和z决定了内部参数位置
【返回】类型 <[长度]>，符号/指数位 [数字1，数字2，数字3，......，数字20]
如：Typ=2 Len=7: 60,89,67,45,23,11,102
SELECT DUMP('ABC',1016) FROM dual;
返回结果为：Typ=96 Len=3 CharacterSet=ZHS16GBK: 41,42,43
代码 数据类型
0 对应 VARCHAR2
1 对应 NUMBER
8 对应 LONG
12 对应 DATE
23 对应 RAW
24 对应 LONG RAW
69 对应 ROWID
96 对应 CHAR
106 对应 MSSLABEL
各位的含义如下:
1.类型: Number型,Type=2 (类型代码可以从Oracle的文档上查到)
2.长度:指存储的字节数
3.符号/指数位
在存储上,Oracle对正数和负数分别进行存储转换:
正数：加1存储(为了避免Null)
负数：被101减,如果总长度小于21个字节，最后加一个102(是为了排序的需要)
指数位换算:
正数：指数=符号/指数位 - 193 (最高位为1是代表正数)
负数：指数=62 - 第一字节
4.从<数字1>开始是有效的数据位
从<数字1>开始是最高有效位,所存储的数值计算方法为：
将下面计算的结果加起来：
每个<数字位>乘以100^(指数-N) (N是有效位数的顺序位，第一个有效位的N=0)
5、举例说明
SQL> select dump(123456.789) from dual;
返回：Typ=2 Len=6: 195,13,35,57,79,91
<指数>: 195 - 193 = 2
<数字1> 13 - 1 = 12 *100^(2-0) 120000
<数字2> 35 - 1 = 34 *100^(2-1) 3400
<数字3> 57 - 1 = 56 *100^(2-2) 56
<数字4> 79 - 1 = 78 *100^(2-3) .78
<数字5> 91 - 1 = 90 *100^(2-4) .009
123456.789
SQL> select dump(-123456.789) from dual;
返回：Typ=2 Len=7: 60,89,67,45,23,11,102
算法：
<指数> 62 - 60 = 2(最高位是0，代表为负数)
<数字1> 101 - 89 = 12 *100^(2-0) 120000
<数字2> 101 - 67 = 34 *100^(2-1) 3400
<数字3> 101 - 45 = 56 *100^(2-2) 56
<数字4> 101 - 23 = 78 *100^(2-3) .78
<数字5> 101 - 11 = 90 *100^(2-4) .009
123456.789(-)
现在再考虑一下为什么在最后加102是为了排序的需要，-123456.789在数据库中实际存储为
60,89,67,45,23,11
而-123456.78901在数据库中实际存储为
60,89,67,45,23,11,91
可见，如果不在最后加上102，在排序时会出现-123456.789<-123456.78901的情况。oracle 时间转换
二、substrb函数
substr和substrb
以前知道有substrb,lengthb等函数，也知道它们是以byte来计算长度，可没用过，也不太明白什么地方需要用到它们。一直就是用substr,length，以字符来计算长度，在我看来varchar2和char里面存的都是字符，那么自然也就不可能以byte为单位来计算长度，也就用不到这些函数了，但事实证明我错了。最近有个procedure出错,往表里insert时总是报1401错误,看了一下程序,觉得问题很奇怪，目标表出错字段的长度是50，insert的对应这个字段的取法也是substr(**,1,50)，怎么会出错呢？有些怀疑是汉字字符为双字节的原因，于是试着将substr(**,1,50)改为了substr(**,1,25)，果然ok。上网原因，在asktom上到了解答。
数据库里的varchar2和char字段长度定义是有两种方式，按字节或按字符，按字节定义长度的方式是varchar2(n byte)或者char(n byte)，这也是缺省的长度定义方式，也就是说，平时我们用到的varchar2(n)或者char(n)都是按字节定义长度的，按字符定义长度的方式是varchar2(n char)或者char(n char)，这样的定义方式可以确保字段有足够的空间储存需要的字符，无论这些字符的长度是多少字节。我们遇到的这个错误的原因在于，数据库的字符集是多字节字符集，也就是说中文字符占多个字节，而源字段的内容都是中文，这样sub
str(**,1,50)的字节长度可能达到100，自然超过了目标表字段中的50了。
总结一些经验和教训，觉得在建表之前，如果某个字段需要储存中文的话，最好明确一下字段需要的长度是否是按字符来决定的。如果是按字符并且数据库字符集为多字节，那建表时就应该采取按字符定义长度的方式来定义该字段的长度。
一个汉字有几个字节？
依据编码形式：
GB－231280 编码为 2个字节(Byte) 包含了 20902 个汉字，其编码范围是 0x8140-0xfefe。
GB18030-2000(GBK2K) 在 GBK 的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。编码是变长的，其二字节部分与 GBK 兼容；四字节部分是扩充的字形、字位，其编码范围是首字节 0x81-0xfe、二字节0x30-0x39、三字节 0x81-0xfe、四字节0x30-0x39
Unicode 范围一般所用为\U0000-\UFFFF，对于CJK EXT B区汉字，范围大于\U20000
UTF， 按其基本长度所用位数分为UTF-8/16/32。其中：
UTF-8是变长编码，每个Unicode代码点按照不同范围，可以有1-3字节的不同长度。
UTF-16长度相对固定，只要不处理大于\U200000范围的字符，每个Unicode代码点使用16位即2字节表示，超出部分使用两个UTF-16即4字节表示。按照高低位字节顺序，又分为UTF-16BE/UTF-16LE。
UTF-32长度始终固定，每个Unicode代码点使用32位即4字节表示。按照高低位字节顺序，又分为UTF-32BE/UTF-32LE。
一般用GB－231280 ，所以大多数情况下是占2个字节。
substrb等函数因字符集不同所造成的差异技术经验随笔
以前一直都是认为英文字母,数字及其他特殊字符占一个字节,汉字占两个字节.但是最近在oracle数据库中编程时使用的substrb出现了错误.
substrb函数是按字节截取特定长度的字符串.而我使用后却得不到想要的结果,原因就出在了字符串中的汉字上了.
接着,我便进行了测试.结果如下:
substrb('大小abc',1,3) 结果为: '大'
substrb('大小abc',1,4) 结果为: '大 ' (包含一个空格)
substrb('大小abc',1,5) 结果为: '大 ' (包含两个空格)
substrb('大小abc',1,6) 结果为: '大小'
通过以上结果可推断,数据库中把一个汉字当成三个字节了.而在论坛上其他网友的测试结果却是汉字占的两个字节.后来才知道,我的数据库选择的字符集是utf-8的形式,这个字符集汉字会表示为多于两个字节.由此可知,其他关于对字节操作的函数处理汉字时也应该会有以上的问题,例如lengthb函数.看来以后要多多注意了.
另外,不同字符集设置对于用同一个函数处理汉字字符串可能会得出不同结果.在网上
搜了一会儿关于不同字符集其各自定义的汉字所占字节数的总结.结果没有满意的答案,都很零碎.以后有时间再吧.
三、convert() 函数
oracle sql如何把us7ascii的字符串编码转换为utf8或者gb2312编码用CONVERT(char, dest_char_set [,source_char_set] )函数
windows可以直接修该
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDb10g_home1 nls_lang值为
SIMPLIFIED CHINESE_CHINA.ZHS16GBK
或使用convert 函数
SQL code
SQL> select CONVERT(datatype, 'US7ASCII' ) from BSTH_SYS_FIELD_ALIAS;
CONVERT(DATATYPE,'US7ASCII')
--------------------------------------------------------------------------------
gfdfghdf
??
SQL> select CONVERT(datatype, 'ZHS16GBK' ) from BSTH_SYS_FIELD_ALIAS;
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论