[20200103]GUID转换GUID_BASE64.txt「建议收藏」

[20200103]GUID转换GUID_BASE64.txt「建议收藏」[20200103]GUID转换GUID_BASE64.txt–//最近在做一个项目优化,里面大量使用uuid.优缺点在链接:http://blog.itpub.net.x.y265/viewspa

[20200103]GUID转换GUID_BASE64.txt

[20200103]GUID转换GUID_BASE64.txt

–//最近在做一个项目优化,里面大量使用uuid.优缺点在链接:http://blog.itpub.net.x.y265/viewspace-2670513/=>[20191225]主键使
–//用uuid优缺点.txt 有相关讨论.我自己的观点不要滥用,或者讲到处都用,合理使用才是比较正确的选择.

–//昨天看12c相关书籍,发现oracle给每个PDB设置唯一GUID.我查看视图V$CONTAINERs,发现有1个字段GUID_BASE64,很明显这个从guid转
–//换过来,自己想知道这个转换如何实现的?

1.环境:
SYS@192.168.x.y:1521/orclcdb> select banner from v$version;
BANNER
———————————————————————-
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 – Production

SYS@192.168.x.y:1521/orclcdb> select sys_guid() from dual ;
SYS_GUID()
——————————–
9B25CF226E3E36A5E0558253DD747177

SYS@192.168.x.y:1521/orclcdb>  select CON_ID,DBID,CON_UID,NAME,GUID,GUID_BASE64 from V$CONTAINERs;
CON_ID       DBID    CON_UID NAME     GUID                             GUID_BASE64
—— ———- ———- ——– ——————————– ————————
     1 2756091850          1 CDB$ROOT 64A52F53A7683286E053CDA9E80AED76 ZKUvU6doMobgU82p6Artdg==
     2 1474312904 1474312904 PDB$SEED 742DCFA2CE044FDEE0558253DD747177 dC3Pos4ET97gVYJT3XRxdw==
     3  115310104  115310104 ORCL     74A69DC145F5662BE0558253DD747177 dKadwUX1ZivgVYJT3XRxdw==

–//注意看sys_guid()后面16位E0558253DD747177,居然没有变化,不知道为什么.
–//GUID_BASE64后面2位是字符”==”,不可能3个正好都是==,一定是用来填充保持字符串长度24.

2.首先我必须确定GUID_BASE64的编码:
–//base64,我的理解就是64进制,确定编码很重要,最容易联想到的rowid编码也是64进制,是否其编码与它一样.
–//我检索发现如下链接:
https://docs.oracle.com/cd/E18150_01/javadocs/DevelopmentKit/com/stc/connector/framework/util/Base64.html

–//内容如下:
            Table 1: The Base64 Alphabet
Value Encoding  Value Encoding  Value Encoding  Value Encoding
   0 A            17 R            34 i            51 z
   1 B            18 S            35 j            52 0
   2 C            19 T            36 k            53 1
   3 D            20 U            37 l            54 2
   4 E            21 V            38 m            55 3
   5 F            22 W            39 n            56 4
   6 G            23 X            40 o            57 5
   7 H            24 Y            41 p            58 6
   8 I            25 Z            42 q            59 7
   9 J            26 a            43 r            60 8
  10 K            27 b            44 s            61 9
  11 L            28 c            45 t            62 +
  12 M            29 d            46 u            63 /
  13 N            30 e            47 v
  14 O            31 f            48 w         (pad) =
  15 P            32 g            49 x
  16 Q            33 h            50 y
–//= 作为pad与看到结果一样.

The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other
characters no found in Table 1 must be ignored by decoding software. In base64 data, characters other than those in
Table 1, line breaks, and other white space probably indicate a transmission error, about which a warning message or
even a message rejection might be appropriate under some circumstances.

编码的输出流必须以不超过76个字符的行表示。所有行打断或其他解码软件必须忽略表1中没有找到的字符。在base64数据中,除了那些
表1、断行和其他空白可能表示传输错误,有关该错误的警告消息或在某些情况下,即使是拒绝信息也可能是合适的。

Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full
encoding quantum is always completed at the end of a body. When fewer than 24 input bits are available in an input
group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is
performed using the “=” character. Since all base64 input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded
output will be an integral multiple of 4 characters with no “=” padding, (2) the final quantum of encoding input is
exactly 8 bits; here, the final unit of encoded output will be two characters followed by two “=” padding characters, or
(3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one “=” padding character.

如果在被编码数据的末尾有少于24位可用,则执行特殊处理。一个完整的编码量子总是在物体的末端完成。当一个输入中可用的输入位少
于24位时组,零位被添加(在右边)形成一个6位组的整数。数据末尾的填充物是使用”=”字符执行。由于所有base64输入都是八进制的整数
,所以只有以下情况才能产生:
(1)编码输入的最终量子是24位的整数倍;这里是编码的最终单位输出将是4个字符的整数倍,没有”=”填充.
(2)编码输入的最终数量是8位,编码输出的最终单位将是两个字符,后面跟着两个”=”填充字符,或者
(3)编码输入的最终量子正好是16位;这里,编码输出的最终单位是三位字符后面跟着一个”=”填充字符。

Because it is used only for padding at the end of the data, the occurrence of any “=” characters may be taken as
evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible,
however, when the number of octets transmitted was a multiple of three and no “=” characters are present.

因为它只用于数据末尾的填充,所以任何”=”字符的出现都可以作为数据结束的证据已经到达(在运输过程中没有截断)。不可能有这样的
保证,然而,当传输的八位数是三个的倍数,并且没有”=”字符存在时。

Any characters outside of the base64 alphabet are to be ignored in base64-encoded data.

在base64编码的数据中,base64字母表之外的任何字符都将被忽略。

Care must be taken to use the proper octets for line breaks if base64 encoding is applied directly to text material that
has not been converted to canonical form. In particular, text line breaks must be converted into CRLF sequences prior to
base64 encoding. The important thing to note is that this may be done directly by the encoder rather than in a prior
canonicalization step in some implementations.

如果base64编码直接应用于尚未转换为规范形式。特别是,文本换行必须先转换成CRLF序列。base64编码。重要的是要注意的是,这可能
是由编码器直接完成的,而不是在以前完成的。规范化步骤在一些实现中。

NOTE: There is no need to worry about quoting potential boundary delimiters within base64-encoded bodies within
multipart entities because no hyphen characters are used in the base64 encoding.   

–//注:翻译我使用金山词霸,可能存在一些瑕疵…
–//这样base64的编码可以确定.A_Z a-z 0-9 +/

3.我写一个测试脚本:
 $ cat 64base.sh
#! /bin/bash
v2=$1
BASE64=($( echo {A..Z} {a..z} {0..9} + / ))

res=””
for i in $(echo “obase=64;ibase=16; $v2” | bc| tr -d “\ “)
do
    res=${res}${BASE64[$(( 10#$i ))]}
done

echo $res

$ ./64base.sh 74A69DC145F5662BE0558253DD747177
B0pp3BRfVmK+BVglPddHF3

–//完全对不上.我再仔细看链接https://docs.oracle.com/cd/E18150_01/javadocs/DevelopmentKit/com/stc/connector/framework/util/Base64.html
–//说明.
When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral
number of 6-bit groups. Padding at the end of the data is performed using the “=” character.

–//有1个非常明显的提示 “zero bits are added (on the right) to form an integral number of 6-bit groups”.
–//guid的显示74A69DC145F5662BE0558253DD747177,占32字符.32*4 = 128 bits.
–//base64 相当于2^6,也就是6 bits表示1个64进制字符.
–//128/6 = 21.333,明显无法整除,这样结尾要补上1个0(占4bits).
–//(128+4)/6 = 22,这样正好整除.
–//补上1个0再计算如下:

$ ./64base.sh 74A69DC145F5662BE0558253DD7471770
dKadwUX1ZivgVYJT3XRxdw

–//^_^正好对上.可以验证看看.

$ echo 64A52F53A7683286E053CDA9E80AED760 742DCFA2CE044FDEE0558253DD7471770 74A69DC145F5662BE0558253DD7471770 | tr ” ” ” ” | xargs -IQ ./64base.sh Q
ZKUvU6doMobgU82p6Artdg
dC3Pos4ET97gVYJT3XRxdw
dKadwUX1ZivgVYJT3XRxdw

SYS@192.168.x.y:1521/orclcdb>  select CON_ID,DBID,CON_UID,NAME,GUID,GUID_BASE64 from V$CONTAINERs;
CON_ID       DBID    CON_UID NAME     GUID                             GUID_BASE64
—— ———- ———- ——– ——————————– ————————
     1 2756091850          1 CDB$ROOT 64A52F53A7683286E053CDA9E80AED76 ZKUvU6doMobgU82p6Artdg==
     2 1474312904 1474312904 PDB$SEED 742DCFA2CE044FDEE0558253DD747177 dC3Pos4ET97gVYJT3XRxdw==
     3  115310104  115310104 ORCL     74A69DC145F5662BE0558253DD747177 dKadwUX1ZivgVYJT3XRxdw==
–//对比完全能对上.当然不包括后面的两个=.

4.修改脚本如下:
$ cat o64base.sh
#! /bin/bash
# convert guid to guid_base64
odebug=${ODEBUG:-0}

v2=${1}0
BASE64=($( echo {A..Z} {a..z} {0..9} + / ))

res=””
for i in $(echo “obase=64;ibase=16; $v2” | bc| tr -d “\ “)
do
    res=${res}${BASE64[$(( 10#$i ))]}
done

if [ $odebug -eq 1 ] ; then
    echo v2=$v2 res=$res
fi

res=${res}==
echo $res

$ ./o64base.sh 74A69DC145F5662BE0558253DD747177
dKadwUX1ZivgVYJT3XRxdw==

5.总结:
–//纯属无聊,浪费一个下午探究这个问题.
–//在测试时我使用链接https://toolslick.com/conversion/data/guid的在线转换工具,不然估计我无法猜测到如何实现.

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/10299.html

(0)
上一篇 2022-12-30
下一篇 2022-12-30

相关推荐

  • Python CGI示例:使用Python编写服务器端脚本

    Python CGI示例:使用Python编写服务器端脚本CGI(Common Gateway Interface)是Web服务器和其它程序之间的接口,它是一种标准,定义了客户端和服务器端之间传输数据的规范和格式。CGI程序可以使用各种编程语言编写,如Perl、C、C++、Python等。

    2024-03-19
    44
  • 在plsql字符串拼接,批量生成trigger

    在plsql字符串拼接,批量生成trigger本次需要批量编写监控全数据库表的trigger,记录下变更的字段名和变更的值、表名、相对应的主键和做的操作(增删改)。在自动生成脚本sql后,执行execute immediate sql_str –

    2023-04-26
    122
  • 陈胡:Apache SeaTunnel实现 非CDC数据抽取实践「建议收藏」

    陈胡:Apache SeaTunnel实现 非CDC数据抽取实践「建议收藏」导读: 随着全球数据量的不断增长,越来越多的业务需要支撑高并发、高可用、可扩展、以及海量的数据存储,在这种情况下,适应各种场景的数据存储技术也不断的产生和发展。与此同时,各种数据库之间的同步与转化的需

    2023-05-18
    121
  • linux安装sqlmap「建议收藏」

    linux安装sqlmap「建议收藏」下载安装包:sqlmapproject-sqlmap-1.4.8-3-g4077a35.tar.gzhttps://github.com/sqlmapproject/sqlmap/tarball/m…

    2023-04-01
    119
  • 利用pip安装cv2的步骤

    利用pip安装cv2的步骤在计算机视觉及图像处理领域,cv2是一款非常常用的Python库。它可以在Python中调用OpenCV(开源计算机视觉库),让Python开发者更加便途地完成图像和视频处理相关的任务。
    在本篇文章中,我们将通过几个方面详细阐述利用pip安装cv2的步骤。通过本文的学习,读者将会掌握如下知识:

    2024-05-01
    34
  • window kafka安装部署_kafka windows

    window kafka安装部署_kafka windowskafka在windows下的安装与配置 By: 授客 QQ:1033553122 1.测试环境…………………………………………….

    2023-03-20
    136
  • HBase Filter 过滤器概述[通俗易懂]

    HBase Filter 过滤器概述[通俗易懂]abc 过滤器介绍 HBase过滤器是一套为完成一些较高级的需求所提供的API接口。 过滤器也被称为下推判断器(push down predicates),支持把数据过滤标准从客户端下推到服务器,带有

    2023-02-20
    114
  • 列约束fk_列级约束和元组级约束的区别

    列约束fk_列级约束和元组级约束的区别check 约束意思,就是对一列或者多列按照一定的预先设置好的规则进行过滤,条件为真,则过滤成功;条件为假,则过滤失败,返回失败代码给客户端。 为什么要把这个单独列出来写呢,经常遇到不规范的 SQL…

    2023-02-27
    111

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注