Protocol Buffers 解码器

无 schema 的 Protobuf 解码器能够确认什么

Protocol Buffers 保存的是一系列字段 tag 和值，而不是原始 .proto 声明。protobuf 官方编码指南规定，tag 由字段编号左移三位后与线类型组合而成，等同于 field_number × 8 + wire_type。因此，本解码器能够确认字段编号、线类型、字节边界，以及结构上可能成立的编码方式。但它无法确认某个 varint 被声明为 uint64、int64、sint64、bool 还是 enum，因为这些声明可能共用完全相同的字节。

输入模式始终由用户明确选择。Hex 允许 ASCII 空白，并且最多允许一个位于开头的 0x。Base64 和 Base64URL 会分别验证长度、填充和未使用的填充位；标准字符集与 URL-safe 字符集不能混用。原始文本指浏览器 TextEncoder 生成的精确 UTF-8 字节，不会解释反斜杠转义。文件输入则使用文件的原始字节。

线类型与候选解释

JavaScript 的普通 number 类型无法精确表示所有 64 位整数。本解码器在整个线格式解析器中使用 BigInt，并将精确整数转换为十进制字符串用于显示和导出。NaN、无穷大和负零等特殊浮点值也会作为字符串导出，避免 JSON 在无提示的情况下将其变成其他值。

理解长度分隔值的歧义

线类型 2 可用于字符串、原始字节、嵌入消息和 packed 重复标量值。缺少 schema 时，同一段字节可能同时满足多种用途。例如，2a 03 01 02 03 表示含有三个字节的字段 5。这些字节可以是有效的 packed varint [1, 2, 3]，也可以只是普通字节。解码器会同时展示两者，不会将其中一个评为更可信。

只有当长度分隔区域的全部内容都能解析为一条完整消息时，才会出现嵌套消息候选解释。packed varint、fixed32 和 fixed64 候选解释同样必须在该解释下用尽全部字节。严格 UTF-8 候选解释要求整个序列都能在没有替代字符的情况下完成解码。这些检查展示的是结构上的可能性，而不是字段的声明类型。

虽然现代 schema 通常更倾向于嵌入消息，本工具仍会按照线格式语法处理组。start-group tag 必须由字段编号相同的 end-group tag 结束。根级结束 tag、不匹配的结束 tag 或缺少结束 tag，都会让解码在准确的字节偏移处停止。错误之前已经完整解码的字段仍会保留；缺失字节和未知值绝不会被伪装成零。

限制、分帧与安全处理

本解码器接收一条最大 10 MiB 的未分帧消息。它不会拆分带长度前缀的 stream、gRPC frame、Delimited Message 文件或其他传输封装。请先去除分帧，再解码单条消息。解析器还会限制记录总数、递归深度、可见行数和候选解释的计算量。这些控制遵循官方关于大型数据集和实现限制的指导原则：protobuf 虽然高效，但浏览器中的诊断页面仍需限制内存和工作量。

字段编号必须介于 1 和 536,870,911 之间。官方字段编号指南将 19,000–19,999 预留给实现，因此本工具会对该范围给出警告。线类型 6 和 7 无效。

解析和导出均在本地进行。多步骤视图可能会在当前标签页的 sessionStorage 中保存大小受限的 payload，最长两小时；重新开始时会将其删除。任何数据都不会写入 URL，也不会发送到我们的服务器。JSON 输出明确属于本工具专用格式的解码报告，而不是 ProtoJSON。CSV 以 UTF-8 BOM 开头，并为类似公式的单元格添加前缀，以便在电子表格中更安全地打开。报告本身仍可能包含机密应用数据，因此分享前请先检查。