Python解析不规则JSON的通用方案

在实际工程中，我们拿到的“JSON”往往并不符合 RFC 8259 规范。它可能来自日志拼接、人工编辑的配置文件、爬虫抓取的页面片段，或者上游系统拼接字符串时留下的尾巴。面对这类数据，很多开发者第一反应是找一款“宽容修复”库，把脏数据强行塞进 json.loads。但宽松修复是一把双刃剑：它在提高解析成功率的同时，也可能悄悄改变数据语义。本文从实际踩坑出发，梳理不规则 JSON 的常见来源，并给出更可控的解析策略。

一、宽松修复库的典型风险

市面上一些高赞的 JSON 修复方案，核心思路是“尽最大努力猜出结构”。这种做法在演示场景下效果惊艳，但在对数据准确性有要求的场景中，会暴露出一系列问题。以下列举几类典型行为，它们并非某一款库独有，而是宽松修复策略的共性风险。

1. 类型语义被改写

Python 中的 None 与 JSON 中的 null 语义接近，但并非同一套字面量。某些修复库会把 {"a": None} 中的 None 直接转成字符串 "None"，而不是 null。对于下游依赖类型判断的逻辑，这会导致字段从“空值”变成“非空字符串”，引发连锁错误。

2. 输出仍不是严格 JSON

NaN、Infinity、-Infinity 在 Python 的 json 模块中默认可以解析，但官方文档明确说明这超出了 JSON 规范。如果修复库输出中保留了这些字面量，那么“修复后的结果”依然无法被严格 JSON 解析器接受，跨语言传输时同样会出问题。

3. 表达式被静默截断

{"a": 1+2, "b": 3} 这类输入，部分修复库会把 1+2 截断成 1，并且不报错。对于配置或计算表达式场景，这相当于篡改了数据，且没有任何告警信号。

4. 结构问题未被拦截

重复 key 在严格模式下应当被视为结构错误。但有些库即使开启 strict 模式，也不会对 {"a": 1, "a": 2} 抛出异常，而是默默保留后者。这与文档承诺不符，容易让开发者误以为数据已经过校验。

5. 尾部垃圾被丢弃

{"a": 1} some text 这种输入，尾部文本会被直接忽略。对日志解析而言，尾部内容有时恰恰是关键证据，静默丢弃会掩盖问题。

6. 过度猜测结构

{foo [bar 这类严重损坏的输入，可能被猜成一个数组。这种“创造性修复”在排障时极具误导性。

小结：宽松修复库适合“只要不报错就行”的场景；一旦数据要参与计算、审计或跨系统传输，就必须谨慎评估其副作用。

二、不规则 JSON 的主要来源

与其盲目修复，不如先分类。工程中常见的不规则 JSON 大致有三类，每类都有更合适的处理方式。

1. 合法 JSON + 前后缀

典型形态是 prefix {"a":1} suffix，例如从 HTML 或日志行中截取出的对象。JSON 本身是合法的，问题只在于如何定位有效载荷。

2. JSON5 / JS 对象风格

包括单引号字符串、注释、尾逗号、未加引号的 key。这类数据常见于前端代码片段或爬虫抓取的脚本内容，属于“有意为之的扩展语法”，而非损坏。

3. 配置文件风格

某些配置格式支持省略逗号、注释、无引号 key 和无引号字符串，整体比 JSON5 更自由，更接近手写配置的习惯。

把这三类分开处理，远比用一款“万能修复”库更可靠。

三、前后缀场景：精准提取而非猜测

如果 JSON 是合法的，只是被前后缀包裹，最稳妥的方式是定位并提取，而不是让修复库去猜。

1. 使用 raw_decode 定位

Python 标准库的 json.JSONDecoder 提供了 raw_decode，可以从字符串任意位置开始解析，并返回结束位置。

import json
def extract_first_json(text):
    decoder = json.JSONDecoder()
    # 从左到右扫描，找到第一个可以成功解析的位置
    for i, ch in enumerate(text):
        if ch in "{[":
            try:
                obj, end = decoder.raw_decode(text[i:])
                return obj, i + end
            except json.JSONDecodeError:
                continue
    raise ValueError("no valid JSON found")

这种方式只接受合法 JSON，不会篡改内容。解析失败就继续往后找，找不到就报错，语义清晰。

2. 括号匹配做预筛

对于大文本，逐字符尝试 raw_decode 可能较慢。可以先做一次括号匹配，定位候选区间，再对候选区间做严格解析。

def find_balanced(text, start):
    stack = []
    pairs = {"}": "{", "]": "["}
    in_str = False
    escape = False
    for i in range(start, len(text)):
        ch = text[i]
        if in_str:
            if escape:
                escape = False
            elif ch == "\\":
                escape = True
            elif ch == '"':
                in_str = False
            continue
        if ch == '"':
            in_str = True
        elif ch in "{[":
            stack.append(ch)
        elif ch in "}]":
            if not stack or stack[-1] != pairs[ch]:
                return None
            stack.pop()
            if not stack:
                return i
    return None

括号匹配只负责定位，不负责解释内容，职责单一，便于测试。

3. 多段 JSON 的处理

如果一行里有多段 JSON，可以用 raw_decode 循环提取，配合 end 位置继续向后扫描。这样既不丢数据，也不过度猜测。

四、JSON5 风格：用专用解析器而非修复

JSON5 明确支持单引号、注释、尾逗号、无引号 key 等特性，这些是规范内的扩展，而非“损坏”。因此正确的做法是使用支持 JSON5 的解析器，而不是让 JSON 修复库去猜。

以某类通用解析能力为例，思路如下：

# 伪代码示意，实际请选用合规的 JSON5 解析实现
# import json5
# obj = json5.loads(text)

使用专用解析器的好处是：

• 语义明确：哪些语法被支持，文档写得清清楚楚；
• 行为可预期：不会出现“把表达式截断”这类副作用；
• 错误可定位：解析失败时会给出行列号，便于排障。

对于爬虫场景，如果确认目标是 JSON5，就应当在解析层明确区分“标准 JSON 解析”和“JSON5 解析”，而不是统一走修复通道。

五、配置文件风格：先规范化再解析

配置文件风格比 JSON5 更自由，可能省略逗号、允许无引号字符串。面对这类数据，建议先做一次规范化转换，再交给标准解析器。

1. 规范化步骤

1. 去除注释行；
2. 为无引号 key 补上双引号；
3. 为无引号字符串值补上双引号；
4. 补齐缺失的逗号；
5. 交给 json.loads 严格解析。

2. 为什么不建议直接上修复库

规范化是显式规则，每一步都可审计；而修复库是隐式猜测，出错时难以定位。对于配置文件这种需要长期维护的数据，可审计性比“能跑就行”更重要。

六、严格校验与降级策略

无论走哪条路径，都建议遵循“先严格、后降级”的原则。

1. 严格解析优先

先用标准 json.loads 尝试解析。成功即返回，失败再进入降级流程。这样可以确保绝大多数正常数据走最可信的通道。

2. 显式降级

降级策略应当分级，且每一级都要有明确日志：

• 一级降级：前后缀提取 + 严格解析；
• 二级降级：JSON5 解析；
• 三级降级：规范化后严格解析；
• 四级降级：记录原始数据，转入人工审核队列。

3. 拒绝静默修复

对于“表达式截断”“尾部丢弃”“结构猜测”这类行为，应当默认关闭。如果业务确实需要，必须显式开启并记录审计日志，明确告知下游数据可能已被修改。

七、实践建议清单

1. 先分类，再解析：区分前后缀、JSON5、配置风格三类来源，分别处理。
2. 优先标准库：json.JSONDecoder().raw_decode() 能解决大部分前后缀问题。
3. 专用语法用专用解析器：JSON5 就用 JSON5 解析器，不要混用修复库。
4. 规范化可审计：配置文件风格的转换规则要显式、可测试。
5. 严格模式兜底：生产环境始终保留严格校验通道，异常数据进审核队列。
6. 拒绝静默篡改：任何改变数据语义的修复行为，都必须有日志和告警。

结语

不规则 JSON 的解析，本质上是“数据清洗”问题，而不是“字符串修复”问题。宽松修复库在特定场景下确实能省事，但它模糊了“解析成功”与“数据正确”之间的边界。通过分类处理、严格优先、显式降级，我们可以在提高解析成功率的同时，守住数据可信度这条底线。对于需要长期运行、跨系统协作的工程而言，可控性永远比“能跑”更重要。