Indata (.proto-schema)

Utdata (JSON-exempel)

Vad det här verktyget gör

Du har ett Protocol Buffers-schema och behöver ett JSON-exempel på hur ett av meddelandena ser ut — för en test-fixture, ett OpenAPI-exempel, ett stubbat gRPC-svar, vad som helst. Att skriva en JSON-form för hand från en lång .proto-fil är trist och felbenäget. Den här konverteraren läser schemat, plockar det sista deklarerade message:t (det vanliga "yttre" typen) och spottar ut ett JSON-objekt som matchar fält för fält.

Utdatan använder de officiella proto3-defaultvärdena: tom sträng för string och bytes, 0 för numeriska typer, false för bool, [] för repeated, {} för map och nollvärdes-enumkonstanten för enum-fält. Nästlade meddelanden expanderas rekursivt. 64-bitars heltal kommer ut som JSON-strängar för att matcha proto3-JSON-mappningsspecen — du kan inte stoppa int64 i ett JS-Number utan att tappa precision.

Allt händer lokalt i din webbläsare — ingen .proto-uppladdning, inget schema som skickas till en server, inget inferensanrop. Bara en handskriven parser som hanterar syntax/package/import-direktiv, kommentarer (rad och block), nästlade message- och enum-block, oneof, map<K, V>, repeated, optional och fältoptioner (läses men ignoreras). Behöver du en fullständig runtime i protobufjs-stil är det ett annat problem — men för "ge mig en JSON-form från det här schemat" är det här snabbare.

Så använder du det

Tre steg. Utdata-JSON är redo att klistras in i en fixture, ett exempelblock eller en request body direkt.

Klistra in ditt .proto-schema

Släpp schemat i vänstra editorn. syntax = "proto3"; överst är okej men valfritt — parsern bryr sig inte. Kommentarer, package-deklarationer och import-satser hoppas alla över rent. Har du flera meddelanden använder parsern det sista message på toppnivå (det typiska yttre/sammansatta typen) som rot.

Vill du konvertera ett annat meddelande? Flytta det du bryr dig om till botten av filen. Schemat får innehålla nästlade typer, enums och oneof-block — allt löses upp.

Tryck på Convert

Klicka på den gröna Convert-knappen. Parsern tokeniserar schemat, bygger ett meddelandeträd och vandrar rotmeddelandet medan den skriver ut proto3-defaults för varje fält. Nästlade meddelanden expanderas inline. repeated-fält producerar en array med ett element som ledtråd om elementets form — tomma arrayer skulle inte visa strukturen.

Använd JSON:en

Kopiera resultatet till din test-fixture, ditt OpenAPI-exempelblock, din gRPC-Web-mock eller där du behöver en request/response-form. Nycklarna matchar exakt fältnamnen i .proto — växla till camelCase sedan om din codegen gör det.

När det faktiskt sparar tid

Stubba gRPC-svar för tester

Din service handler returnerar ett Protobuf-svar. Enhetstestet behöver en JSON-fixture som matchar meddelandets form. Klistra in <code>.proto</code>, ta JSON:en, släng den i fixtures-mappen. Slut på att skriva 30 fält för hand och missa ett.

OpenAPI-exempel för en gRPC-gateway

Kör du grpc-gateway eller liknande för att exponera Protobuf-tjänster som REST? Varje operation vill ha ett JSON-exempel. Konvertera varje .proto-meddelande till ett JSON-skelett och klistra in under example-nyckeln i din spec.

Bootstrappa JSON Schema

Du vill validera JSON-requests som matchar ett <code>.proto</code>-kontrakt. Konvertera först till ett JSON-exempel, ge det till ett JSON-Schema-from-sample-verktyg och du har ett startschema på sekunder.

Fyll i request-bodies i API-klienter

Testar du ett HTTP-transkodat gRPC-API i Postman eller med curl? Klistra in .proto, kopiera JSON-skelettet till request body, fyll i värdena du faktiskt vill skicka.

Vanliga frågor

Skickas mitt .proto-schema någonstans?

Nej. Parsningen sker helt i din webbläsare via JavaScript. Inget av ditt schema — meddelandenamn, fältnamn, package-paths — lämnar din maskin. Öppna DevTools och titta på Network-fliken medan du klickar Convert. Noll requests.

Hanterar den proto2 lika bra som proto3?

Mestadels. Parsern hanterar proto2-syntaxtokens som required och optional, men utdatavärdena använder proto3-defaults (det som proto3 JSON-mappningen specificerar). Har du en proto2-fil med explicita defaults via [default = ...] appliceras de inte på utdatan.

Hur väljer den vilket meddelande som ska konverteras?

Den använder det sista message på toppnivå som deklareras i filen. I riktiga scheman deklareras den yttre/sammansatta typen oftast efter sina beroenden, så det stämmer med vad du vill ha. Om den väljer fel, sortera om filen så att meddelandet du vill ha hamnar sist.

Varför är int64-värden strängar i utdatan?

För att JSON bara har IEEE-754-doubles, som tappar precision över 2^53. Den officiella proto3 JSON-mappningen kräver att int64, uint64, fixed64, sfixed64, sint64 kodas som JSON-strängar. Vi följer den konventionen.

Hur är det med oneof, map och repeated?

Alla tre fungerar. oneof-fält parsas som vanliga fält (JSON-objektet får alla istället för att välja en — typiskt raderar du de du inte vill ha). map<K, V> ger ett tomt {}-objekt. repeated ger en array med ett element som visar elementets form — duplicera eller radera för att passa din riktiga data.

Följer den imports?

Nej. import-satser känns igen och hoppas över. Meddelandetyper mellan filer löses upp till null i utdatan. Behöver du upplösning över filer, klistra in de relevanta meddelandena från de importerade filerna i samma indata.

Hur stort schema klarar den?

Tiotusentals rader, inga problem. Allt är lokalt, så det är ingen uppladdning, ingen rate limit, ingen nätverkslatens.

Relaterade verktyg

Om du brottas med Protobuf, JSON och scheman passar dessa bra ihop:

Protobuf till JSON-konverterare