Protobuf 解码器（无需 .proto）
protobuf 负载本身什么都不透露。线上传输的没有字段名，只有编号和 wire 类型，所以来自 gRPC 调用或 API 抓包的二进制正文，如果没有生成它的 .proto 文件就无法阅读——而在调试别人的服务时，你通常拿不到那个文件。 这个解码器直接读取 wire 格式。每个字段都会带着编号、wire 类型和取值返回，嵌套消息就地展开；当编码本身存在歧义时，它会明确说明，而不是替你做决定。这种歧义是真实存在的：varint 可能是无符号整数、zigzag 编码的有符号整数，也可能是布尔值；长度分隔字段可能是字符串、嵌套消息、packed 重复数字，或就是原始字节。工具会给出最可能的读法，并把其他读法列在旁边。 对嵌套消息的判断不是对语义的猜测：只有当一段字节能够干净地解析为消息——每个键都是合法的字段编号，每个长度都恰好落在末尾——才会作为消息呈现。全部处理都在你的浏览器中完成，负载不会被上传。
—
粘贴 base64 或 hex 的 protobuf 负载即可解码。
使用方法
- 以 base64 或 hex 粘贴负载——格式会自动识别，也可以手动指定。
- 阅读这棵树：每一行是字段编号、wire 类型和取值。
- 留意灰色文字，那是同一个值的其他可能读法。
- 嵌套消息会缩进显示在其父字段之下。
- 拖入二进制文件，可直接解码抓取到的正文。
常见问题
- 为什么看不到字段名？
- 因为字段名根本不会被传输。protobuf 在线上只放字段编号和 wire 类型，名字保存在两端的 .proto 文件里。这正是编码紧凑的原因，也是无 schema 解码器只能展示消息结构、却无法给出字段名称的原因。
- 它怎么判断某个字段是嵌套消息？
- 它会尝试把这段字节解析为消息，只有完全自洽时才采纳：每个键都是合法的字段编号和 wire 类型，每个长度都恰好在缓冲区末尾结束。短字符串有时会碰巧通过这项检验，因此当这段字节同时也是有效文本时，工具会标注该读法存在歧义。
- 数字的其他读法是指什么？
- 线上的 varint 可能是 int32/int64/uint、zigzag 的 sint，或者 bool。fixed64 可能是 double、fixed64 或 sfixed64。负载中没有任何信息能区分它们，所以先展示最常见的读法，其余列在旁边。
- 能解码 gRPC 的正文吗？
- gRPC 帧会在每条消息前加上 1 字节压缩标志和 4 字节长度。去掉这 5 个字节，剩下的就能在这里解码。压缩过的帧需要先解压。
- group 怎么处理？
- group 是 proto2 中已废弃的 wire 类型 3 和 4，如今几乎见不到。遇到时解码器只标出该标记，而不去猜测嵌套结构。
- 我的负载会被上传吗？
- 不会。字节在你的浏览器中解码，不会发送到任何服务器。
相关工具
JSON 转 Protobuf 模式转换器 (proto3)
在浏览器中将 JSON 对象转换为带类型字段和嵌套消息的 proto3 .proto 模式。
开发 0 0
JWT 解码器
解码 JSON Web Token，查看其头部、声明和过期时间。
开发 0 0
MessagePack 解码器
粘贴 base64 或 hex 的 MessagePack 字节，在浏览器中读出取值——类型、嵌套映射、二进制块与时间戳。
开发 0 0
Base64 编码 / 解码
即时将文本编码为 Base64，或将 Base64 解码为文本。
开发 0 0
Data URI 解析器与解码器
在浏览器中解码 data: URI,查看其 MIME 类型、编码、大小和解码内容。
开发 0 0
Base64 与十六进制互转
在浏览器中将 Base64 字符串转换为十六进制字节,并将十六进制转换回 Base64,支持 URL-safe。
开发 0 0