[20250403]GUID转换GUID_BASE64(补充).txt
[20250403]GUID转换GUID_BASE64(补充).txt
--//以前写过一篇GUID转换GUID_BASE64的文章，链接：[20200103]GUID转换GUID_BASE64.txt
--//实际上linux直接有一个命令base64直接实现转换，实际上当时我也做了测试，忽略一些编码问题，先要转换raw类型再计算，导致当
--//时计算老是不对，自己当时也不明白问题在那里。在21c下重复测试，并说明遇到的一个问题，顺便做一个记录。
1.环境：
SYS@book> @ver2
==============================
PORT_STRING : x86_64/Linux 2.4.xx
VERSION : 21.0.0.0.0
BANNER : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
BANNER_FULL : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
BANNER_LEGACY : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
CON_ID : 0
PL/SQL procedure successfully completed.
2.测试：
SYS@book> select CON_ID,DBID,CON_UID,NAME,GUID,GUID_BASE64 from V$CONTAINERs;
CON_ID DBID CON_UID NAME GUID GUID_BASE64
------ ---------- ---------- -------- -------------------------------- ------------------------------
1 1617337831 1 CDB$ROOT C8209F27C6B16005E053362EE80AE60E yCCfJ8axYAXgUzYu6ArmDgA=
2 2763294012 2763294012 PDB$SEED 1F36DBBBA2C8169BE0636538A8C04D12 Hzbbu6LIFpvgY2U4qMBNEgA=
3 1073777561 1073777561 BOOK01P 1F36F47256D41C08E0636538A8C03260 Hzb0clbUHAjgY2U4qMAyYAA=
$ echo -n 1F36F47256D41C08E0636538A8C03260|xxd -r -p | base64
Hzb0clbUHAjgY2U4qMAyYA==
--//结尾不对，出现2个等号，作为pad字符。补充两个0，再验证看看。
$ echo -n 1F36F47256D41C08E0636538A8C0326000|xxd -r -p | base64
Hzb0clbUHAjgY2U4qMAyYAA=
$ echo -n 1F36DBBBA2C8169BE0636538A8C04D1200|xxd -r -p | base64
Hzbbu6LIFpvgY2U4qMBNEgA=
$ echo -n C8209F27C6B16005E053362EE80AE60E00|xxd -r -p | base64
yCCfJ8axYAXgUzYu6ArmDgA=
--//完全能对上。
--//再利用base64测试当时的遇到的情况：
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 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==
$ echo -n 74A69DC145F5662BE0558253DD747177|xxd -r -p | base64
dKadwUX1ZivgVYJT3XRxdw==
--//不用补充00，计算完成正确，说明后面的oracle版本做了小小改动，现在21c需要补充\0\0字符参与运算。
--//参考链接：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 +/
--//前面guid的输出占32位，base64编码64个字符(2^6),32*4 = 128，128/24 = 5.33(不能整除).
--//oracle 21c在GUID在做base64编码转换结尾加入\0\0字符，变成34字符。
--//34*4 = 136, 136%24 = 16,符合如下条件：
(3)编码输入的最终量子正好是16位；这里，编码输出的最终单位是三位字符后面跟着一个"="填充字符。
--//补充1个=
--//以前写过一篇GUID转换GUID_BASE64的文章，链接：[20200103]GUID转换GUID_BASE64.txt
--//实际上linux直接有一个命令base64直接实现转换，实际上当时我也做了测试，忽略一些编码问题，先要转换raw类型再计算，导致当
--//时计算老是不对，自己当时也不明白问题在那里。在21c下重复测试，并说明遇到的一个问题，顺便做一个记录。
1.环境：
SYS@book> @ver2
==============================
PORT_STRING : x86_64/Linux 2.4.xx
VERSION : 21.0.0.0.0
BANNER : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
BANNER_FULL : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
BANNER_LEGACY : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
CON_ID : 0
PL/SQL procedure successfully completed.
2.测试：
SYS@book> select CON_ID,DBID,CON_UID,NAME,GUID,GUID_BASE64 from V$CONTAINERs;
CON_ID DBID CON_UID NAME GUID GUID_BASE64
------ ---------- ---------- -------- -------------------------------- ------------------------------
1 1617337831 1 CDB$ROOT C8209F27C6B16005E053362EE80AE60E yCCfJ8axYAXgUzYu6ArmDgA=
2 2763294012 2763294012 PDB$SEED 1F36DBBBA2C8169BE0636538A8C04D12 Hzbbu6LIFpvgY2U4qMBNEgA=
3 1073777561 1073777561 BOOK01P 1F36F47256D41C08E0636538A8C03260 Hzb0clbUHAjgY2U4qMAyYAA=
$ echo -n 1F36F47256D41C08E0636538A8C03260|xxd -r -p | base64
Hzb0clbUHAjgY2U4qMAyYA==
--//结尾不对，出现2个等号，作为pad字符。补充两个0，再验证看看。
$ echo -n 1F36F47256D41C08E0636538A8C0326000|xxd -r -p | base64
Hzb0clbUHAjgY2U4qMAyYAA=
$ echo -n 1F36DBBBA2C8169BE0636538A8C04D1200|xxd -r -p | base64
Hzbbu6LIFpvgY2U4qMBNEgA=
$ echo -n C8209F27C6B16005E053362EE80AE60E00|xxd -r -p | base64
yCCfJ8axYAXgUzYu6ArmDgA=
--//完全能对上。
--//再利用base64测试当时的遇到的情况：
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 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==
$ echo -n 74A69DC145F5662BE0558253DD747177|xxd -r -p | base64
dKadwUX1ZivgVYJT3XRxdw==
--//不用补充00，计算完成正确，说明后面的oracle版本做了小小改动，现在21c需要补充\0\0字符参与运算。
--//参考链接：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 +/
--//前面guid的输出占32位，base64编码64个字符(2^6),32*4 = 128，128/24 = 5.33(不能整除).
--//oracle 21c在GUID在做base64编码转换结尾加入\0\0字符，变成34字符。
--//34*4 = 136, 136%24 = 16,符合如下条件：
(3)编码输入的最终量子正好是16位；这里，编码输出的最终单位是三位字符后面跟着一个"="填充字符。
--//补充1个=
浙公网安备 33010602011771号