Entrada (esquema .proto)

Saída (amostra JSON)

O que esta ferramenta faz

Você tem um esquema Protocol Buffers e precisa de um exemplo JSON de como uma daquelas mensagens fica — para uma fixture de teste, um exemplo de OpenAPI, uma resposta gRPC mockada, qualquer coisa. Digitar à mão a forma JSON a partir de um .proto longo é tedioso e dá erro fácil. Este conversor lê o esquema, escolhe o último message declarado (o típico tipo "externo") e emite um objeto JSON correspondente, campo a campo.

A saída usa os valores padrão do proto3 oficiais: string vazia para string e bytes, 0 para tipos numéricos, false para bool, [] para repeated, {} para map, e a constante de enum com valor zero para campos enum. Mensagens aninhadas são expandidas recursivamente. Os inteiros de 64 bits saem como strings JSON para casar com a spec do mapeamento JSON do proto3 — não dá para colocar um int64 em um Number do JS sem perder precisão.

Tudo acontece localmente no navegador — sem upload do .proto, sem esquema mandado para servidor, sem chamada de inferência. Só um parser feito à mão que lida com diretivas syntax/package/import, comentários (linha e bloco), blocos aninhados de message e enum, oneof, map<K, V>, repeated, optional e opções de campo (lidas mas ignoradas). Se você precisa de um runtime completo estilo protobufjs, é outro problema — mas para "me dá um shape JSON deste esquema", isto é mais rápido.

Como usar

Três passos. O JSON de saída fica pronto para colar em uma fixture, num bloco de exemplo ou num body de requisição.

Cole seu esquema .proto

Solte o esquema no editor da esquerda. syntax = "proto3"; no topo é OK mas opcional — o parser não liga. Comentários, declarações de package e import são todos ignorados de forma limpa. Se você tem várias mensagens, o parser usa o último message de nível raiz (o típico tipo externo/composto) como root.

Quer converter outra mensagem? Mova a que te interessa para o final do arquivo. O esquema pode ter tipos aninhados, enums e blocos oneof — todos resolvem.

Aperte Convert

Clique no botão verde Convert. O parser tokeniza o esquema, monta uma árvore de mensagens e percorre a mensagem raiz emitindo os defaults do proto3 para cada campo. Mensagens aninhadas são expandidas inline. Campos repeated produzem um array com um elemento como dica do shape do elemento — array vazio não mostraria a estrutura.

Use o JSON

Copie o resultado para sua fixture de teste, seu bloco de exemplo do OpenAPI, seu mock de gRPC-Web ou onde precisar de um shape de request/response. As chaves batem exatamente com os nomes de campo do .proto — converta para camelCase depois se seu codegen fizer isso.

Quando isto realmente economiza tempo

Stub de respostas gRPC para testes

Seu handler de serviço retorna uma resposta Protobuf. O teste unitário precisa de uma fixture JSON que combine com o shape da mensagem. Cole o <code>.proto</code>, pegue o JSON, jogue na sua pasta de fixtures. Adeus a digitar 30 campos à mão e esquecer um.

Exemplos OpenAPI para um gRPC-gateway

Está rodando grpc-gateway ou similar para expor serviços Protobuf como REST? Cada operação precisa de um exemplo JSON. Converta cada mensagem .proto para um esqueleto JSON e cole sob a chave example na sua spec.

Bootstrap de JSON Schema

Você quer validar requisições JSON que correspondam a um contrato <code>.proto</code>. Converta primeiro para uma amostra JSON, passe para uma ferramenta de JSON-Schema-from-sample e tem um esquema inicial em segundos.

Preencher request bodies em clientes de API

Testando uma API gRPC transcodificada por HTTP no Postman ou com curl? Cole o .proto, copie o esqueleto JSON no body da requisição, preencha os valores que você realmente quer mandar.

Perguntas comuns

Meu esquema .proto vai para algum lugar?

Não. O parsing acontece inteiramente no navegador via JavaScript. Nada do seu esquema — nomes de mensagens, nomes de campos, paths de package — sai da sua máquina. Abra o DevTools e olhe a aba Network enquanto clica em Convert. Zero requisições.

Funciona com proto2 também ou só proto3?

Em grande parte, sim. O parser lida com tokens da sintaxe proto2 como required e optional, mas os valores de saída usam os defaults do proto3 (que é o que o mapeamento JSON do proto3 especifica). Se você tem um arquivo proto2 com defaults explícitos via [default = ...], esses defaults não são aplicados na saída.

Como ele decide qual mensagem converter?

Ele usa o último message de nível raiz declarado no arquivo. Em esquemas reais o tipo externo/composto costuma ser declarado depois das suas dependências, então isto bate com o que você quer. Se ele pegar a errada, reordene o arquivo para que a mensagem desejada fique por último.

Por que valores int64 são strings na saída?

Porque JSON só tem doubles IEEE-754, que perdem precisão acima de 2^53. O mapeamento JSON do proto3 oficial pede que int64, uint64, fixed64, sfixed64, sint64 sejam codificados como strings JSON. Seguimos essa convenção.

E quanto a oneof, map e repeated?

Os três funcionam. Campos oneof são parseados como campos normais (o objeto JSON inclui todos em vez de escolher um — você normalmente apaga os que não quer). map<K, V> emite um objeto {} vazio. repeated emite um array de um elemento mostrando o shape do elemento — você duplica ou apaga conforme seus dados reais.

Ele segue imports?

Não. Instruções import são reconhecidas e ignoradas. Tipos de mensagem entre arquivos resolvem para null na saída. Se precisa de resolução entre arquivos, cole as mensagens relevantes dos arquivos importados na mesma entrada.

Quão grande pode ser o esquema?

Dezenas de milhares de linhas, sem problema. Tudo é local, então não há upload, rate limit nem latência de rede.

Ferramentas relacionadas

Se você está mexendo com Protobuf, JSON e esquemas, estas combinam bem:

Conversor de Protobuf para JSON