rs.getobject("col", string.class)是唯一安全读取方式，因oracle 19c原生json列为独立sql类型，需ojdbc8u3+驱动显式协议支持，否则getstring()会抛异常或返回二进制乱码。
Oracle 19c+ 的原生 JSON 列类型不是“存字符串的 VARCHAR2”，直接用 rs.getString("col") 会失败或返回二进制乱码；必须配合 JDBC 驱动的协议级支持，才能拿到标准 JSON 字符串——这是绝大多数 Java 开发者踩坑的第一步。
为什么 rs.getString("j") 在 Oracle 19c 上抛异常或返回 0x7B2261223A317D？
根本原因不是字符集或数据库配置，而是 Oracle JDBC 驱动（ojdbc8 ≥ 19.19）将原生 JSON 类型视为独立 SQL 类型，不自动转为字符串。调用 getString() 会触发底层类型转换失败，报错类似：SQLException: cannot convert to string；或 fallback 到二进制 blob 表示（如 0x7B2261223A317D），解码后是乱码。
这不是 bug，是 JDBC 规范对扩展类型（SQLType.JSON、SQLType.XML）的明确要求：必须显式声明目标类型，不能靠驱动猜。
-
rs.getObject("j", String.class)✅ 是唯一被 ojdbc8u3+ 原生支持的正确方式 -
rs.getNString("j")❌ 不适用，JSON 列不是 NCHAR/NVARCHAR -
rs.getClob("j")❌ 返回空或异常，CLOB 是存储类型，不是协议类型 -
rs.getObject("j")❌ 返回oracle.sql.json.OracleJsonStructure，不能直接 toString() 或强转
如何安全读取 JSON 列并交给 Jackson 解析？
拿到字符串后，才是 JSON 库的事。重点在于：不要跳过 JDBC 层的类型声明，也不要试图在 JDBC 层做解析。
- 先确保使用
ojdbc8-19.19.0.0.jar或更高版本（旧版连SQLType.JSON常量都没有） - 用
rs.getObject("j", String.class)获取原始 JSON 字符串，字段为 NULL 时返回null，不是空字符串 - 传给 Jackson：
mapper.readValue(jsonStr, MyPojo.class)，注意处理null边界 - 避免用
rs.getObject("j", JsonObject.class)—— 驱动不支持，直接抛SQLFeatureNotSupportedException
示例片段：
String jsonStr = rs.getObject("payload", String.class);
if (jsonStr != null) {
MyOrder order = mapper.readValue(jsonStr, MyOrder.class);
}
什么时候该用 JSON_VALUE 而不是 JDBC 读取整列？
当只需要 JSON 中某个字段（比如 $.user.id），且该字段类型简单（数字、字符串），就别把整个 JSON 拉到 Java 内存里再解析——服务端提取更高效、网络开销更低。
- SQL 示例：
SELECT JSON_VALUE(data, '$.user.email') AS email FROM orders - 对应 JDBC：
rs.getString("email")就能直接拿到字符串值 - 注意：
JSON_VALUE返回的是标量，不是 JSON 片段；要取子对象用JSON_QUERY - 这些函数是 Oracle 数据库服务端能力，与 JDBC 驱动版本无关（只要数据库 ≥ 12c）
- 所谓 “OracleJsonValue 驱动” 不存在，纯属混淆 SQL 函数和 JDBC 协议
真正容易被忽略的点是：JDBC 层的类型协议（getObject(col, String.class)）和服务端函数（JSON_VALUE）是两条完全正交的路径，选哪条取决于你是否需要完整 JSON 结构。一旦选错，要么拿不到数据，要么扛不住高并发下的内存压力——尤其是 Kafka 消费者每秒处理上千条含 JSON 的记录时，少一次无谓的字符串拷贝，就能省下可观的 GC 时间。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
