01
根消息不是文件名
默认选择源码中首个 message，枚举和服务不会被当作 JSON 根节点。参数区列出完整消息路径，适合存在多个嵌套同名类型的文件。编辑源码后会重置为首个消息，避免继续引用已改名或已删除的旧根节点。
Protocol Buffers 定义
Protobuf 格式化
输入一份无需导入的 proto3 定义，在结构树、排版源码和 JSON 形状之间切换，字段编号保持原样。
Protobuf 格式化
Proto3 源码
结果
源码仅在当前浏览器处理，不加载导入文件，也不发送网络请求。
选项
仅支持单文件 proto3 子集；不加载 import、不处理自定义选项，不进行编译或兼容性检查。修改源码会重置根消息。
上限：100,000 个 UTF-16 字符、20,000 个词法单元、2,000 个声明、32 层嵌套；超时为 8 秒。
结果已过期，复制和下载已禁用。
使用 Protobuf 格式化整理一段紧凑的协议定义时，缩进只是第一步。字段编号有没有重复、预留号是否被重新使用、某个类型能否在当前文件找到，都需要在导出前核对。这个工作台把这些受支持的检查与源码排版放在一次运行里。
结构树展示的是声明关系：原始字段名、wire 编号、类型及其完整路径。JSON Schema 则描述所选消息的一种 JSON 数据形状。两种结果解决不同问题；字段历史、服务接口及运行时行为仍以原始协议和工程配置为准。
为什么使用 Protobuf 格式化工具
同名类型也能分清来源
Protobuf 格式化保留嵌套声明与字段顺序，并在结构树中显示引用的完整名称。OuterA.Item 与 OuterB.Item 不会因为末尾名字一样就合成一个定义。循环引用显示为类型路径，浏览树时不会无限展开。
按根消息审阅转换结果
一个文件可以包含多个消息。切换根消息后，导出结果用 $ref 指向相应定义，其他消息保留在 $defs 中。数组、map 与 oneof 的关系可以直接查看，方便在接入前发现自己选错了根消息或误解了字段形状。
检查前先确认这三件事
02
树的折叠不改变导出内容
点击声明旁的箭头展开或折叠，点击行号返回源码位置。长列表每次显示 50 个可见条目。复制结构树时导出完整声明列表，折叠节点与尚未显示的条目也包含在内，不需要先逐个展开。
03
自动与手动共用同一份状态
输入停顿 350 毫秒后自动检查；关闭开关才显示主按钮，并支持 Ctrl/Cmd + Enter。修改源码、缩进或根消息会立即禁用旧结果导出。示例和清空先显示替换字符数，应用后可撤销，同时恢复输入和结果。
源码检查与数据形状各看什么
排版保留协议标识
Protocol Buffers IDL 格式化提供 2 或 4 个空格缩进。字符串里的分号、花括号以及注释文本不会被当作结构符号处理。字段名、编号和声明顺序保持原样，结果放在独立区域；导出前还会重新解析排版结果，核对它与原定义的结构一致。
编号与枚举分别验证
Protobuf 验证要求消息字段号为正整数，在同一消息内唯一，并避开 19000–19999。reserved 写在字段之前或之后都会参与检查。proto3 枚举的首个值必须为零，数字别名需要 allow_alias，枚举名与数字预留冲突也会阻止导出。
引用显示完整路径
结构树列出 package、message、enum、oneof、service 和 RPC。前向引用、循环消息以及嵌套类型都在当前文件内解析。找不到类型就报错，不会用宽松的任意对象占位；字段在树中保留 snake_case 原名，便于与源码逐项对照。
按受支持规则转换 Schema
proto 转 JSON Schema 输出 2020-12 文档，使用完整名称组织 $defs。repeated 映射为数组，map 映射为对象，int64 映射为字符串。oneof 允许零个或一个成员出现，两个同时出现则不符合约束；不会擅自把普通字段或 optional 标成必填。
语法范围与转换边界
- 显式 proto3 与单文件输入
- 首条声明必须是 syntax = "proto3";。本版不支持 proto2、Editions、required、group 或 extensions，也拒绝所有 import，包括 Timestamp、Any 等内置常见类型的导入。需要依赖文件的定义应交给带完整目录配置的工程工具链检查。
- 选项只接受明确支持的部分
- 支持常见文件级代码生成选项，以及合法位置上的 json_name、packed、deprecated 和 allow_alias。自定义选项、聚合选项、校验注解与 CEL 表达式会被拒绝。保留代码生成设置不意味着会把这些设置转换成 JSON Schema 的业务校验规则。
- JSON 投影不等于运行时校验
- 输出描述常见 ProtoJSON 输出形状，不覆盖以 null 表示未设置、数字枚举或宽松数字字符串输入。十进制字符串模式没有完整检查 64 位数值范围，contentEncoding 也只是 base64 注解。用它校验真实业务数据前，需要补充项目所需的范围与内容约束。
- 不自动修复协议契约
- 排版不会重新编号、删除预留项或回写输入。单份当前文件无法知道历史版本是否曾用过某个字段号；本工具也不进行 protoc 编译、Buf 风格检查、破坏性变更检测、客户端生成或 OpenAPI 输出。当前检查通过只代表所列范围内没有发现问题。
- 超过上限会停止处理
- 每次最多接受 100,000 个 UTF-16 字符、20,000 个词法单元、2,000 个声明和 32 层嵌套。结果上限为 1,000,000 个字符，工作线程在 8 秒后超时终止。不会悄悄截断源码再把残缺结果显示为成功。
- 这里接收定义而不是消息内容
- 输入应为 .proto 声明，不是二进制、Base64 或 TextFormat 消息。可导出源码、结构报告或 JSON Schema，但不会解码业务数据。本版也没有反向 Schema 转换、批量文件、远程加载或把源码放进分享链接的入口。
Protobuf 格式化常见问题
字段编号可以从零开始吗？
不可以。消息字段号的有效范围从 1 到 536870911，其中 19000 到 19999 保留给实现使用。不要把消息编号与枚举值混为一谈：proto3 枚举的第一个声明值反而必须是零。本工具按声明类型分别检查，错误会指向相应的字段或枚举位置。
字段编号中间可以留空吗？
可以，编号不需要连续。字段 1 后面直接声明字段 20 并不构成错误，只要没有重复或命中预留范围。排版会保留这些空档与原顺序。若某个号曾用于已删除的字段，应通过 reserved 明确保留；单纯留空不能记录过去的使用历史。
proto3 怎样声明可选字段？
在字段类型前使用 optional，可以让生成代码保留显式的存在性信息。结构树会展示这个声明。导出的 JSON Schema 中，普通单值字段和 optional 字段都允许缺省；它不能表达生成代码里的 has 方法，也不等同于运行时对未设置值与默认值的区分。
为什么 int64 在 JSON 中是字符串？
JavaScript 的普通数字无法精确表示所有 64 位整数，因此常见 ProtoJSON 输出用十进制字符串保留值。导出遵循这种形状，不先把整数转换为 Number。字符串模式只检查基本写法，确切的有符号或无符号范围需要额外核对。
import 路径明明正确，为什么还是失败？
编译器要根据配置的导入根目录寻找文件，只有一段路径文本还不够。此工作台没有文件树或依赖解析环境，因此明确拒绝所有 import。包含依赖的工程应交给配置好目录的 protoc 或 Buf；工具不会尝试联网获取，也不会跳过导入后显示完整通过。
遇到了应当支持的协议定义？