Inndata (JSON)

Utdata (.proto-skjema)

Hva verktøyet gjør

Har du en ekte JSON-payload — et eksempelsvar fra et API, en webhook-body, en rad fra et NoSQL-store — og vil modellere det som en Protocol Buffers-message? Å skrive skjemaet for hånd er tregt og lett å trå feil i, særlig når det er nestede objekter og arrayer. Denne konverteren går gjennom JSON-en, utleder Protobuf-typer for hvert felt og gir deg et rent proto3-skjema som du kan lime rett inn i prosjektet ditt.

Type-utledningen følger det du selv ville skrevet: string for strenger, bool for boolean-er, int32 for heltall som passer i 32 bit, int64 for resten, double for ikke-heltall, repeated <T> for arrayer med en enhetlig elementtype (én nestet message gjenbrukes for arrayer av objekter) og nestede message-blokker for nestede objekter. JSON skiller ikke struct fra map, så alle objekter kommer ut som nestede messages — bytt selv til map<K, V> hvis dataene dine faktisk er en map.

Feltnavn konverteres fra camelCase eller kebab-case til det Protobuf-konvensjonelle snake_case. Feltnummer tildeles 1, 2, 3, … i deklarasjonsrekkefølge. Utdataen er gyldig proto3 — lim den inn i en .proto-fil, kjør protoc eller buf, og du har generert kode på det språket du velger. Konverteringen kjører helt i nettleseren — ingen JSON, ingen feltnavn, ingen verdier sendes noe sted.

Slik bruker du det

Tre steg. Funker med ethvert velformet JSON-objekt — API-svar, loggrader, fixture-filer, hva som helst.

Lim inn JSON-en din

Slipp JSON-en inn i editoren til venstre. Roten må være et objekt ({ ... }) — pakk en array inn i et objekt først hvis dataene dine starter med en array, f.eks. { "items": [...] }. Bruk realistiske data: jo mer representativ prøven er, desto bedre matcher de utledede typene det du faktisk vil ha på sikt.

Hvis JSON-en har usiterte nøkler, hengende komma eller andre rariteter, kjør den gjennom JSON Fixer først — Protobuf vil ha et rent objekt å jobbe ut fra.

Trykk Konverter

Klikk den grønne Konverter-knappen. Konverteren går gjennom hver nøkkel i JSON-en, velger en Protobuf-type, bygger nestede message-blokker for nestede objekter og gir ut skjemaet med syntax = "proto3"; øverst. Feltnummer tildeles i kilderekkefølge.

Bruk .proto-filen

Kopier skjemaet inn i en .proto-fil i repoen din. Gå gjennom de utledede typene — for felter der JSON-prøven var tom (tom array, null) ser du en kommentar som flagger at typen er gjettet. Juster der det trengs, og kjør så protoc eller buf generate for å produsere kode i ditt språk.

Når det faktisk sparer tid

Modellere et tredjeparts-API som Protobuf

En leverandør returnerer JSON. Tjenesten din lagrer Protobuf. Ta et ekte svar, lim det inn her, få et startskjema for typen, og pusse det opp etterpå. Bedre enn å lese dokumentasjonen og hamre inn 50 felt for hånd.

Migrere en JSON-basert tjeneste til gRPC

Du flytter en HTTP+JSON-microservice til gRPC. Hver request- og response-form trenger en .proto. Konverter hver fanget payload til et Protobuf-skjema, lim dem i én fil, og kontrakten er skissert.

Bootstrappe en Buf-modul

Setter du opp en ny Buf-modul og trenger realistiske skjemaer å starte med? Konverter eksisterende JSON-fixtures og bruk utdataen som frø til .proto-filene dine — mye raskere enn å skrive dem fra bunnen.

Skrive test-fixtures for Protobuf-kode

Teamet ditt har testdata i JSON. Den nye koden konsumerer Protobuf. Generer <code>.proto</code> fra JSON-en, og la codegen bygge typene — fixtures og kode holdes i synk.

Vanlige spørsmål

Sendes JSON-en min noe sted?

Nei. Konverteren kjører helt i nettleseren som JavaScript. JSON-en din — nøkler, verdier, alt sensitivt — forlater aldri maskinen din. Åpne DevTools og se på Network-fanen mens du klikker Konverter. Null requests.

Hvordan velger den mellom int32, int64 og double?

For heltallsverdier sjekker den om verdien får plass i et fortegnsmessig 32-bit-intervall (-2^31 til 2^31-1). Hvis ja, int32. Hvis nei, int64. Tall som ikke er heltall blir alltid double. Vet du at dataene dine er fortegnsløse eller ønsker en bestemt bredde som fixed32, så rediger utdataen — se tabellen over skalartyper for alle tilgjengelige numeriske typer og deres wire-encoding-avveininger.

Når blir et objekt en map i stedet for en nestet message?

Alltid en nestet message — aldri en map. JSON skiller ikke struct fra map, så å gjette på det ene eller andre bommer omtrent halvparten av tiden. Hvis dataene dine faktisk er en nøkkel-verdi-map (f.eks. metadata, headers, feature flags), åpne utdataen og bytt selv ut message Foo { ... } med map<string, V> foo = N;. Fiksen er mekanisk og opplagt så snart du ser dataene dine.

Hva med null og tomme arrayer?

Begge gir en kommentar i utdataen som flagger at typen er gjettet ut fra et degenerert utvalg. null faller tilbake på string med en "nullable"-merknad. Tomme arrayer faller tilbake på repeated string med en "empty array"-merknad. Bytt ut de typene med det du faktisk forventer.

Hvorfor rendres arrayer med blandede typer som repeated string?

Protobuf støtter ikke heterogene lister direkte. Hvis JSON-arrayen din har blandede typer (noen strenger, noen tall) finnes ingen ren Protobuf-ekvivalent — du trenger enten google.protobuf.Value, en oneof, eller å skrive om dataformen. Konverteren flagger det med en kommentar slik at du kan bestemme.

Takler den dypt nestet JSON?

Ja. Hvert nestet objekt blir en nestet message med et avledet PascalCase-navn. Nestedybden er bare begrenset av stakkdybden, ikke av konverteren — selv svært nestede API-svar konverteres pent.

Kan jeg ta en tur-retur JSON ↔ Protobuf med disse to verktøyene?

Stort sett. JSON til Protobuf gir deg et skjema; Protobuf til JSON gir deg et utvalg. Formene stemmer for felter der JSON-utvalget hadde en representativ verdi. Der JSON hadde null eller tomme arrayer, er den utledede Protobuf-typen en gjetning, og tur-retur vil først være presis etter at du har rettet typen.

Relaterte verktøy

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

JSON til Protobuf-konverterer