Database 无法解码Oracle原始数据中的所有信息

我有一个可以上传文件并向文件添加元数据的应用程序。这些元数据信息存储在数据库中，但添加的部分信息以某种方式进行了编码（遗憾的是，我无法访问源代码）

Oracle数据库中元数据的原始表示形式如下所示：

0000000 90100000000000000000000512005B698015050000000000100000007000000004000000000A01000000006496D61676500000003C000000010000000A010000000A696D6167652F706E67000000002700000003000005010000000100000000000000000010000000B64653A3132E706E67700000002A0800000000000000000000000000000000000000000E737461636B76657266C6F770000000004200000100000000A0100000018444330783031635653964203078303033336433640000000A26000000100000020100033D0000003E000000010000000A0100000012134266653539343934363135633332386137363131636337346134353900

而原始序列

737461636B6F766572666C6F77

对应于

stackoverflow

询问

从dual中选择UTL_RAW.CAST_TO_VARCHAR2（）

返回以下字符串：


这里显示了元数据的值。但是属性的名称/标识符不可读。
stackoverflow
的对应名称/标识符应为
test
或包含
test
的表的外键。其他数据包含有关文件的附加信息（如校验和、标题或mime类型）

可以从原始字符串中检索不可读的数据（标识符）吗？
原始列并不总是包含字符串，因为结果看起来内容是二进制数据，更确切地说是一个jpg文件，其中包含字符串头，但包含二进制信息。
将其转换为varchar将生成表示为矩形框的无效字符码。
您在这里使用varchar所做的工作相当于使用记事本打开一个二进制文件，即winword.doc甚至.jpeg

要获得内容，您需要将其视为图像，而不是varchar

您可以使用PLSQL获取jpg文件，如下所述：

最终，可以使用以下方法获取char数据类型中的所有内容而不丢失：

select RAWTOHEX(<raw_data>) from dual;

从dual中选择RAWTOHEX（）；

这将返回整个内容作为包含其十六进制等效值的字符值，并且不应显示任何用矩形框表示的无效ANSI字符。
实际上，您将无法再读取“stackoverflow”或任何其他文本，因为您将只获得一系列十六进制值。
然后，您需要从程序中将其转换为二进制/图像并正确处理。
使用“A01”和“101”作为4字节长度的前缀，后跟以null结尾的文本

00000009 010000000000000000512005B69801505B000000010000000700000040000000010000000A01
00000006 496D61676500                   Image

0000003C 000000010000000A01
0000000A 696D6167652F706E6700           image/png

00000027 00000003000000050100000001000000050000000101
0000000B 64653A3132332E706E6700         de:123.png

000002A8 00000003000000050100000003000000070000000101
0000000E 737461636B6F766572666C6F7700   stackoverflow

00000042 000000010000000A01
00000018 444330783031663635653964203078303030333364336400
          D C 0 x 0 1 f 6 5 e 9 d   0 x 0 0 0 3 3 d 3 d

00000A26 00000001000000020100033D3D0000003E000000010000000A01
00000021 346266653539343939343631356333323861613736313431636337346134353900
          4 b f e 5 9 4 9 9 4 6 1 5 c 3 2 8 a a 7 6 1 4 1 c c 7 4 a 4 5 9

你可能想在Code Golf@Stack Exchange上发布这篇文章。他们把我发回这里：）s映射到76 t映射到77，o映射到6F，可能是一个简单的映射。我想这取决于无法读取的数据编码信息的方式。您可以使用UTL_RAW.SUBSTR提取部分原始数据，然后在子字符串上尝试各种强制转换函数，但只有当数据采用Oracle的一种格式时，这些函数才会起作用。否则，我想您可以取出子字符串，使用DUMP（）将其转换为十六进制，然后编写一些代码将其转换为所需的格式。其中有许多零（null）和可能是控制字符的内容，因此我认为无法恢复文本数据。它们看起来像以下值的（可能）字节计数的混合，也可能是下一个字节块所代表内容的指示符或标志；因此，也许有些枚举值比标签更有意义。（曾经，部分看起来几乎像一个编码的历元日期/时间，直到我意识到它不在字节边界上…）。我不认为这是不需要访问应用程序源代码就可以进一步解释的东西。问题是这是关于文件的元数据，而不是文件本身。