WebSocket 一条 JSON 被分成多帧，怎样验消息边界

WebSocket的帧不是应用消息。一条文本消息可以由首个text帧和后续continuation帧组成，最后由FIN结束；中间允许穿插Ping等控制帧，控制帧不属于JSON内容。成熟浏览器API通常交付完整message，只有底层接收库或抓包分析才需要自己处理帧，不要在每个片段上独立JSON.parse。

环境和证据范围

附件是已经去除掩码、已提取payload的离线帧描述，不是完整可发送的WebSocket线包。只演示一条非交错数据消息的分片与控制帧插入，不实现握手、扩展、掩码或完整协议校验。未测试浏览器、服务端库或真实TCP分段行为。

核对顺序

1. 先确认观察点提供的是TCP字节块、WebSocket帧还是完整message。TCP一次read不保证一帧，浏览器一次message又不等于一次TCP包；混淆层级会把本来正确的库再次错误拆包。

2. 底层帧解析后按opcode和FIN维护当前消息。text或binary开始消息，continuation继续；收到最终continuation后才将完整payload交给对应解析器。

3. 遇到Ping/Pong等控制帧先独立处理，保持当前分片缓存不变。控制帧自身不能分片，也不应被拼进业务JSON；还需有消息最大字节数和缓冲上限，避免无限等待。

4. 加入没有首帧就出现continuation、前一分片未结束又来了新数据消息的错误输入。生产库应按规范处理错误，附件只输出明确的错误标签，不生成真实Close帧。

可复算的输入与预期

合成帧依次为text FIN=0装入{“v”:、Ping FIN=1装入p、continuation FIN=1装入1}，随后独立text消息{“v”:2}。输出两条完整文本{“v”:1}和{“v”:2}，Ping单独计数1。另一个孤立continuation输出“缺首帧”。

接收端还应区分“当前消息未结束”和“连接已正常关闭”。连接关闭时留下的半条消息不能补成JSON对象，也不能带到新连接继续拼接；新连接的消息重组状态应重新初始化，避免两次会话的字节混在一起。

下载与现场记录

下载本题合成输入与预期JSON、离线只读核验脚本和现场空白记录CSV。放在同一目录，用 Python 3 运行 python verify.py，逐项计算或解析后与预期比较，失败会显示差异。

现场字段包括 capture_layer、opcode、fin、payload_bytes、message_index、control_frame_count、library_version。合成样例保持原样，实测另存并填写型号、版本、证据路径，未采集处留空。本地核验不代表真实设备、代理、浏览器或长期稳定性已测。

失败分支与移交

对每个片段单独做UTF-8解码也可能把跨帧多字节字符误判为乱码，应以完整文本消息的编码要求处理。使用浏览器message事件时不应再等待FIN字段，因为它根本没有暴露这个字段。若接收库已重组，优先核对使用方式，避免自建第二套缓存。

移交材料应注明日志层级、是否已经解掩码和重组、库版本、消息大小限制以及异常关闭记录。真实抓包还要核对扩展协商，压缩扩展会改变负载处理；本页简化夹具不能替代实现RFC6455全部状态机。

基础背景可看WebSocket 实时控制协议科普（RFC 6455）。片段重组后还要正确解码多字节文本，见WebSocket 收到二进制却当字符串，怎样核对 UTF-8 解码边界。更多资料在设备协议库。

需要接入中控时，可对照SoftControl设备联动需求核实适配范围；独立校验方法是否纳入交付需逐项约定。

一级资料

• 官方资料：§5.4 Fragmentation与§5.5控制帧

核对日期：2026-10-24。规范定义与本文应用约定分开，示例门限及脚本不自动代表产品原生能力。