在处理包含已编码JSON字符串的字典时，直接对外部字典进行JSON序列化会导致内部字符串的引号被二次转义。本文将深入探讨这一常见问题，解释其发生机制，并提供一种清晰的两步解码策略，确保消费者能够正确解析嵌套的JSON数据，尤其适用于消息队列中payload字段被定义为字符串的场景。
理解JSON序列化中的嵌套字符串问题
在数据传输和存储中，我们经常需要将复杂的数据结构序列化为JSON字符串。一个常见场景是，一个字典中的某个字段本身包含一个已经编码好的JSON字符串。当尝试将这个外部字典再次序列化时，就会遇到内部JSON字符串被“二次转义”的问题。
考虑以下场景：我们有一个消息体 message，它是一个Python字典，需要根据Avro schema将其序列化为JSON字符串。
import jsonfrom datetime import datetimefrom io import StringIOimport fastavro# 原始消息字典message = { "name": "any", "ingestion_ts": datetime.utcnow(), "values": { "amount": 5, "countries": ["se", "nl"], "source": { "name": "web", "url": "whatever" } }}# 假设 avro_schema 已定义avro_schema = { "type": "record", "name": "MyMessage", "fields": [ {"name": "name", "type": "string"}, {"name": "ingestion_ts", "type": {"type": "long", "logicalType": "timestamp-micros"}}, {"name": "values", "type": { "type": "record", "name": "Values", "fields": [ {"name": "amount", "type": "int"}, {"name": "countries", "type": {"type": "array", "items": "string"}}, {"name": "source", "type": { "type": "record", "name": "Source", "fields": [ {"name": "name", "type": "string"}, {"name": "url", "type": "string"} ] }} ] }} ]}# 使用 fastavro 将 message 序列化为 JSON 字符串fo = StringIO()fastavro.json_writer(fo, avro_schema, [message])message_str = fo.getvalue()print(f"内部 JSON 字符串: {message_str}")# 示例输出: '{"name": "any", "ingestion_ts": 1703192665965373, "values": {"amount": 5, "countries": ["se", "nl"], "source": {"name": "web", "url": "whatever"}}}'
现在，这个 message_str 需要被包装到一个更大的字典 wrap 中，作为其 payload 字段的值，然后发送到消息队列。消息队列期望的外部Schema如下：
{ "type": "record", "namespace": "CDCEvent", "name": "CDCEvent", "fields": [ {"doc": "The system that generated the event", "type": "string", "name": "sys"}, {"doc": "The operation performed on the event", "type": "string", "name": "op"}, {"doc": "The content of the event", "type": "string", "name": "payload"} ]}
注意，payload 字段的类型被定义为 string。这意味着 payload 字段的值在外部JSON中必须是一个普通的字符串。
如果我们直接将 message_str 赋值给 wrap 字典的 payload 字段，并再次使用 json.dumps 进行序列化：
wrap = { "sys": "my_system", "op": "c", "payload": message_str}wrap_str = json.dumps(wrap)print(f"二次序列化后的 JSON 字符串: {wrap_str}")# 示例输出: '{"sys": "my_system", "op": "c", "payload": "{"name": "any", "ingestion_ts": 1703192665965373, "values": {"amount": 5, "countries": ["se", "nl"], "source": {"name": "web", "url": "whatever"}}}"}'
可以看到，payload 字段中的双引号都被反斜杠 转义了。这是因为 json.dumps 在处理 wrap 字典时，将 message_str 视为一个普通的Python字符串值。为了确保生成的外部JSON字符串是合法的，它必须对 message_str 内部的所有特殊字符（如双引号）进行转义。这并非错误，而是 json.dumps 按照JSON规范正确地序列化一个包含字符串值的字段。
Find JSON Path Online
Easily find JSON paths within JSON objects using our intuitive Json Path Finder
30 查看详情
消费者端的正确解析策略
问题的核心不在于生产者端的“二次编码”错误，而在于消费者端如何正确地“二次解码”。如果消费者直接尝试将 wrap_str 整体作为一个JSON对象进行单次解析，并期望 payload 字段的值是一个可以直接使用的JSON对象，那么就会失败，因为它得到的是一个包含转义字符的字符串。
正确的解析方法是采用两步解码策略：
解析外部JSON字符串： 首先，将接收到的 wrap_str 使用 json.loads() 解析成一个Python字典 wrapped_object。解析内部JSON字符串： 从 wrapped_object 中取出 payload 字段的值，这个值现在是一个普通的Python字符串，其中包含了原始的JSON数据（没有转义）。然后，再对这个 payload 字符串进行一次JSON解析。
以下是消费者端的示例代码：
# 假设消费者接收到 wrap_strreceived_wrap_str = '{"sys": "my_system", "op": "c", "payload": "{"name": "any", "ingestion_ts": 1703192665965373, "values": {"amount": 5, "countries": ["se", "nl"], "source": {"name": "web", "url": "whatever"}}}"}'# 第一步：解析外部 JSONwrapped_object = json.loads(received_wrap_str)print(f"第一步解析结果 (Python 字典): {wrapped_object}")# 此时 wrapped_object['payload'] 的值是一个不含转义符的字符串：# '{"name": "any", "ingestion_ts": 1703192665965373, "values": {"amount": 5, "countries": ["se", "nl"], "source": {"name": "web", "url": "whatever"}}}'# 第二步：解析 payload 字段中的内部 JSON 字符串payload_json_str = wrapped_object["payload"]print(f"从 payload 字段中取出的 JSON 字符串: {payload_json_str}")# 根据原始内部 Avro Schema 进行解析# 注意：这里需要再次提供内部消息的 avro_schemainner_message_stream = StringIO(payload_json_str)decoded_messages = []for record in fastavro.json_reader(inner_message_stream, avro_schema): decoded_messages.append(record)print(f"第二步解析结果 (原始消息列表): {decoded_messages}")# 示例输出: [{'name': 'any', 'ingestion_ts': 1703192665965373, 'values': {'amount': 5, 'countries': ['se', 'nl'], 'source': {'name': 'web', 'url': 'whatever'}}}]
通过这种两步解析方法，消费者能够成功地从 wrap_str 中提取出原始的 message 数据。
注意事项与最佳实践
Schema一致性： 这种方法依赖于 payload 字段在外部Schema中被明确定义为 string 类型。如果外部Schema允许 payload 是一个JSON对象，那么在生产者端就应该直接将原始字典 message 赋值给 payload，而不是先将其序列化为字符串。
# 如果外部 Schema 允许 payload 是一个 JSON 对象# 那么生产者端可以直接这样处理，避免预先序列化# wrap = {# "sys": "my_system",# "op": "c",# "payload": message # 直接放置字典，而不是字符串# }# wrap_str = json.dumps(wrap) # json.dumps 会自动处理嵌套字典
在这种情况下，消费者端只需要一步 json.loads(wrap_str) 即可。
性能考量： 两次JSON解析会带来一定的性能开销。在对性能要求极高的场景下，如果设计允许，尽量避免这种嵌套字符串的设计。清晰的文档： 务必在系统设计文档中明确指出 payload 字段的特殊性，以及消费者需要执行两步解析的流程，以避免混淆和错误。错误处理： 在实际应用中，解析 payload_json_str 时应加入 try-except 块来处理可能的 json.JSONDecodeError，以应对 payload 内容不符合JSON格式的情况。
总结
当一个字典的字段被明确要求存储一个已经编码的JSON字符串时，对其进行外部JSON序列化是会产生内部引号转义的。这并非错误，而是标准JSON序列化行为。解决之道在于消费者端采用两步解码策略：首先解析外部JSON以获取包含内部JSON字符串的字段值，然后再次解析该字符串以恢复原始数据。理解这一机制对于构建健壮的数据处理管道至关重要。
以上就是处理嵌套JSON字符串的正确姿势：避免二次转义与多层解析的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/569404.html
微信扫一扫 
支付宝扫一扫 
