Protobuf till Go-konverterare
Klistra in ett .proto-schema. Få Go-structar med rätt typer, struct-taggar och pointers för nästade meddelanden — redo att klistra in i ditt repo.
Indata (.proto-schema)
Utdata (Go)
Vad det här verktyget gör
Go är protobufs hemmaspråk — de flesta gRPC-tjänster i produktion är skrivna i det. Normalt genererar du Go från .proto med protoc-gen-go eller buf, vilket innebär att installera toolchainen, konfigurera en generator och köra ett build-steg. Den här konverteraren gör samma jobb i din webbläsare — klistra in, kopiera, släpp i ditt repo.
Typmappningen följer det protoc-gen-go spottar ut: string → string, bool → bool, bytes → []byte, heltalstyperna mappas till sina int32/int64/uint32/uint64-motsvarigheter (ingen precisionsförlust som i JavaScript), double → float64, float → float32. Singulära message-fält är pointers (i linje med konventionen för de officiella Go-protobuf-bindningarna), repeated T blir []T, map<K, V> blir map[K]V.
Fältnamn får Go-kanonisk PascalCase-behandling, med vanliga akronymer i versaler (order_id → OrderID, api_url → APIURL) enligt Go review style. Varje fält får färdiga struct-taggar: protobuf:"varint,3,opt,name=status,proto3" för wire-formatet och json:"status,omitempty" för JSON-marshalling. Konverteringen är lokal — ditt .proto lämnar aldrig webbläsaren. För produktionskod vill du fortfarande köra riktig codegen för att få metoder, descriptors och reflection-rörmokeri — men för skisser, granskningar och engångsskript är det här snabbare.
Så använder du det
Tre steg. Utdatan är klistrabar Go som kompilerar som den är med standardbiblioteket.
Klistra in ditt .proto-schema
Släpp schemat i den vänstra editorn. syntax = "proto3"; överst går bra men är frivilligt. Parsern hanterar nästade message-block, enum-deklarationer, oneof, map<K, V> och fältoptioner. Imports känns igen men hoppas över.
Fältnamn konverteras automatiskt från snake_case till PascalCase. Konverteraren stora-bokstavar vanliga akronymsuffix (Id → ID, Url → URL) så att utdatan passerar revive / golint utan klagomål.
Läs utdatan
Till höger: Go med en type X struct per message och ett type X int32 + const-block per enum. package proto överst är en platshållare — byt till ditt riktiga paketnamn.
Koppla in det i ditt projekt
Släpp filen i ditt projekt, fixa package-deklarationen och importera. För riktig gRPC-kod vill du fortfarande köra protoc-gen-go för att få marshal/unmarshal-metoderna. Den här utdatan är tänkt för typad JSON-hantering, struct-skisser och granskningar — protobufs wire-format-metoder genereras inte här.
När det faktiskt sparar tid
Skissa en Go-tjänst utifrån ett befintligt .proto
Du sätter ihop en Go-tjänst som konsumerar Protobuf-meddelanden från ett annat team. Du vill ha struct-formerna för handler-signaturer och JSON-svar utan att sätta upp hela codegen-pipelinen. Klistra in, släpp i types.go, du är typad.
Granska en Protobuf-API-ändring för en Go-konsument
En backend-kollega lade till fält i ett message. Klistra in det nya .proto, diffa Go-utdatan mot ditt nuvarande types.go, lämna en fokuserad granskning. Snabbare än att dra igång toolchainen bara för att titta på ändringen.
Sanity check mellan språk
Du har ett .proto som konsumeras av både Go- och TypeScript-klienter. Använd det här sida vid sida med Protobuf till TypeScript-konverteraren för att bekräfta att båda språken kommer se kompatibla fältnamn och typer efter JSON-kodning.
Engångsintegrationsskript
Du skriver ett 50-radigt Go-skript som slår mot en gRPC-gateway-endpoint. Att sätta upp protoc, buf och en generator-konfig för ett enda skript är överdrivet. Generera structarna här, släpp in dem, skicka iväg skriptet.
Vanliga frågor
Är det här en ersättare för protoc-gen-go?
Nej. protoc-gen-go spottar ut binära marshal/unmarshal-metoder, fildescriptors och det reflection-rörmokeri som behövs för riktig gRPC. Den här konverteraren spottar bara ut struct-formerna och taggarna. Skriver du en riktig gRPC-tjänst, kör den officiella codegen. Behöver du bara typer för JSON-svar, handgjorda skript eller skisser — det här är snabbare.
Varför är message-typade fält pointers?
Det speglar vad protoc-gen-go gör med proto3 message-fält — de är pointers så att zero value är nil (urskiljbart från ett närvarande men tomt message). Skalära fält stannar som värden eftersom deras zero values i sig är giltiga (tom sträng, 0, false). Föredrar du av någon anledning icke-pointer, gör find-replace på asteriskerna i utdatan.
Hur genereras enums?
Som Go-int32-typedef:er med ett const-block, i linje med protoc-gen-go-konventionerna. Varje enum-värde blir en PascalCase Go-konstant av den typen. De numeriska tilldelningarna kommer rakt från .proto.
Hur är det med protobufs struct-taggar?
Varje fält får en protobuf:"..."-tagg med wire-typen (varint, fixed32, fixed64, bytes), fältnummer, etikett (opt/rep), namn och proto3-markör. Plus en json:"name,omitempty"-tagg som använder originalets snake_case-namn. map<K, V>-taggar är förenklade — för strikt wire-format-kompatibilitet, kör riktig codegen.
Hur konverteras fältnamn?
snake_case → PascalCase, med vanliga akronymsuffix i versaler: order_id → OrderID, api_url → APIURL, data_json → DataJSON. Det matchar Go review-stilens konventioner så utdatan passerar lint utan manuell städning.
Vad om mitt schema importerar ett annat .proto?
import-satser känns igen och hoppas över — message-typer mellan filer renderas med sitt löv-namn (foo.Bar → Bar) som Go inte kommer kunna lösa upp om inte den typen också finns i samma paket. Antingen klistrar du in de importerade messagen inline, eller så räknar du med att fixa referenserna i utdatan.
Relaterade verktyg
Om du jobbar med Protobuf, JSON och Go fungerar dessa bra ihop: