Protobuf 查看
不需要 .proto 文件即可解析 Protocol Buffers 二进制数据：按字段号展示 varint（含 zigzag）、fixed32/64、长度前缀字段，并对长度前缀内容递归尝试嵌套消息、可打印字符串或十六进制字节。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
解析结果
粘贴十六进制字节后自动解析
选中节点
JSON 视图
同一字段号重复出现时聚合为数组；字节串写作 0x…，超出安全范围的整数以字符串表示。
这个工具能做什么
- 抓包或日志里只有一段二进制，没有 .proto 文件，先粘进来看看字段号和内容，再决定要不要找 schema。
- 调试 gRPC 或 Kafka 里的 protobuf 消息：确认某个字段到底传了什么，字段号是否和接口文档一致。
- 核对序列化结果：把十六进制字节解成树，对比 JSON 视图，快速判断 packed repeated 字段有没有按预期打包。
- 逆向第三方接口时按字段号猜字段含义，长度前缀字段会先尝试嵌套消息、再试可打印文本，省去手工切字节。
示例
输入
08 96 01 12 07 74 65 73 74 69 6e 67
输出
{
"1": 150,
"2": "testing"
}字段 1 是 varint（0x96 0x01 = 150），字段 2 是长度前缀字段，内容按 UTF-8 解码出可打印文本 testing。
常见问题
没有 .proto 文件真的能解析吗？
能解析 wire format，但不知道字段真实类型。varint、fixed32/64 和长度前缀都能按协议解出来，长度前缀的内容按「先尝试嵌套消息、再尝试可打印文本、最后退化为十六进制」判断，所以类型标签是推断而不是权威结论。
varint 旁边的 zigzag 是什么？
sint32 / sint64 会用 zigzag 编码把负数映射成小的正整数，解析时无法区分两者，所以两个值都显示：原值用于 uint32 / uint64 / int32 / int64，zigzag 值用于 sint 类型。
为什么 packed repeated 字段显示成字节串？
packed 编码把一串数字塞进一个长度前缀字段，没有 schema 时无法知道里面是几个字节的元素还是别的数据，工具只能按字节串展示，这是预期行为。
报「不是合法的 protobuf 数据」是什么原因？
常见原因：字节被截断（长度前缀声明的长度超过剩余字节）、字段号或 wire type 非法（字段号 0、wire type 6/7）、varint 超过 10 字节、分组没有闭合。粘贴时漏掉或多写字节都会触发。
数据会被上传吗？
不会。解析完全在浏览器里用 JavaScript 完成，页面不发任何请求，敏感的二进制数据不会离开本机。
关键词：protobufprotocol bufferswire formatvarintzigzagdecodebinaryProtobuf 解码字段号二进制解析序列化gRPC