Inmatning (JSON)

Utdata (.proto-schema)

Vad det här verktyget gör

Har du en riktig JSON-payload — ett exempelsvar från ett API, en webhook-body, en rad från en NoSQL-store — och vill modellera den som ett Protocol Buffers-meddelande? Att skriva schemat för hand är segt och lätt att göra fel på, särskilt när det finns nästade objekt och arrayer. Den här konverteraren går igenom JSON:en, inferera Protobuf-typer för varje fält och spottar ur sig ett rent proto3-schema som du kan klistra rakt in i ditt projekt.

Typinferensen följer det du själv skulle skriva: string för strängar, bool för booleaner, int32 för heltal som ryms i 32 bitar, int64 för resten, double för icke-heltal, repeated <T> för arrayer med en enhetlig elementtyp (ett nästat meddelande återanvänds för arrayer av objekt) och nästade message-block för nästade objekt. JSON skiljer inte på en struct och en map, så alla objekt blir nästade meddelanden — byt själv till map<K, V> om dina data faktiskt är en map.

Fältnamn konverteras från camelCase eller kebab-case till det Protobuf-konventionella snake_case. Fältnummer tilldelas 1, 2, 3, … i deklarationsordning. Utdatan är giltig proto3 — klistra in den i en .proto-fil, kör protoc eller buf, så har du genererad kod på det språk du väljer. Konverteringen körs helt i din webbläsare — ingen JSON, inga fältnamn, inga värden skickas någonstans.

Så använder du det

Tre steg. Funkar med vilket välformat JSON-objekt som helst — API-svar, loggrader, fixturfiler, vad som helst.

Klistra in din JSON

Släpp in JSON i den vänstra editorn. Roten måste vara ett objekt ({ ... }) — om dina data är array-rotade, packa in dem i ett objekt först, t.ex. { "items": [...] }. Använd realistiska data: ju mer representativt provet är, desto bättre matchar de inferera typerna det du vill ha på sikt.

Om din JSON har okvoterade nycklar, kommatecken på slutet eller andra konstigheter, kör den genom JSON Fixer först — Protobuf vill ha ett rent objekt att utgå från.

Tryck Konvertera

Klicka på den gröna Konvertera-knappen. Konverteraren går igenom varje nyckel i JSON, väljer en Protobuf-typ, bygger nästade message-block för nästade objekt och spottar ur sig schemat med syntax = "proto3"; överst. Fältnummer tilldelas i källordning.

Använd .proto-filen

Kopiera schemat till en .proto-fil i ditt repo. Gå igenom de inferera typerna — för fält där JSON-provet var tomt (tom array, null) ser du en kommentar som flaggar att typen är gissad. Justera där det behövs och kör sedan protoc eller buf generate för att producera kod på ditt språk.

När det faktiskt sparar tid

Modellera ett tredjeparts-API som Protobuf

En leverantör returnerar JSON. Din tjänst lagrar Protobuf. Ta ett riktigt svar, klistra in här, få ett startschema för typen och finslipa sedan. Bättre än att läsa dokumentationen och knappa in 50 fält för hand.

Migrera en JSON-baserad tjänst till gRPC

Du flyttar en HTTP+JSON-mikrotjänst till gRPC. Varje request- och response-form behöver en .proto. Konvertera varje uppfångad payload till ett Protobuf-schema, klistra in dem i en enda fil och kontraktet är skissat.

Bootstrappa en Buf-modul

Sätter du upp en ny Buf-modul och behöver realistiska scheman att börja med? Konvertera dina befintliga JSON-fixturer och använd utdatan som frö till dina .proto-filer — mycket snabbare än att skriva dem från scratch.

Skriva testfixturer för Protobuf-kod

Ditt team har testdata i JSON. Den nya koden konsumerar Protobuf. Generera <code>.proto</code> från JSON och låt din codegen bygga typerna — fixturer och kod hålls i synk.

Vanliga frågor

Skickas min JSON någonstans?

Nej. Konverteraren körs helt i din webbläsare som JavaScript. Din JSON — nycklar, värden, allt känsligt — lämnar aldrig din maskin. Öppna DevTools och kolla Network-fliken medan du klickar Konvertera. Noll requests.

Hur väljer den mellan int32, int64 och double?

För heltalsvärden kollar den om värdet ryms i ett signed 32-bitars-intervall (-2^31 till 2^31-1). Om ja, int32. Om nej, int64. Tal som inte är heltal blir alltid double. Vet du att din data är osignerad eller vill ha en specifik bredd som fixed32, redigera utdatan — se tabellen över skalära typer för alla tillgängliga numeriska typer och deras wire-encoding-avvägningar.

När blir ett objekt en map istället för ett nästat meddelande?

Alltid ett nästat meddelande — aldrig en map. JSON skiljer inte struct och map, så att gissa det ena eller det andra blir fel ungefär hälften av gångerna. Är dina data faktiskt en nyckel-värde-map (t.ex. metadata, headers, feature-flaggor), öppna utdatan och byt själv ut message Foo { ... } mot map<string, V> foo = N;. Fixen är mekanisk och uppenbar så fort du ser dina data.

Vad gäller för null och tomma arrayer?

Båda producerar en kommentar i utdatan som flaggar att typen gissats utifrån ett urartat prov. null faller tillbaka på string med en "nullable"-notering. Tomma arrayer faller tillbaka på repeated string med en "empty array"-notering. Byt ut de typerna mot det du faktiskt förväntar dig.

Varför renderas arrayer med blandade typer som repeated string?

Protobuf stöder inte heterogena listor direkt. Om din JSON-array har blandade typer (några strängar, några tal) finns ingen ren Protobuf-motsvarighet — du behöver antingen google.protobuf.Value, ett oneof, eller bygga om dataformen. Konverteraren flaggar det med en kommentar så att du får bestämma.

Klarar den djupt nästad JSON?

Ja. Varje nästat objekt blir ett nästat message med ett härlett PascalCase-namn. Nästningsdjupet begränsas bara av stackdjupet, inte av konverteraren — även mycket nästade API-svar konverteras snyggt.

Kan jag åka tur och retur JSON ↔ Protobuf med dessa två verktyg?

Mestadels. JSON till Protobuf ger dig ett schema; Protobuf till JSON ger dig ett prov. Formerna stämmer för fält där JSON-provet hade ett representativt värde. Där JSON hade null eller tomma arrayer är den inferera Protobuf-typen en gissning, och tur-och-retur stämmer först exakt efter att du fixat typen.

Relaterade verktyg

Om du tampas med JSON och scheman passar dessa bra ihop:

JSON till Protobuf-konverterare