jc 解析 /proc/net/igmp：Linux IGMP 组播组状态文件的结构化 JSON 转换指南

• 开发工具

本指南围绕 jc 项目内置的proc_net_igmp解析器展开，讲解如何将 Linux 内核的/proc/net/igmp组播组状态文件转换为结构化的 JSON 数组，涵盖 CLI 与 Python 模块两种调用方式、完整输出 Schema、raw原始模式与-p美化输出的差异，并从源码实现层面剖析该解析器的逐行解析逻辑与数据加工流程。读完本文，你将掌握用 jc 一键读取 IGMP 组成员、查询接口上的组播组数量与版本（V2/V3）的实战方法，并能将其接入 jq 等下游工具实现自动化监控与脚本化处理。

一、背景：/proc/net/igmp是什么

/proc/net/igmp是 Linux 内核虚拟文件系统提供的只读接口，记录系统中各网络接口上已加入的 IGMP（Internet Group Management Protocol）组播组状态。其原始内容为制表符分隔的文本表，形如：

Idx Device : Count Querier Group Users Timer Reporter 0 lo : 0 V3 010000E0 1 0:00000000 0 2 eth0 : 26 V2 260301E0 1 0:00000000 1 ...

每行字段含义如下：

• Idx：接口索引号；
• Device：接口名称（如lo、eth0）；
• Count：该接口上记录的组播组成员数量；
• Querier：IGMP 查询器版本（如V2、V3）；
• 缩进的成员行包含Group（组播地址）、Users（使用者数量）、Timer（定时器状态）、Reporter（报告者标志）。

这类文本格式对脚本来说难以直接消费。jc 的proc_net_igmp解析器（源码）正是为此设计：把这份表格转换为标准的 JSON 数组，从而可以直接管道给jq等工具。

二、CLI 用法：三种等价调用方式

原文档给出了三种命令行调用方式，均指向同一个解析器：

$ cat /proc/net/igmp | jc --proc

或直接传入文件路径：

$ jc /proc/net/igmp

或使用该解析器的专用选项：

$ cat /proc/net/igmp | jc --proc-net-igmp

三种方式输出结果一致。其中--proc是通用选项，jc 会依据输入内容自动匹配对应的proc_*子解析器；--proc-net-igmp则直接锁定本解析器。这种自动路由机制可以在 proc.py 的解析器映射表中看到，proc_net_igmp与proc_net_igmp6均挂载在--proc分发逻辑下。

配合-p参数可以输出美化（pretty）后的 JSON，配合-r参数则输出原始（raw）未加工数据，详见下文示例。

三、Python 模块用法

在 Python 脚本中，可以通过 jc 的通用parse接口解析该文件内容：

import jc result = jc.parse('proc', proc_net_igmp_file)

或者直接调用专用解析器名称：

import jc result = jc.parse('proc_net_igmp', proc_net_igmp_file)

其中proc_net_igmp_file为读取到的文件内容字符串。返回值是「字典列表」（List of Dict），即与下文 Schema 对应的结构化数据。

parse 函数签名

原文档同时公开了底层parse函数的签名：

def parse(data: str, raw: bool = False, quiet: bool = False) -> List[Dict]

参数说明：

返回值：字典列表，即加工后（或原始）的结构化数据。

四、输出 Schema：字段结构与类型约定

解析后的 JSON 数组遵循如下 Schema（原文档完整继承）：

[ { "index": integer, "device": string, "count": integer, "querier": string, "groups": [ { "address": string, "users": integer, "timer": string, "reporter": integer } ] } ]

顶层每个对象对应一个网络接口；嵌套的groups数组对应该接口下缩进排列的每个组播组成员记录：

• index：接口索引（整型）；
• device：接口名称（字符串，如lo、eth0）；
• count：组成员数量（整型）；
• querier：查询器 IGMP 版本（字符串，如V3、V2）；
• groups[].address：组播地址（字符串，内核以十六进制小端序形式输出，如010000E0，其对应的点分十进制组播地址为224.0.0.1这一类）；
• groups[].users：该组成员的使用者数量（整型）；
• groups[].timer：内核维护的组成员定时器状态（字符串，格式如0:00000000）；
• groups[].reporter：是否为该组播组的报告者（整型，0或1）。

五、完整示例：加工输出与原始输出对比

加工后的美化输出（-p）

$ cat /proc/net/igmp | jc --proc -p [ { "index": 0, "device": "lo", "count": 0, "querier": "V3", "groups": [ { "address": "010000E0", "users": 1, "timer": "0:00000000", "reporter": 0 } ] }, { "index": 2, "device": "eth0", "count": 26, "querier": "V2", "groups": [ { "address": "260301E0", "users": 1, "timer": "0:00000000", "reporter": 1 }, { "address": "9B0101E0", "users": 1, "timer": "0:00000000", "reporter": 1 } ] } ... ]

原始输出（-p -r）

$ cat /proc/net/igmp | jc --proc-net-igmp -p -r [ { "index": "0", "device": "lo", "count": "0", "querier": "V3", "groups": [ { "address": "010000E0", "users": "1", "timer": "0:00000000", "reporter": "0" } ] }, { "index": "2", "device": "eth0", "count": "26", "querier": "V2", "groups": [ { "address": "260301E0", "users": "1", "timer": "0:00000000", "reporter": "1" }, { "address": "9B0101E0", "users": "1", "timer": "0:00000000", "reporter": "1" } ] } ... ]

对比两组输出可以看出：-r模式下所有字段保持为字符串（如"index": "0"），而默认加工模式下index、count、users、reporter均被转换为整型，device、querier、address、timer保持字符串类型，与 Schema 完全一致。

六、源码级实现原理：逐行解析与类型加工

1. 主解析流程（parse）

parse函数的解析核心位于 jc/parsers/proc_net_igmp.py，其流程如下：

1. 调用jc.utils.compatibility()检查运行平台（该解析器compatible = ['linux']），并用jc.utils.input_type_check(data)校验输入类型；
2. 通过jc.utils.has_data(data)判断输入是否为空——测试用例test_proc_net_igmp_nodata验证了空输入返回[]的行为（见 tests/test_proc_net_igmp.py）；
3. 跳过首行表头（data.splitlines()[1:]），并过滤空行（filter(None, ...)）；
4. 对每一行，以「是否以制表符\t开头」区分两类记录：
   • 不以\t开头：接口头记录，line.split()解包为index, device, _, count, querier（中间的_丢弃:分隔符），构造接口对象；
   • 以\t开头：组成员记录，line.split()解包为address, users, timer, reporter，追加进当前接口的groups列表；
5. 遇到下一条接口头记录时，把已累积的groups挂到上一个接口对象上并写入raw_output；
6. 遍历结束后将最后一个接口（含其groups）追加进结果；
7. 若raw=True直接返回raw_output，否则交给_process加工。

从实现细节可以看出，该解析器是基于行首制表符缩进的结构化解析，这正是/proc/net/igmp中「接口记录 + 缩进成员记录」两种行类型的可靠区分依据。

2. 类型加工流程（_process）

_process函数（jc/parsers/proc_net_igmp.py）定义了整型字段集合：

int_list = {'index', 'count', 'users', 'reporter'}

随后对每个接口对象及其嵌套的每个groups元素，凡是键名落在int_list中的字段，一律执行int(val)转换为整型。这解释了上文「加工输出与原始输出的类型差异」：四个数字型字段在默认模式下全部由字符串转换为 Pythonint，再序列化为 JSON 数值。

七、测试与真实数据验证

仓库内置了两组针对本解析器的测试夹具，可直接用于验证解析行为：

• tests/fixtures/linux-proc/net_igmp：包含lo与ens33两个接口、各 1 个组播组的简单场景；
• tests/fixtures/linux-proc/net_igmp_more：包含lo、eth0（26 个组播组）、eth1（5 个组播组）的多接口、多组播组复杂场景，其中eth0的成员行以制表符缩进排列，恰好覆盖了解析器「切换接口时归档 groups」的分支逻辑。

对应的期望 JSON 文件（net_igmp.json、net_igmp_more.json）与解析结果逐字段一致。测试用例 test_proc_net_igmp.py 通过parse(..., quiet=True)对两组夹具断言，可作为理解解析器行为的可运行样例，也可以直接执行python -m unittest tests.test_proc_net_igmp复现验证。

八、相关解析器与进阶使用

• IPv6 版本：内核同时提供/proc/net/igmp6，jc 内置了对应的proc_net_igmp6解析器，其文档见 docs/parsers/proc_net_igmp6.md，源码见 jc/parsers/proc_net_igmp6.py。两者在--proc分发中并列挂载（见 jc/parsers/proc.py）；
• 与 jq 组合：将输出管道给 jq 即可按接口统计组播组数量、筛选特定组播地址等，例如筛选所有reporter为 1 的组成员：

  cat /proc/net/igmp | jc --proc | jq '[.[].groups[] | select(.reporter == 1)]'

• 兼容性与元数据：本解析器compatible = ['linux']，即仅面向 Linux 平台（/proc/net/igmp为 Linux 专有接口）；同时hidden = True表明它在 jc 帮助信息中不单独列出，只能通过--proc自动路由或显式--proc-net-igmp调用（见 jc/parsers/proc_net_igmp.py 的info类）。

小结

/proc/net/igmp的文本表格在 jc 的proc_net_igmp解析器作用下，可以在一个命令内完成结构化转换：CLI 侧支持--proc自动路由、--proc-net-igmp精确指定与文件路径直传三种方式，模块侧支持jc.parse('proc', ...)与jc.parse('proc_net_igmp', ...)两种入口；输出 Schema 中接口级字段与嵌套groups成员字段类型清晰，-r与默认模式分别对应字符串与整型两种形态。结合仓库内的测试夹具与源码解析逻辑，读者既能直接上手使用，也能深入理解其「制表符缩进 + 字段解包 + 类型加工」的实现原理，为在监控脚本中消费 IGMP 组播状态数据提供了可靠方案。

• 开发工具