Protobuf 解码
Protobuf Decoder
没有 .proto 文件也能解码 protobuf 数据，推断字段号、wire type 和嵌套结构。
不用 `.proto` 文件解码 protobuf 载荷。它读线路格式——字段号、wire type、嵌套——并把每个值所有合法的读法并排显示，因为没有 schema 的时候读法确实不止一种。
负载
把二进制负载拖进来
在这个标签页里解码，什么都不会上传。
字段
顶层字段
3
总大小
17 B
- #1VARINT@0, 3 Buint 150 · zigzag 75
- #2LEN@3, 9 B"testing"
- #3LEN@12, 5 B消息（1个字段）
- #1VARINT@0, 3 Buint 150 · zigzag 75
当作 JSON 看（名字的位置放字段号）
.proto 文件就没有字段名，同一段负载可以有几种成立的读法：varint 会同时按无符号、有符号和 zigzag 三种给出，带长度的字段会按消息、文本、字节三种给出。画面上的嵌套是每个字节都刚好对齐的那种读法；别的读法印在旁边，不藏起来。怎么用
粘贴字节或拖入文件
带空格或不带空格的十六进制，或 Base64。也可以改为拖入一个最大 32 MB 的二进制文件。
读字段列表
每一行给出字段号、wire type、字节偏移和长度，以及各种读法。嵌套消息缩进在它的父级下面。
拿 JSON 投影
同一棵树的 JSON 形式，用字段号代替名字。适合对比两份载荷，或者粘进 issue 里。
常见问题
为什么没有字段名？
因为 protobuf 不把它们放到线路上。编码后的消息只带字段*号*——名字在 `.proto` 文件里，这正是这种格式紧凑的原因，也正是无 schema 解码只能给你看数字的原因。
为什么一个值显示了三种不同的样子？
因为线路上的 varint 只是一串位：同样的字节既是合法的 `uint64`，也是合法的 `int64`，也是合法的 zigzag `sint64`，只有 schema 才说是哪一种。显示一种、藏起其他的，就是把猜测当事实呈现。
它怎么判定一个字段是嵌套消息？
一个带长度前缀的字段可以是消息、字符串或原始字节。当它的内容能完整解析——每个字节都被消耗，没有剩余——就显示为消息，字节同时也是可打印文本时，字符串读法会一并打印在旁边。偶尔一个短字符串会碰巧解析成消息；两种读法都在，你能分辨。
它能解码 gRPC 流量吗？
消息体可以，前提是你先把前面五个字节的 gRPC 帧头——一个压缩标志和一个四字节大端长度——去掉。把那之后的字节喂进来，它就正常解码。
可以从这些接进来
十六进制查看器
Hex Viewer
把任意文件展成偏移／十六进制／ASCII 三栏，用魔数判断格式，并高亮搜索命中的位置。
JSON 格式化与校验
JSON Formatter & Validator
把 JSON 美化成缩进形式或压成一行，校验语法并直接指出出错的行和列。
YAML 格式化与校验
YAML Formatter & Validator
统一 YAML 缩进并校验语法，把会让解析器崩掉的制表符和锚点错误标出来。
TOML 格式化与校验
TOML Formatter & Validator
格式化并校验 TOML，统一表的排列顺序和内联表的写法。
接下来
这些工具吃得下当前工具的产出，结果可以直接送过去。
Base64 编码解码
Base64 Encoder & Decoder
对文本和文件做 Base64 与 Base64URL 编解码，UTF-8 处理正确。
十六进制查看器
Hex Viewer
把任意文件展成偏移／十六进制／ASCII 三栏，用魔数判断格式，并高亮搜索命中的位置。
JSON 格式化与校验
JSON Formatter & Validator
把 JSON 美化成缩进形式或压成一行，校验语法并直接指出出错的行和列。
JSON ⇄ CSV 互转
JSON ⇄ CSV
把嵌套 JSON 按点路径列名拍平成列，或者从表格重新拼回对象。
JSON 对比
JSON Diff
按结构比较两份 JSON，忽略键的顺序，报出新增、删除和改动的路径。
JSON 转 TypeScript 类型
JSON to TypeScript
从一份 JSON 样例推断 TypeScript 接口或类型，合并可选字段和联合类型。