Oracle 的 ROWID 是内部使用的物理地址标识符，以 Base64 编码字符串形式返回（如 `AABRFrAAEAADnz2AAB`），并非十六进制；其本质是二进制结构的紧凑编码，不可直接转为 Hex，但可通过 UTL_ENCODE 等函数解码还原物理组成。
在 Oracle 数据库中，ROWID 是一个伪列（pseudocolumn），用于唯一标识表中每一行的物理存储位置。它不是用户定义的数据类型，也不以十六进制字符串形式存储或展示——而是 Oracle 内部采用紧凑的二进制格式表示（含数据对象号、文件号、块号、行号等信息），并在 SQL 查询结果中自动以 Base64 编码的可读字符串形式呈现（例如 *BB170egLyghDYQwXPUdQY1b+ 或更常见的 AABRFrAAEAADnz2AAB）。这正是你看到“特殊字符”的根本原因：它不是乱码，而是标准 Base64 编码（使用 A–Z, a–z, 0–9, +, /，并以 = 补位）。
⚠️ 注意：
- ROWID 的 Base64 字符串 不能通过简单 HEX 转换还原（如 DatatypeConverter.printHexBinary(...) 失败正是因为 ROWID.getBytes() 返回的是 UTF-8 编码后的字节，而非原始二进制结构）；
- 直接对 ROWID 字符串调用 UTL_RAW.CAST_TO_RAW 会将其视为文本，导致后续 Base64 解码失败；正确做法是先 Base64 解码，再按 Oracle ROWID 二进制布局解析字段。
✅ 正确解析示例（SQL 层）：
SELECT
ROWID AS rowid_base64,
-- 完整解码为原始 RAW（可用于进一步分析）
UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(ROWID)) AS rowid_raw,
-- 提取并解码块号（Block Number）：通常位于 ROWID 第16–18位（扩展 ROWID 格式）
UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(LPAD(SUBSTR(ROWID, 16, 3), 4, 'A'))) AS block_raw,
-- 将块号 RAW 转为十进制数值（注意格式掩码 'XXXXXX' 需匹配实际字节数）
TO_NUMBER(
RAWTOHEX(UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(LPAD(SUBSTR(ROWID, 16, 3), 4, 'A')))),
'XXXXXXXX'
) AS block_number,
-- 行槽号（Row Slot）通常由最后3位 Base64 字符隐含，可类似解析
DUMP(ROWID, 16) AS rowid_dump -- 辅助调试：查看 ROWID 内部十六进制字节表示
FROM your_table_name
WHERE id = 123456;? 关键说明：
- Oracle 扩展 ROWID（18 字符）结构为：OOOOOOFFFBBBBBBRRR（O=对象号，F=文件号，B=块号，R=行号），但 Base64 编码后已打乱字节顺序，需严格按 Oracle 文档定义的偏移和长度提取；
- UTL_ENCODE.BASE64_DECODE 接收 RAW 输入，因此必须先用 UTL_RAW.CAST_TO_RAW(ROWID) 将字符串转为 RAW（即 UTF-8 字节流），再解码——这是多数误用的根源；
- 若需在 Java/JDBC 中处理，应使用 ResultSet.getRowId().toString() 获取 Base64 字符串，再通过 Base64.getDecoder().decode() 解码为 byte[]，而非 rs.getRowId(1).getBytes()（该方法返回的是字符串 UTF-8 字节，非原始 ROWID 二进制）。
? 总结：ROWID 的“特殊字符”是 Base64 编码的必然表现，反映其底层二进制物理地址的本质。理解其编码逻辑，善用 UTL_ENCODE.BASE64_DECODE + UTL_RAW.CAST_TO_RAW 组合，才能安全、准确地解析和利用 ROWID 信息。切勿尝试十六进制强制转换——那只会得到无意义的字节映射。
