Oracle 11g无原生JSON支持，需依赖PL/JSON包（纯PL/SQL、免Java、GitHub开源）或Java方案（loadjava导入org.json.jar），但后者受限于权限、字符集与兼容性；手写字符串解析函数仅适用于无嵌套、无特殊字符的极简场景，生产环境不可靠。
JSON_VALUE 或 IS JSON，它们在 12c 才出现。
用 PL/JSON 第三方包是最靠谱的起点
PL/JSON 是纯 PL/SQL 实现、无需 Java、兼容 11g 的成熟方案（GitHub 地址：https://github.com/pljson/pljson）。它提供 pljson、pljson_list、pljson_ext 等类型和工具函数，能 parse、get、put、to_clob。
- 安装只需运行
pljson.sql脚本（含 type、package、body），无额外依赖 - 对简单对象：用
pljson(jstr).get('key').get_string()；对数组：用pljson_list(jstr)+get(i)循环 - 注意：
pljson_ext.get_number()对 ".123" 这类 Oracle 自动省略前导零的小数会报错（ORA-20100），需先用TO_CHAR(x, 'FM999999999.000000')格式化再转 JSON - 避免直接拼接 JSON 字符串——用
pljson().put('k', v)构建，防止引号/转义出错
自己写字符串解析函数？只适合极简场景
网上流传的 instr+substr 提取 key-value 的函数（如 F_GET_FRO_JSON）仅适用于扁平、无嵌套、无引号内逗号/冒号的 JSON。一旦遇到 {"msg":"a,b:c"} 或 {"items":[{"id":1}]}，立刻失效。
- 这类函数本质是“按固定分隔符切片”，不是 JSON 解析器，连合法性和编码都不校验
-
REPLACE去双引号、TRIM空格等操作会破坏带引号的原始值（比如值本身含"） - 无法处理空值、布尔、嵌套对象或数组，也不支持 Unicode 字符（AL32UTF8 下易截断）
- 若只是读 CLOB 中单层 key，且数据来源可控（如固定格式日志），可临时应急；否则别投入生产
Java 存储过程可行但运维成本高
通过 loadjava 导入 org.json.jar，再创建 JsonUtil Java Source 调用，理论上能处理任意复杂度 JSON。但 11g 的 Java 支持老旧，实际踩坑密集：
-
loadjava -r -f -u user/pass@db json.jar前必须确认 jar 无依赖（fastjson、jackson必然失败；org.json可行但类多、加载慢） - 数据库用户需被授予
java.io.FilePermission等权限，DBA 通常限制严格 - Java Source 编译失败常见于字符集（建议用 UTF-8 保存 .java 文件）、JDK 版本（11g 默认 JRE 1.4.2，不支持泛型/注解）
- 调用时传参长度受限（
VARCHAR2最大 4000 字节），CLOB 需额外转换，且异常堆栈难调试
别忽略数据源头的改造机会
真正省事的做法，往往不是“在 11g 里硬解 JSON”，而是推动上游改输出格式：
- 如果 JSON 来自 Web API，要求对方提供 XML 或 CSV 备选格式——Oracle 11g 的
XMLTYPE和UTL_FILE更稳定 - 若由应用层生成 JSON，改用结构化 INSERT（如拆成主表+明细表），避免把 JSON 当字段存
- 临时中转用外部脚本：Python/Node.js 接口响应 → 解析 → 写入 Oracle 表，比在 DB 内硬扛更可控
- 升级数据库仍是终极解法：12cR1（2013）起支持
JSON_EXISTS，19c 支持完整路径查询和JSON_TABLE；迁移成本常低于长期维护自定义解析逻辑
sql_to_json 对小数格式敏感、不支持流式解析大 CLOB；Java 方案理论上最强，却卡在权限和兼容性上；而手写字符串函数，看着短，其实最危险——它把“解析失败”悄悄变成“返回错误值”，线上排查时根本看不出问题。 
