Definições Protocol Buffers

Formatador Protobuf

Examine uma definição proto3 independente como árvore, código formatado ou estrutura JSON. Os números dos campos permanecem iguais.

Formatador Protobuf

Código proto3

Resultado

    O código fica no navegador. Nenhum import é carregado e nenhuma solicitação de rede é enviada.

    Opções

    Subconjunto proto3 em um único arquivo. Sem imports, opções personalizadas, compilação ou teste de compatibilidade. Editar o código redefine a raiz.

    Limites: 100.000 caracteres UTF-16, 20.000 tokens, 2.000 declarações e 32 níveis; tempo máximo de 8 segundos.

    Resultado desatualizado. A exportação está desativada.

    Um formatador Protobuf ajuda a revisar contratos difíceis de ler, mas uma boa indentação não identifica sozinha um número reservado ou um tipo desconhecido. O painel executa as verificações suportadas antes de liberar os resultados para exportação.

    A árvore mostra os nomes originais, as tags de transmissão e os caminhos completos dos tipos. O JSON Schema descreve uma forma de dados para a mensagem escolhida. Preserve o contrato original para consultar serviços, reservas antigas e comportamentos que não cabem nessa projeção.

    Por que usar este formatador Protobuf?

    Tipos de mesmo nome continuam separados

    O formatador Protobuf mantém a ordem das declarações e exibe referências com o nome completo. OuterA.Item e OuterB.Item não viram a mesma definição. Referências recursivas aparecem como caminhos, sem abrir indefinidamente a mesma estrutura na árvore.

    Um documento de código ligado a uma árvore com mensagens aninhadas distintas.

    Escolha a mensagem que será consumida

    Quando o arquivo contém várias mensagens, a raiz determina o $ref principal. Os tipos compartilhados ficam em $defs. Isso permite comparar listas, mapas e campos de contato exclusivos sem copiar a mesma definição em vários lugares ou perder a identidade de um tipo.

    Dois tipos aninhados semelhantes levam a definições de esquema separadas.

    Três pontos para uma revisão consistente

    01

    A raiz é uma mensagem, não o arquivo

    A primeira declaração message é usada inicialmente, mesmo que existam enums e serviços. O seletor apresenta nomes completos. Ao editar o código, a seleção volta ao início para não manter como raiz um tipo que acabou de ser removido ou renomeado.

    02

    Navegar não reduz a exportação

    Expanda ou recolha declarações e use os números de linha para voltar ao código. A árvore mostra lotes de 50 entradas visíveis. Copiar ou baixar a estrutura inclui todas as declarações, também as recolhidas e as que ainda não apareceram na tela.

    03

    Espere o resultado ficar atual

    A verificação automática aguarda 350 ms após a edição. Desativá-la mostra o botão principal e habilita Ctrl/Cmd + Enter. Alterações bloqueiam imediatamente o resultado antigo. Exemplo e Limpar exibem uma prévia com a quantidade de caracteres; Desfazer recupera código e resultado juntos.

    O que aparece em cada resultado

    Formatar arquivos proto preservando as tags

    Escolha recuo de dois ou quatro espaços. Comentários e conteúdo de strings são mantidos; chaves e ponto e vírgula dentro deles não viram delimitadores de estrutura. Nomes, números e ordem dos campos ficam intactos. A saída é analisada novamente e seu descritor é comparado ao original antes de permitir a exportação.

    Conferir números de campos e reservas

    As tags devem ser positivas, únicas dentro da mensagem e fora de 19000–19999. Declarações reserved posteriores aos campos também são verificadas. Um enum proto3 precisa começar em zero e aliases numéricos exigem allow_alias. Os controles tratam do arquivo atual, sem presumir a história das versões anteriores.

    Ler esquemas Protobuf com tipos resolvidos

    A árvore reúne package, message, enum, oneof, service e RPC. Referências antecipadas, tipos aninhados e mensagens recursivas são resolvidos no mesmo arquivo. Um tipo ausente interrompe a geração. O nome snake_case continua visível na árvore mesmo quando a propriedade JSON usa lowerCamelCase.

    Gerar uma projeção JSON Schema limitada

    O documento 2020-12 usa nomes completos em $defs. repeated vira array, map vira objeto e int64 vira string. Um grupo oneof aceita nenhum ou apenas um membro presente, nunca dois. Campos simples e optional podem ser omitidos; required não é acrescentado automaticamente.

    Escopo suportado e limites da projeção

    Um arquivo com proto3 explícito
    Comece com syntax = "proto3";. Proto2, Editions, required, group e extensions não são suportados. Todos os imports são rejeitados, inclusive Timestamp e Any. Definições com dependências precisam ser verificadas com os arquivos e caminhos de busca do próprio projeto.
    Opções padrão em posições válidas
    São aceitas opções comuns de geração de código por arquivo e usos suportados de json_name, packed, deprecated e allow_alias. Opções personalizadas ou agregadas, anotações de validação e CEL são rejeitados. Preservar configurações de geração não cria regras de negócio no JSON Schema.
    A projeção não é um parser ProtoJSON completo
    A saída representa formas comuns, não todas as entradas que um runtime pode aceitar. Null como ausência, enums numéricos e leitura permissiva de strings numéricas ficam fora. Padrões de inteiros textuais não conferem todo o intervalo de 64 bits, e contentEncoding base64 é uma anotação. Acrescente as restrições necessárias no projeto.
    Sem reparos automáticos no contrato
    O código não é sobrescrito durante a formatação; números e reservas não são alterados. Um arquivo atual não revela quais tags foram usadas no passado. Compilação protoc, Buf lint, detecção de alterações incompatíveis, geração de clientes e saída OpenAPI pertencem às ferramentas do projeto.
    Limites por execução
    O processamento aceita 100.000 caracteres UTF-16, 20.000 tokens, 2.000 declarações e 32 níveis de aninhamento. A saída vai até 1.000.000 de caracteres e o worker é encerrado após oito segundos. Exceder um limite gera erro, sem truncar o arquivo e anunciar sucesso com dados incompletos.
    Definições em vez de mensagens codificadas
    Cole declarações .proto, não dados binários, Base64 ou TextFormat. A saída é código, relatório de estrutura ou esquema, nunca um payload decodificado. Não há conversão inversa de JSON Schema, processamento de lotes, carregamento remoto ou links de compartilhamento com o código.

    Dúvidas sobre o formatador Protobuf

    Os números dos campos podem começar em zero?

    Não. Tags de mensagens vão de 1 a 536870911, excluindo 19000–19999, reservados para a implementação. Valores de enum têm outra função: a primeira declaração em proto3 precisa valer zero. A ferramenta verifica essas regras separadamente para não confundir uma tag inválida com um valor de enumeração necessário.

    Posso deixar intervalos entre os números dos campos?

    Sim. As tags não precisam ser consecutivas. Um campo 1 seguido do campo 20 é válido se não houver conflito ou reserva. A formatação mantém os intervalos e a ordem. Para impedir a reutilização de um número antigo, registre-o em reserved. Um espaço na sequência não documenta sozinho o uso anterior.

    Como declarar um campo opcional em proto3?

    Coloque optional antes do tipo para obter informação explícita de presença no código gerado. A árvore mantém essa indicação. No JSON Schema exportado, tanto campos simples quanto optional podem faltar. Ele não representa o método has gerado nem a diferença entre ausência e o valor padrão devolvido pelo runtime.

    Por que int64 aparece como string em JSON?

    Números JavaScript não representam com precisão todos os inteiros de 64 bits. As saídas ProtoJSON comuns usam strings decimais, e a projeção mantém essa forma sem converter para Number. O padrão verifica a escrita do valor; a faixa exata de inteiros com ou sem sinal exige uma verificação adicional.

    Por que o import falha se o caminho está correto?

    O compilador procura arquivos em diretórios de importação configurados. Este painel não tem árvore de arquivos nem resolvedor de dependências e rejeita cada import explicitamente. Use protoc ou Buf com o projeto completo. O caminho não é baixado nem ignorado para produzir uma aparência de validação completa.

    Encontrou uma definição que deveria ser suportada?

    Revise a próxima mudança de esquema

    Use o formatador Protobuf para examinar as declarações suportadas e levar o código e a forma JSON revisada ao projeto. A compilação final ainda precisa de todas as dependências.