Modbus 0x14 一次读多个文件记录，怎样按子响应边界拆包

0x14（十进制 20）读文件记录的响应由多个子响应组成。每段先声明子响应长度，再给引用类型 06 和记录数据；应按游标逐段消费，不能把所有剩余字节按普通寄存器回包直接拆成双字节。

适用版本与输入范围

依据 Modbus Application Protocol V1.1b3（2012-04-26），按下方具体功能章节解释PDU。输入已经剥离RTU地址、CRC或TCP封装，不把封装检查与数据字段解析混为一体。 本文所有输入均为原创合成数据，未接真实设备。

区分总长度和子响应长度

示例响应 14 0C 后面有十二个数据字节，包含两段相同长度的子响应。每段的 05 表示后面五字节，其中 06 是引用类型，余下四字节才是两项记录数据。总 byte count 包含每个子响应自己的长度字节，子响应长度却不包含自身这一字节。只要把这两个计数的起点混淆，第二段就会错一字节，可能仍读出看似合理却不属于任何记录的数。

先验证边界再访问字段

程序令 end=当前游标+1+子响应长度，先检查 end 不越过总响应，再读取引用类型和数据。引用类型只支持规范中的 06；数据长度减去引用类型字节后必须是偶数，才能拆成十六位记录字。附件负例故意声明长度九，却只给出六字节总负载，程序报告子响应越界，不补齐、不跨到下一个报文读取。这个检查是处理不可信导出日志时的基本边界。

记录数据不是地址字段

正常响应不会在每个子响应里再次回传文件号和记录号，子响应应按请求顺序与原请求配对。本附件用第一段 11、12 和第二段 21、22 区分两组值，报告保留 records 嵌套数组，避免合并后丢失分段。正式工程应同时保存请求中的文件号、记录号和记录长度；仅看这个响应无法凭空恢复它们。这里的“文件”也不是操作系统路径，程序没有访问设备或写入任何真实文件。

只接受明确声明的记录子集

本解析器限定公开功能的引用类型 06 和非空、偶数字节记录数据，不尝试解释厂商业务结构。第二条负例把引用类型改为 05，长度仍然自洽，也应因类型不受支持而拒绝，而不是盲目读取数值。离线报告给出子响应数量与逐段值，能验证游标和记录边界；设备是否支持文件记录功能、文件号范围和内容语义仍需对照厂商手册，不由通用解析器替厂商定义。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 3 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。records保留请求顺序内的分组；subresponses只是解析段数，不包含文件号或记录地址。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到Modbus 寄存器映射基础核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• §6.14 Read File Record

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。