oracle 中的 rowid 是数据库内部用于唯一标识行的物理地址，其查询结果以 base64 编码字符串形式呈现（如 `aabrfraaeaadnz2aab`），并非十六进制；这是 oracle 的标准编码方式，不可直接按 hex 解析，需通过 `utl_encode.base64_decode` 等函数还原为原始二进制结构。
在 Oracle 数据库中，ROWID 是一个伪列（pseudocolumn），它不存储在表结构中（DESC table_name 不会显示），但可通过 SELECT ROWID FROM ... 直接查询。你看到的类似 *BB170egLyghDYQwXPUdQY1b+ 或 AABRFrAAEAADnz2AAB 的字符串，并非乱码或错误格式，而是 Oracle 对内部 6-byte 物理地址进行 Base64 编码后的标准可读表示。该编码兼顾紧凑性与 URL/SQL 安全性，因此包含 +, /, = 等字符（Base64 字符集），而非纯十六进制。
⚠️ 重要澄清：
- ROWID 本身不是十六进制字符串，也不推荐也不应被“转换为十六进制”；
- Java 中调用 rs.getRowId(1).getBytes() 获取的是 Base64 编码后的字节数组（即 ASCII 字符 'A', 'A', 'B', ... 的 byte 值），而非原始地址二进制——因此 DatatypeConverter.printHexBinary(...) 输出的是 Base64 字符串的 Hex 表示（如 "414142524672..."），毫无语义意义，且长度远超 10 字节，完全偏离设计本意。
✅ 正确解析 ROWID 的核心思路是：Base64 解码 → 提取结构字段 → 转换为可读信息。Oracle 的扩展 ROWID（如 OraRowid）通常由四部分组成（以 OOOOOO.FFF.BBBBBB.AAAA 格式逻辑划分）：
- OOOOOO：数据对象号（Data Object ID）
- FFF：文件编号（Relative File Number）
- BBBBBB：块编号（Block Number）
- AAAA：行槽号（Row Slot / Row Number）
以下是在 SQL*Plus 或 PL/SQL 中解析 ROWID 的实用示例：
SELECT
ROWID AS physical_rowid,
-- 解码整个 ROWID（返回 RAW）
UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(ROWID)) AS raw_decoded,
-- 提取并解码块号（第 16–18 字符，左补 'A' 对齐 Base64 长度）
UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(LPAD(SUBSTR(ROWID, 16, 3), 4, 'A'))) AS block_raw,
-- 将块号 RAW 转为十进制整数（注意：需按 Oracle 内部字节序处理）
TO_NUMBER(
RAWTOHEX(UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(LPAD(SUBSTR(ROWID, 16, 3), 4, 'A')))),
'XXXXXXXXXX'
) AS block_number,
-- 行槽号（最后 4 字符，通常为 AAxx 形式）
SUBSTR(ROWID, -4) AS row_slot_base64,
-- 解码行槽号（示例：'AAB' → 实际 slot=1）
TO_NUMBER(
RAWTOHEX(UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(LPAD(SUBSTR(ROWID, -4, 3), 4, 'A')))),
'XXXX'
) AS slot_number,
id, name
FROM your_table_name
WHERE id = 123456;? 注意事项：
- Base64 解码前必须确保输入长度合法（4 的倍数），Oracle 的 ROWID 长度固定（18 字符），但自定义截取时需用 LPAD(..., 4, 'A') 补齐；
- UTL_ENCODE.BASE64_DECODE 返回 RAW 类型，后续需结合 RAWTOHEX、TO_NUMBER(..., 'XXXXXX') 等函数进一步解析；
- 生产环境切勿依赖 ROWID 长期存储——因表移动（如 ALTER TABLE ... MOVE）、分区维护或段压缩会导致 ROWID 变更；
- 若需持久化定位某行，应使用业务主键（如 ID）或创建 ROWID + 时间戳的映射快照。
总结：Oracle ROWID 的 Base64 表达是其官方设计规范，理解其编码本质比强行转 Hex 更重要。掌握 UTL_ENCODE.BASE64_DECODE 与 UTL_RAW 工具链，即可安全提取文件、块、槽等物理位置信息，支撑高级诊断（如 I/O 热点分析）或迁移校验场景。
