Inndata (.proto-skjema)

Utdata (JSON-eksempel)

Hva dette verktøyet gjør

Du har et Protocol Buffers-skjema og trenger et JSON-eksempel på hvordan en av de meldingene ser ut — til en test-fixture, et OpenAPI-eksempel, et stubbet gRPC-svar, hva som helst. Å skrive en JSON-form for hånd fra en lang .proto-fil er kjedelig og feilutsatt. Denne konvertereren leser skjemaet, plukker det sist deklarerte message-objektet (det vanlige "ytre" typen) og spytter ut et JSON-objekt som matcher felt for felt.

Utdataen bruker de offisielle proto3-defaultverdiene: tom streng for string og bytes, 0 for numeriske typer, false for bool, [] for repeated, {} for map, og nullverdi-enum-konstanten for enum-felt. Nestede meldinger ekspanderes rekursivt. 64-bits heltall kommer ut som JSON-strenger for å matche proto3 JSON-mapping-spesifikasjonen — du kan ikke putte int64 i et JS-Number uten å miste presisjon.

Alt skjer lokalt i nettleseren din — ingen .proto-opplasting, intet skjema sendt til en server, ingen inferenskall. Bare en håndskreven parser som håndterer syntax/package/import-direktiver, kommentarer (linje og blokk), nestede message- og enum-blokker, oneof, map<K, V>, repeated, optional og feltopsjoner (leses men ignoreres). Trenger du en full runtime i protobufjs-stil, er det et annet problem — men til "gi meg en JSON-form fra dette skjemaet" er dette raskere.

Slik bruker du det

Tre steg. Utdata-JSON er klar til å limes rett inn i en fixture, en eksempelblokk eller en request body.

Lim inn .proto-skjemaet

Slipp skjemaet i venstre editor. syntax = "proto3"; øverst er greit, men valgfritt — parseren bryr seg ikke. Kommentarer, package-deklarasjoner og import-setninger hoppes pent over. Har du flere meldinger, bruker parseren den siste message-deklarasjonen på toppnivå (typisk den ytre/sammensatte typen) som rot.

Vil du konvertere en annen melding? Flytt den du bryr deg om til bunnen av filen. Skjemaet kan inneholde nestede typer, enums og oneof-blokker — alt løses opp.

Trykk Convert

Klikk den grønne Convert-knappen. Parseren tokeniserer skjemaet, bygger et meldingstre og går rotmeldingen gjennom mens den skriver ut proto3-defaults for hvert felt. Nestede meldinger ekspanderes inline. repeated-felt produserer et array med ett element som hint om elementets form — tomme arrays ville ikke vist strukturen.

Bruk JSON

Kopier resultatet til test-fixturen din, OpenAPI-eksempelblokken, gRPC-Web-mocken, eller hvor du trenger en request/response-form. Nøklene matcher feltnavnene i .proto nøyaktig — bytt til camelCase etterpå om codegen-en din gjør det.

Når det faktisk sparer tid

Stubbe gRPC-svar til tester

Service-handleren din returnerer et Protobuf-svar. Enhetstesten trenger en JSON-fixture som matcher meldingens form. Lim inn <code>.proto</code>, ta JSON, slipp i fixtures-mappen. Slutt på å skrive 30 felt for hånd og glemme ett.

OpenAPI-eksempler for en gRPC-gateway

Kjører du grpc-gateway eller lignende for å eksponere Protobuf-tjenester som REST? Hver operasjon vil ha et JSON-eksempel. Konverter hver .proto-melding til et JSON-skjelett og lim inn under example-nøkkelen i specen din.

Bootstrappe JSON Schema

Du vil validere JSON-requester som matcher en <code>.proto</code>-kontrakt. Konverter først til et JSON-eksempel, gi det til et JSON-Schema-from-sample-verktøy, og du har et startskjema på sekunder.

Fylle ut request-bodies i API-klienter

Tester du et HTTP-transkodet gRPC-API i Postman eller med curl? Lim inn .proto, kopier JSON-skjelettet inn i request body, fyll ut verdiene du faktisk vil sende.

Vanlige spørsmål

Sendes .proto-skjemaet mitt noen steder?

Nei. Parsing skjer helt og holdent i nettleseren via JavaScript. Ingenting av skjemaet — meldingsnavn, feltnavn, package-stier — forlater maskinen din. Åpne DevTools og se på Network-fanen mens du klikker Convert. Null forespørsler.

Håndterer den proto2 like godt som proto3?

For det meste. Parseren håndterer proto2-syntakstokens som required og optional, men utdataverdiene bruker proto3-defaults (det proto3 JSON-mappingen spesifiserer). Har du en proto2-fil med eksplisitte defaults via [default = ...], anvendes de ikke på utdataen.

Hvordan velger den hvilken melding som skal konverteres?

Den bruker den siste message på toppnivå som er deklarert i filen. I ekte skjemaer deklareres den ytre/sammensatte typen som regel etter avhengighetene sine, så det treffer ofte det du vil ha. Tar den feil, omorganiser filen slik at meldingen du vil ha står sist.

Hvorfor er int64-verdier strenger i utdataen?

Fordi JSON bare har IEEE-754-doubles, som mister presisjon over 2^53. Den offisielle proto3 JSON-mappingen krever at int64, uint64, fixed64, sfixed64, sint64 kodes som JSON-strenger. Vi følger den konvensjonen.

Hva med oneof, map og repeated?

Alle tre fungerer. oneof-felt parses som vanlige felt (JSON-objektet får alle i stedet for å velge ett — typisk sletter du de du ikke vil ha). map<K, V> gir et tomt {}-objekt. repeated gir et array med ett element som viser elementets form — dupliser eller slett for å passe de ekte dataene dine.

Følger den imports?

Nei. import-setninger gjenkjennes og hoppes over. Meldingstyper på tvers av filer løses til null i utdataen. Trenger du oppløsning på tvers av filer, lim inn de relevante meldingene fra de importerte filene i samme inndata.

Hvor stort skjema kan den håndtere?

Titusenvis av linjer, ingen problem. Alt er lokalt, så det er ingen opplasting, ingen rate limit, ingen nettverkslatens.

Relaterte verktøy

Hvis du roter med Protobuf, JSON og skjemaer, passer disse godt sammen:

Protobuf til JSON-konverterer