开发工具【免费下载链接】jcCLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.项目地址https://gitcode.com/gh_mirrors/jc/jc点击查看免费下载本文围绕jc仓库中的proc_loadavg解析器文档展开讲清 Linux 系统负载文件/proc/loadavg如何被jc转换为结构化 JSON 的完整链路三种 CLI 调用方式、Python 模块 API、输出 Schema 与字段类型并结合 源码实现 剖析parse()的解析流程、类型转换逻辑以及--proc分发器如何靠签名正则自动识别该文件。读完后你可以直接在监控脚本或自动化环境中用jc或jq消费负载平均值数据。/proc/loadavg 输入格式与解析器定位/proc/loadavg是 Linux 内核暴露在 procfs 中的单行文件内容形如0.00 0.01 0.03 2/111 2039五个字段依次为1 分钟、5 分钟、15 分钟平均负载运行中任务数/调度队列中任务总数以及最近分配的 PID。jc仓库中针对该文件的解析器为jc.parsers.proc_loadavg其解析器元数据源码见 info 类声明了Version:1.0作者 Kelly BrazilCompatibility:[linux]—— 仅在 Linux 平台可正常运行parse()入口会先调用jc.utils.compatibility()做平台校验Tags:[file]Hidden: 源码中info.hidden True即该解析器被标记为隐藏解析器与 docs/lib.md 中all_parser_info的show_hidden语义对应常规列表不一定直接展示可用jc -hh查看全部隐藏解析器见 jc/cli_data.py 中的示例说明。该文档的原始说明位于 docs/parsers/proc_loadavg.md与源码文件头 docstring 保持同步。CLI 调用方式文档给出了三种等价调用形式覆盖了管道、文件路径和指定解析器三种常见用法# 方式一通过 --proc 分发解析器 $ cat /proc/loadavg | jc --proc # 方式二Magic 语法直接把 /proc 文件作为位置参数 $ jc /proc/loadavg # 方式三直接指定 proc-loadavg 解析器 $ cat /proc/loadavg | jc --proc-loadavg几点使用细节Magic 语法的位置约束从 jc/parsers/proc.py 的 docstring 可知jc /proc/path to file形式要求jc的所有选项必须写在/proc路径之前否则会解析失败。隐藏解析器的发现由于hidden True若你想确认proc-loadavg是否在可用列表中建议用jc -hh显示隐藏解析器或jc -a。输出选项组合文档示例中-p表示 pretty-print带缩进的 JSON-r表示 raw见下文配合--yaml等选项同样可切换输出格式这也是jc项目整体设计目标之一——把命令输出转成 JSON/YAML 以便接入jq等工具。输出 Schema 与字段语义文档定义的输出 Schema 如下注意文档 Schema 标题写有 All values are integers 的遗留描述但字段声明与源码实现一致——三个 load 字段为浮点数其余为整数{ load_1m: float, load_5m: float, load_15m: float, running: integer, available: integer, last_pid: integer }字段语义对照原始文件0.00 0.01 0.03 2/111 2039字段类型来源字段说明load_1mfloat第 1 个字段最近 1 分钟平均负载load_5mfloat第 2 个字段最近 5 分钟平均负载load_15mfloat第 3 个字段最近 15 分钟平均负载runninginteger2/111中/前正在运行不可中断睡眠或运行中的任务数availableinteger2/111中/后可运行含运行中的任务总数last_pidinteger第 5 个字段最近分配出去的进程 PID文档中的两段示例输出可直接复现$ cat /proc/loadavg | jc --proc -p { load_1m: 0.0, load_5m: 0.01, load_15m: 0.03, running: 2, available: 111, last_pid: 2039 } $ cat /proc/loadavg | jc --proc -p -r { load_1m: 0.00, load_5m: 0.01, load_15m: 0.03, running: 2, available: 111, last_pid: 2039 }对比可见-rraw模式保留解析前的原始字符串值不做float/int转换适合需要按原文精确比较或二次处理的场景默认非 raw模式则输出类型化数值可直接做数值比较运算。Python 模块 API 调用除 CLI 外文档给出了两种模块级调用方式二者等价import jc result jc.parse(proc, proc_loadavg_file)import jc result jc.parse(proc_loadavg, proc_loadavg_file)传入proc时走 jc/parsers/proc.py 的分发逻辑自动识别文件类型后委托给proc_loadavg解析传入proc_loadavg时直接命中目标解析器跳过识别过程开销更低、意图更明确。结合 jc/lib.py 提供的高层 API还可以按 docs/lib.md 中jc.lib.parse的说明通过jc.get_parser(proc_loadavg)先取模块再调用其parse()或直接import jc.parsers.proc_loadavg使用底层模块参数签名与文档一致def parse(data: str, raw: bool False, quiet: bool False) - Dictdatastring待解析的文本数据rawboolean为True时返回未类型转换的原始结构化数据quietboolean为True时抑制警告信息。源码实现剖析parse() 的解析流程源码 实现非常紧凑核心逻辑如下def parse(data: str, raw: bool False, quiet: bool False) - Dict: jc.utils.compatibility(__name__, info.compatible, quiet) jc.utils.input_type_check(data) raw_output: Dict {} if jc.utils.has_data(data): load_1m, load_5m, load_15m, runnable, last_pid data.split() running, available runnable.split(/) raw_output { load_1m: load_1m, load_5m: load_5m, load_15m: load_15m, running: running, available: available, last_pid: last_pid } return raw_output if raw else _process(raw_output)从源码结构看解析分为四步前置校验jc.utils.compatibility()校验当前平台是否在info.compatiblelinux内jc.utils.input_type_check()确保传入data是字符串/bytes 等合法类型实现见 jc/utils.py 中的compatibility、input_type_check函数。空输入短路jc.utils.has_data(data)为False时直接返回空字典{}不做任何 split。这意味着解析空输入不会抛异常而是得到{}——测试用例test_proc_loadavg_nodata正是验证了这一点见 tests/test_proc_loadavg.py。按空白切分data.split()把单行文本拆成 5 个 token第 4 个 token2/111再用split(/)拆成running与available。这是无正则的纯字符串解析性能开销极小但也隐含前提输入必须恰好是标准/proc/loadavg格式否则解包会触发ValueError。类型转换非 raw 路径进入_process()float_list {load_1m, load_5m, load_15m} int_list {running, available, last_pid} for key in proc_data: if key in float_list: proc_data[key] float(proc_data[key]) if key in int_list: proc_data[key] int(proc_data[key])这里用两个集合白名单明确划分了浮点字段与整数字段与 Schema 声明一一对应rawTrue时跳过此步返回的全是字符串。--proc 分发器如何自动识别 loadavg 文件jc /proc/loadavg或jc --proc之所以能无参识别文件类型依赖 jc/parsers/proc.py 中的签名正则。loadavg对应的签名为loadavg_p re.compile(r^\d.\d\d \d.\d\d \d.\d\d \d/\d \d$)见 proc.py 签名定义 与 procmap 路由表。其识别策略为按procmap顺序对输入数据逐一search首个命中的正则决定委托给哪个proc_*子解析器命中loadavg_p时通过get_parser(proc_loadavg)动态加载模块并调用其parse()。若所有签名都未命中则抛出ParseError(Proc file could not be identified.)。值得注意的是该正则末尾的\d$要求第 5 字段last_pid为纯数字且独占行尾与proc_uptime的签名^\d.\d\d \d.\d\d$形成区分——两者字段数不同不会误判。此外proc.py的 docstring 提到 Magic 语法支持slurping多文件输入如jc /proc/*/stat会输出数组并附带_file字段用于输入输出关联proc解析器因此带有slurpable标签而proc_loadavg单独作为文件解析器使用标签为file。空输入处理与测试验证/proc/loadavg的解析行为被 tests/test_proc_loadavg.py 中的两个用例完整覆盖def test_proc_loadavg_nodata(self): # 空输入应返回空字典 self.assertEqual(jc.parsers.proc_loadavg.parse(, quietTrue), {}) def test_proc_loadavg(self): # 标准 fixture 输入应输出与期望 JSON 完全一致的结果 self.assertEqual(jc.parsers.proc_loadavg.parse(self.f_in[proc_loadavg], quietTrue), self.f_json[proc_loadavg])测试使用的 fixture 与期望输出存放在输入tests/fixtures/linux-proc/loadavg内容为0.00 0.01 0.03 2/111 2039期望 JSONtests/fixtures/linux-proc/loadavg.json内容为{load_1m: 0.0, load_5m: 0.01, load_15m: 0.03, running: 2, available: 111, last_pid: 2039}。这与文档 Examples 一节给出的数值完全吻合说明文档示例即由该 fixture 生成可直接用于本地对照验证运行tests/下的单元测试即可复现见 runtests.sh。适用边界与实战建议基于文档与源码使用时的注意事项平台限制info.compatible [linux]该解析器面向 Linux 的 procfs 设计其他平台下compatibility()会给出兼容性提示可经quietTrue抑制。输入格式敏感parse()依赖恰好 5 个空白分隔字段、且第 4 字段含/。若管道混入额外换行或文本可能触发解包异常或--proc分发器无法识别而抛ParseError。数值比较用默认模式原文核对用 raw默认输出为 float/int便于jq中做select(.load_1m 1)之类的阈值判断需要与cat原文逐字符比对时加-r。直接指定解析器更稳已知输入就是 loadavg 时jc --proc-loadavg或jc.parse(proc_loadavg, data)可跳过分发器的签名匹配语义更清晰。相关文件索引资源路径解析器文档docs/parsers/proc_loadavg.md解析器源码jc/parsers/proc_loadavg.pyproc 分发器jc/parsers/proc.py单元测试tests/test_proc_loadavg.py测试 fixturetests/fixtures/linux-proc/loadavg / tests/fixtures/linux-proc/loadavg.json库级 API 说明docs/lib.md赞分享开发工具【免费下载链接】jcCLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.项目地址https://gitcode.com/gh_mirrors/jc/jc点击查看免费下载相关推荐jc proc-cpuinfo 解析器将 Linux /proc/cpuinfo 精准转换为结构化 JSONjc proc cpuinfo 解析器将 Linux /proc/cpuinfo 精准转换为结构化 JSON 本文基于 proc_cpuinfo 解析器文档开发工具jc ping 解析器实战把 ping / ping6 命令输出转换为结构化 JSONjc ping 解析器实战把 ping / ping6 命令输出转换为结构化 JSON jcJSON Convert的 ping 解析器能将 ping 与开发工具jc proc-iomem 解析器把 /proc/iomem 物理内存映射转为可查询的 JSON 结构jc proc iomem 解析器把 /proc/iomem 物理内存映射转为可查询的 JSON 结构 本文围绕 jc 项目中的 proc_iomem 解析器开发工具上一篇如何快速搭建个人游戏云主机Sunshine游戏串流完全配置指南下一篇3分钟搞定NCM文件解密Windows用户的音乐格式转换终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 jc proc_loadavg 解析器详解：把 /proc/loadavg 负载数据结构化输出为 JSON
开发工具【免费下载链接】jcCLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.项目地址https://gitcode.com/gh_mirrors/jc/jc点击查看免费下载本文围绕jc仓库中的proc_loadavg解析器文档展开讲清 Linux 系统负载文件/proc/loadavg如何被jc转换为结构化 JSON 的完整链路三种 CLI 调用方式、Python 模块 API、输出 Schema 与字段类型并结合 源码实现 剖析parse()的解析流程、类型转换逻辑以及--proc分发器如何靠签名正则自动识别该文件。读完后你可以直接在监控脚本或自动化环境中用jc或jq消费负载平均值数据。/proc/loadavg 输入格式与解析器定位/proc/loadavg是 Linux 内核暴露在 procfs 中的单行文件内容形如0.00 0.01 0.03 2/111 2039五个字段依次为1 分钟、5 分钟、15 分钟平均负载运行中任务数/调度队列中任务总数以及最近分配的 PID。jc仓库中针对该文件的解析器为jc.parsers.proc_loadavg其解析器元数据源码见 info 类声明了Version:1.0作者 Kelly BrazilCompatibility:[linux]—— 仅在 Linux 平台可正常运行parse()入口会先调用jc.utils.compatibility()做平台校验Tags:[file]Hidden: 源码中info.hidden True即该解析器被标记为隐藏解析器与 docs/lib.md 中all_parser_info的show_hidden语义对应常规列表不一定直接展示可用jc -hh查看全部隐藏解析器见 jc/cli_data.py 中的示例说明。该文档的原始说明位于 docs/parsers/proc_loadavg.md与源码文件头 docstring 保持同步。CLI 调用方式文档给出了三种等价调用形式覆盖了管道、文件路径和指定解析器三种常见用法# 方式一通过 --proc 分发解析器 $ cat /proc/loadavg | jc --proc # 方式二Magic 语法直接把 /proc 文件作为位置参数 $ jc /proc/loadavg # 方式三直接指定 proc-loadavg 解析器 $ cat /proc/loadavg | jc --proc-loadavg几点使用细节Magic 语法的位置约束从 jc/parsers/proc.py 的 docstring 可知jc /proc/path to file形式要求jc的所有选项必须写在/proc路径之前否则会解析失败。隐藏解析器的发现由于hidden True若你想确认proc-loadavg是否在可用列表中建议用jc -hh显示隐藏解析器或jc -a。输出选项组合文档示例中-p表示 pretty-print带缩进的 JSON-r表示 raw见下文配合--yaml等选项同样可切换输出格式这也是jc项目整体设计目标之一——把命令输出转成 JSON/YAML 以便接入jq等工具。输出 Schema 与字段语义文档定义的输出 Schema 如下注意文档 Schema 标题写有 All values are integers 的遗留描述但字段声明与源码实现一致——三个 load 字段为浮点数其余为整数{ load_1m: float, load_5m: float, load_15m: float, running: integer, available: integer, last_pid: integer }字段语义对照原始文件0.00 0.01 0.03 2/111 2039字段类型来源字段说明load_1mfloat第 1 个字段最近 1 分钟平均负载load_5mfloat第 2 个字段最近 5 分钟平均负载load_15mfloat第 3 个字段最近 15 分钟平均负载runninginteger2/111中/前正在运行不可中断睡眠或运行中的任务数availableinteger2/111中/后可运行含运行中的任务总数last_pidinteger第 5 个字段最近分配出去的进程 PID文档中的两段示例输出可直接复现$ cat /proc/loadavg | jc --proc -p { load_1m: 0.0, load_5m: 0.01, load_15m: 0.03, running: 2, available: 111, last_pid: 2039 } $ cat /proc/loadavg | jc --proc -p -r { load_1m: 0.00, load_5m: 0.01, load_15m: 0.03, running: 2, available: 111, last_pid: 2039 }对比可见-rraw模式保留解析前的原始字符串值不做float/int转换适合需要按原文精确比较或二次处理的场景默认非 raw模式则输出类型化数值可直接做数值比较运算。Python 模块 API 调用除 CLI 外文档给出了两种模块级调用方式二者等价import jc result jc.parse(proc, proc_loadavg_file)import jc result jc.parse(proc_loadavg, proc_loadavg_file)传入proc时走 jc/parsers/proc.py 的分发逻辑自动识别文件类型后委托给proc_loadavg解析传入proc_loadavg时直接命中目标解析器跳过识别过程开销更低、意图更明确。结合 jc/lib.py 提供的高层 API还可以按 docs/lib.md 中jc.lib.parse的说明通过jc.get_parser(proc_loadavg)先取模块再调用其parse()或直接import jc.parsers.proc_loadavg使用底层模块参数签名与文档一致def parse(data: str, raw: bool False, quiet: bool False) - Dictdatastring待解析的文本数据rawboolean为True时返回未类型转换的原始结构化数据quietboolean为True时抑制警告信息。源码实现剖析parse() 的解析流程源码 实现非常紧凑核心逻辑如下def parse(data: str, raw: bool False, quiet: bool False) - Dict: jc.utils.compatibility(__name__, info.compatible, quiet) jc.utils.input_type_check(data) raw_output: Dict {} if jc.utils.has_data(data): load_1m, load_5m, load_15m, runnable, last_pid data.split() running, available runnable.split(/) raw_output { load_1m: load_1m, load_5m: load_5m, load_15m: load_15m, running: running, available: available, last_pid: last_pid } return raw_output if raw else _process(raw_output)从源码结构看解析分为四步前置校验jc.utils.compatibility()校验当前平台是否在info.compatiblelinux内jc.utils.input_type_check()确保传入data是字符串/bytes 等合法类型实现见 jc/utils.py 中的compatibility、input_type_check函数。空输入短路jc.utils.has_data(data)为False时直接返回空字典{}不做任何 split。这意味着解析空输入不会抛异常而是得到{}——测试用例test_proc_loadavg_nodata正是验证了这一点见 tests/test_proc_loadavg.py。按空白切分data.split()把单行文本拆成 5 个 token第 4 个 token2/111再用split(/)拆成running与available。这是无正则的纯字符串解析性能开销极小但也隐含前提输入必须恰好是标准/proc/loadavg格式否则解包会触发ValueError。类型转换非 raw 路径进入_process()float_list {load_1m, load_5m, load_15m} int_list {running, available, last_pid} for key in proc_data: if key in float_list: proc_data[key] float(proc_data[key]) if key in int_list: proc_data[key] int(proc_data[key])这里用两个集合白名单明确划分了浮点字段与整数字段与 Schema 声明一一对应rawTrue时跳过此步返回的全是字符串。--proc 分发器如何自动识别 loadavg 文件jc /proc/loadavg或jc --proc之所以能无参识别文件类型依赖 jc/parsers/proc.py 中的签名正则。loadavg对应的签名为loadavg_p re.compile(r^\d.\d\d \d.\d\d \d.\d\d \d/\d \d$)见 proc.py 签名定义 与 procmap 路由表。其识别策略为按procmap顺序对输入数据逐一search首个命中的正则决定委托给哪个proc_*子解析器命中loadavg_p时通过get_parser(proc_loadavg)动态加载模块并调用其parse()。若所有签名都未命中则抛出ParseError(Proc file could not be identified.)。值得注意的是该正则末尾的\d$要求第 5 字段last_pid为纯数字且独占行尾与proc_uptime的签名^\d.\d\d \d.\d\d$形成区分——两者字段数不同不会误判。此外proc.py的 docstring 提到 Magic 语法支持slurping多文件输入如jc /proc/*/stat会输出数组并附带_file字段用于输入输出关联proc解析器因此带有slurpable标签而proc_loadavg单独作为文件解析器使用标签为file。空输入处理与测试验证/proc/loadavg的解析行为被 tests/test_proc_loadavg.py 中的两个用例完整覆盖def test_proc_loadavg_nodata(self): # 空输入应返回空字典 self.assertEqual(jc.parsers.proc_loadavg.parse(, quietTrue), {}) def test_proc_loadavg(self): # 标准 fixture 输入应输出与期望 JSON 完全一致的结果 self.assertEqual(jc.parsers.proc_loadavg.parse(self.f_in[proc_loadavg], quietTrue), self.f_json[proc_loadavg])测试使用的 fixture 与期望输出存放在输入tests/fixtures/linux-proc/loadavg内容为0.00 0.01 0.03 2/111 2039期望 JSONtests/fixtures/linux-proc/loadavg.json内容为{load_1m: 0.0, load_5m: 0.01, load_15m: 0.03, running: 2, available: 111, last_pid: 2039}。这与文档 Examples 一节给出的数值完全吻合说明文档示例即由该 fixture 生成可直接用于本地对照验证运行tests/下的单元测试即可复现见 runtests.sh。适用边界与实战建议基于文档与源码使用时的注意事项平台限制info.compatible [linux]该解析器面向 Linux 的 procfs 设计其他平台下compatibility()会给出兼容性提示可经quietTrue抑制。输入格式敏感parse()依赖恰好 5 个空白分隔字段、且第 4 字段含/。若管道混入额外换行或文本可能触发解包异常或--proc分发器无法识别而抛ParseError。数值比较用默认模式原文核对用 raw默认输出为 float/int便于jq中做select(.load_1m 1)之类的阈值判断需要与cat原文逐字符比对时加-r。直接指定解析器更稳已知输入就是 loadavg 时jc --proc-loadavg或jc.parse(proc_loadavg, data)可跳过分发器的签名匹配语义更清晰。相关文件索引资源路径解析器文档docs/parsers/proc_loadavg.md解析器源码jc/parsers/proc_loadavg.pyproc 分发器jc/parsers/proc.py单元测试tests/test_proc_loadavg.py测试 fixturetests/fixtures/linux-proc/loadavg / tests/fixtures/linux-proc/loadavg.json库级 API 说明docs/lib.md赞分享开发工具【免费下载链接】jcCLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.项目地址https://gitcode.com/gh_mirrors/jc/jc点击查看免费下载相关推荐jc proc-cpuinfo 解析器将 Linux /proc/cpuinfo 精准转换为结构化 JSONjc proc cpuinfo 解析器将 Linux /proc/cpuinfo 精准转换为结构化 JSON 本文基于 proc_cpuinfo 解析器文档开发工具jc ping 解析器实战把 ping / ping6 命令输出转换为结构化 JSONjc ping 解析器实战把 ping / ping6 命令输出转换为结构化 JSON jcJSON Convert的 ping 解析器能将 ping 与开发工具jc proc-iomem 解析器把 /proc/iomem 物理内存映射转为可查询的 JSON 结构jc proc iomem 解析器把 /proc/iomem 物理内存映射转为可查询的 JSON 结构 本文围绕 jc 项目中的 proc_iomem 解析器开发工具上一篇如何快速搭建个人游戏云主机Sunshine游戏串流完全配置指南下一篇3分钟搞定NCM文件解密Windows用户的音乐格式转换终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考