WebSocket帧解码器 (RFC 6455)

什么是WebSocket帧?

通过WebSocket连接发送的每条消息都被包装在一个帧中 — 一个小的二进制头部(RFC 6455 §5.2定义)后跟有效载荷数据。头部将几个字段紧凑地打包到前一或两个字节中：FIN位、三个RSV(保留)位、标识帧类型(text、binary、ping、pong、close…)的4位opcode、MASK位和有效载荷长度，可以根据有效载荷大小采用三种不同的字节宽度。如果帧被掩码化，有效载荷也会在您读取之前与4字节的掩码密钥进行XOR运算。这些东西肉眼看不出来 — 该工具逐字段解码。

如何使用

1. 以十六进制粘贴原始帧字节(用空格、冒号或0x分隔 — 81 05 48 65 6c 6c 6f和0x81,0x05,0x48,0x65,0x6c,0x6c,0x6f都可以工作)或作为二进制位字符串(例如10000001 00000101 ...)。
2. Frame Fields显示FIN、RSV1–3、opcode(带其名称)、MASK、原始7位长度字段和实际解析的有效载荷长度、掩码密钥(如果有)和任何协议警告。
3. Byte Structure按字节偏移量分解帧 — 哪些字节组成头部、扩展长度(如果存在)、掩码密钥(如果存在)和有效载荷 — 镜像RFC 6455图表中的布局。
4. Payload显示接收到的有效载荷(如果适用，仍被掩码化)、XOR未掩码的十六进制以及 — 对于文本帧 — 解码的UTF-8文本。关闭帧将其2字节状态码和UTF-8原因短语单独分割。
5. JSON Export将相同的解码字段作为单个JSON对象提供，用于脚本或错误报告。

三种有效载荷长度形式

第二个字节的低7位编码长度，但它们携带的含义取决于该值：

• 0–125 — 这是实际的有效载荷长度。
• 126 — 实际长度作为接下来的2个字节(大端字节序、无符号16位)。
• 127 — 实际长度作为接下来的8个字节(大端字节序、无符号64位；最高有效位必须按RFC为0)。

掩码化

客户端到服务器的帧必须被掩码化(MASK=1) — 有效载荷针对紧跟长度字段之后的4字节掩码密钥进行XOR运算，密钥每4字节循环一次(payload[i] XOR key[i mod 4])。服务器到客户端的帧通常不被掩码化。该工具在MASK=1时自动进行反掩码，并显示原始的和未掩码的十六进制，以便您可以比较。

该工具标记为警告的内容

• 控制帧(close/ping/pong、opcode 0x8–0xA)的FIN=0，或有效载荷超过125字节 — 按RFC 6455 §5.5两者都无效(控制帧不能被分片或携带大有效载荷)。
• 任何设置的RSV位，但没有商定的扩展来定义它。
• 保留opcode(0x3–0x7或0xB–0xF) — 没有扩展则未定义。
• 截断的帧 — 声明的长度超过实际提供的字节。

该工具不执行的操作

解码已捕获的单个帧的头部 — 不打开活动WebSocket连接、不将碎片化帧序列(opcode 0x0继续帧)重新组装为一条逻辑消息、不验证任何WebSocket流量之前的HTTP Upgrade握手。

FAQ

我在哪里可以获得要粘贴的原始帧字节? 从浏览器的DevTools网络面板(WS选项卡 → 单击一个帧 → 原始字节)、从数据包捕获(Wireshark的"Follow → WebSocket Stream"或TCP有效载荷的十六进制视图)或从代理工具如Burp/mitmproxy获取它们。

为什么我的输入无法解析? 帧头部至少为2字节 — 确保您粘贴了完整的帧，而不仅仅是有效载荷。十六进制输入需要偶数个十六进制数字；二进制输入需要位数为8的倍数。

我的数据会上传到任何地方吗? 不会 — 解码完全在您的浏览器中运行。您粘贴的任何内容都不会离开您的设备。

相关工具

• Hex Dump Viewer — 用于任何二进制blob的通用字节级视图。
• HTTP Header Analyzer — 解码WebSocket连接之前的HTTP Upgrade握手。
• Raw HTTP Request Parser — 解析原始HTTP请求行和头部。