Input (.proto-skema)

Output (JSON-eksempel)

Hvad værktøjet gør

Du har et Protocol Buffers-skema og skal bruge et JSON-eksempel på, hvordan en af de beskeder ser ud — til en test-fixture, et OpenAPI-eksempel, et stubbet gRPC-svar, hvad som helst. At skrive en JSON-form i hånden ud fra en lang .proto-fil er kedeligt og fejlfølsomt. Den her konverter læser skemaet, vælger det sidst deklarerede message (det typiske "ydre" type) og udsender et JSON-objekt, der matcher felt for felt.

Outputtet bruger de officielle proto3-defaultværdier: tom streng for string og bytes, 0 for numeriske typer, false for bool, [] for repeated, {} for map og nul-værdi-enum-konstanten for enum-felter. Indlejrede beskeder foldes rekursivt ud. 64-bit heltal kommer ud som JSON-strenge for at matche proto3 JSON-mapping-specifikationen — du kan ikke putte int64 i et JS-Number uden at miste præcision.

Alt sker lokalt i din browser — ingen .proto-upload, intet skema sendt til en server, ingen inferens-kald. Bare en håndskreven parser, der håndterer syntax/package/import-direktiver, kommentarer (linje og blok), indlejrede message- og enum-blokke, oneof, map<K, V>, repeated, optional og feltoptioner (læses men ignoreres). Skal du bruge en fuld runtime i protobufjs-stil, er det et andet problem — men til "giv mig en JSON-form ud fra det her skema" er det her hurtigere.

Sådan bruger du det

Tre trin. Output-JSON er klar til at blive sat ind i en fixture, en eksempelblok eller en request body direkte.

Indsæt dit .proto-skema

Smid skemaet ind i venstre editor. syntax = "proto3"; i toppen er fint, men valgfrit — parseren er ligeglad. Kommentarer, package-erklæringer og import-sætninger springes pænt over. Har du flere beskeder, bruger parseren det sidste message på topniveau (typisk det ydre/sammensatte type) som rod.

Vil du konvertere en anden besked? Flyt den, du går efter, ned i bunden af filen. Skemaet må indeholde indlejrede typer, enums og oneof-blokke — det hele bliver løst.

Tryk på Convert

Klik på den grønne Convert-knap. Parseren tokeniserer skemaet, bygger et beskedtræ og går rodbeskeden igennem mens den udsender proto3-defaults for hvert felt. Indlejrede beskeder foldes ud inline. repeated-felter producerer et array med ét element som hint om elementets form — tomme arrays ville ikke vise strukturen.

Brug JSON

Kopier resultatet til din test-fixture, din OpenAPI-eksempelblok, din gRPC-Web-mock eller hvor end du har brug for en request/response-form. Nøglerne matcher præcist feltnavnene i .proto — skift til camelCase bagefter, hvis din codegen gør det.

Hvornår det faktisk sparer tid

Stubbe gRPC-svar til tests

Din service handler returnerer et Protobuf-svar. Enhedstesten skal bruge en JSON-fixture, der matcher beskedens form. Indsæt <code>.proto</code>, tag JSON, smid den i fixtures-mappen. Slut med at skrive 30 felter i hånden og overse et.

OpenAPI-eksempler til en gRPC-gateway

Kører du grpc-gateway eller lignende for at eksponere Protobuf-services som REST? Hver operation vil have et JSON-eksempel. Konverter hver .proto-besked til et JSON-skelet og sæt det ind under example-nøglen i din spec.

Bootstrappe JSON Schema

Du vil validere JSON-requests, der matcher en <code>.proto</code>-kontrakt. Konverter først til et JSON-eksempel, giv det til et JSON-Schema-from-sample-værktøj, og du har et startskema på få sekunder.

Udfylde request-bodies i API-klienter

Tester du et HTTP-transkodet gRPC-API i Postman eller med curl? Indsæt .proto, kopier JSON-skelettet ind i request body, udfyld de værdier, du faktisk vil sende.

Almindelige spørgsmål

Bliver mit .proto-skema sendt nogen steder hen?

Nej. Parsing foregår udelukkende i din browser via JavaScript. Intet af dit skema — beskednavne, feltnavne, package-stier — forlader din maskine. Åbn DevTools og kig på Network-fanen, mens du klikker Convert. Nul requests.

Håndterer den proto2 lige så vel som proto3?

For det meste. Parseren håndterer proto2-syntakstokens som required og optional, men outputværdierne bruger proto3-defaults (det, som proto3 JSON-mapping specificerer). Har du en proto2-fil med eksplicitte defaults via [default = ...], anvendes de defaults ikke på outputtet.

Hvordan vælger den, hvilken besked der skal konverteres?

Den bruger den sidste message på topniveau, der er deklareret i filen. I rigtige skemaer er den ydre/sammensatte type som regel deklareret efter sine afhængigheder, så det passer med det, du vil have. Hvis den vælger den forkerte, omarrangér filen, så den ønskede besked står sidst.

Hvorfor er int64-værdier strenge i outputtet?

Fordi JSON kun har IEEE-754-doubles, som mister præcision over 2^53. Den officielle proto3 JSON-mapping kræver, at int64, uint64, fixed64, sfixed64, sint64 kodes som JSON-strenge. Vi følger den konvention.

Hvad med oneof, map og repeated?

Alle tre virker. oneof-felter parses som almindelige felter (JSON-objektet får dem alle i stedet for at vælge ét — typisk sletter du dem, du ikke vil have). map<K, V> giver et tomt {}-objekt. repeated giver et array med ét element, der viser elementets form — duplikér eller slet for at passe til dine rigtige data.

Følger den imports?

Nej. import-sætninger genkendes og springes over. Beskedtyper på tværs af filer opløses til null i outputtet. Skal du bruge opløsning på tværs af filer, indsæt de relevante beskeder fra de importerede filer i samme input.

Hvor stort et skema kan den klare?

Titusinder af linjer, intet problem. Alt er lokalt, så der er ingen upload, ingen rate limit, ingen netværkslatens.

Relaterede værktøjer

Hvis du roder med Protobuf, JSON og skemaer, passer disse godt sammen:

Protobuf til JSON-konverter