Eingabe (JSON)

Ausgabe (.proto-Schema)

Was dieses Tool tut

Du hast eine echte JSON-Payload — eine API-Antwort, einen Webhook-Body, eine Zeile aus einem NoSQL-Store — und willst sie als Protocol-Buffers-Message modellieren? Das Schema von Hand zu tippen ist zäh und fehleranfällig, vor allem mit verschachtelten Objekten und Arrays. Dieser Konverter läuft durch das JSON, leitet für jedes Feld einen Protobuf-Typ ab und liefert ein sauberes proto3-Schema, das du direkt ins Projekt übernehmen kannst.

Die Typinferenz folgt dem, was du selbst schreiben würdest: string für Strings, bool für Booleans, int32 für Ganzzahlen, die in 32 Bit passen, int64 für den Rest, double für Nicht-Ganzzahlen, repeated <T> für Arrays mit einheitlichem Elementtyp (eine verschachtelte Message wird für Arrays von Objekten wiederverwendet) und verschachtelte message-Blöcke für verschachtelte Objekte. JSON unterscheidet nicht zwischen Struct und Map, deshalb werden alle Objekte als verschachtelte Messages ausgegeben — tausch sie per Hand gegen map<K, V>, wenn deine Daten wirklich eine Map sind.

Feldnamen werden von camelCase oder kebab-case in das in Protobuf übliche snake_case umgesetzt. Feldnummern werden in Deklarationsreihenfolge mit 1, 2, 3, … vergeben. Die Ausgabe ist gültiges proto3 — füge sie in eine .proto-Datei ein, lass protoc oder buf laufen, und du hast generierten Code in der Sprache deiner Wahl. Die Konvertierung läuft komplett im Browser — kein JSON, keine Feldnamen, keine Werte werden irgendwohin gesendet.

So benutzt du es

Drei Schritte. Funktioniert mit jedem wohlgeformten JSON-Objekt — API-Antworten, Log-Einträgen, Fixture-Dateien, was auch immer.

JSON einfügen

Wirf das JSON in den linken Editor. Die Wurzel muss ein Objekt sein ({ ... }) — wenn deine Daten ein Array als Wurzel haben, pack es zuerst in ein Objekt, z. B. { "items": [...] }. Nimm realistische Daten: je repräsentativer die Probe, desto besser passen die abgeleiteten Typen langfristig zu dem, was du wirklich willst.

Wenn dein JSON Schlüssel ohne Anführungszeichen, Trailing Commas oder andere Macken hat, schick es zuerst durch den JSON Fixer — Protobuf braucht ein sauberes Objekt zum Arbeiten.

Konvertieren drücken

Klick den grünen Konvertieren-Button. Der Konverter läuft jeden Schlüssel im JSON ab, wählt einen Protobuf-Typ, baut für verschachtelte Objekte verschachtelte message-Blöcke und gibt das Schema mit syntax = "proto3"; oben aus. Feldnummern werden in Quellreihenfolge vergeben.

.proto verwenden

Kopiere das Schema in eine .proto-Datei in deinem Repo. Prüfe die abgeleiteten Typen — bei Feldern, in denen die JSON-Probe leer war (leeres Array, null), siehst du einen Kommentar, der den Typ als geraten markiert. Passe das an und führ dann protoc oder buf generate aus, um Code in deiner Sprache zu erzeugen.

Wann das wirklich Zeit spart

Eine Fremd-API als Protobuf modellieren

Ein Anbieter liefert JSON. Dein Service speichert Protobuf. Nimm eine echte Antwort, füg sie hier ein, hol dir ein Start-Schema für den Typ und feile dann nach. Schlägt das Lesen der Doku und 50 Felder von Hand zu tippen.

Einen JSON-basierten Service auf gRPC migrieren

Du ziehst einen HTTP+JSON-Microservice auf gRPC um. Jede Request- und Response-Form braucht eine .proto. Konvertiere jede mitgeschnittene Payload in ein Protobuf-Schema, klatsch sie in eine Datei, und du hast den Vertrag skizziert.

Ein Buf-Modul aufsetzen

Du baust ein neues Buf-Modul auf und brauchst realistische Schemas zum Anfangen? Konvertiere deine vorhandenen JSON-Fixtures und nutze die Ausgabe als Saatgut für deine .proto-Dateien — viel schneller, als von Null an zu tippen.

Test-Fixtures für Protobuf-Code schreiben

Dein Team hat JSON-Testdaten. Der neue Code konsumiert Protobuf. Generier die <code>.proto</code> aus dem JSON und lass dein Codegen daraus Typen erzeugen — Fixtures und Code bleiben synchron.

Häufige Fragen

Wird mein JSON irgendwohin gesendet?

Nein. Der Konverter läuft komplett im Browser als JavaScript. Dein JSON — Schlüssel, Werte, alles Sensible — verlässt deinen Rechner nie. Öffne die DevTools und schau auf den Network-Tab, während du Konvertieren klickst. Null Requests.

Wie wird zwischen int32, int64 und double entschieden?

Für Ganzzahlen wird geprüft, ob der Wert in einen vorzeichenbehafteten 32-Bit-Bereich passt (-2^31 bis 2^31-1). Wenn ja, int32. Wenn nicht, int64. Nicht-ganzzahlige Zahlen werden immer zu double. Wenn du weißt, dass deine Daten vorzeichenlos sind, oder eine bestimmte Breite wie fixed32 willst, bearbeite die Ausgabe — siehe die Skalar-Typtabelle für alle verfügbaren numerischen Typen und ihre Wire-Encoding-Trade-offs.

Wann wird ein Objekt zu einer Map statt zu einer verschachtelten Message?

Immer eine verschachtelte Message — nie eine Map. JSON unterscheidet nicht zwischen Struct und Map, also liegt man beim Raten ungefähr in der Hälfte der Fälle daneben. Wenn deine Daten tatsächlich eine Key-Value-Map sind (z. B. Metadaten, Header, Feature-Flags), öffne die Ausgabe und ersetze message Foo { ... } per Hand durch map<string, V> foo = N;. Der Fix ist mechanisch und offensichtlich, sobald du die Daten siehst.

Was ist mit null und leeren Arrays?

Beides erzeugt einen Kommentar in der Ausgabe, der vermerkt, dass der Typ aus einer entarteten Probe geraten wurde. null wird standardmäßig zu string mit einem "nullable"-Hinweis. Leere Arrays werden standardmäßig zu repeated string mit einem "empty array"-Hinweis. Tausche diese Typen gegen das aus, was du tatsächlich erwartest.

Warum werden Arrays mit gemischten Typen als repeated string ausgegeben?

Protobuf unterstützt heterogene Listen nicht direkt. Wenn dein JSON-Array gemischte Typen hat (manche Strings, manche Zahlen), gibt es kein sauberes Protobuf-Äquivalent — du brauchst entweder google.protobuf.Value, ein oneof oder ein Refactoring der Datenform. Der Konverter markiert das mit einem Kommentar, damit du entscheiden kannst.

Kommt es mit tief verschachteltem JSON klar?

Ja. Jedes verschachtelte Objekt wird zu einer verschachtelten message mit einem abgeleiteten PascalCase-Namen. Die Verschachtelungstiefe ist nur durch die Stack-Tiefe begrenzt, nicht durch den Konverter — selbst stark verschachtelte API-Antworten werden sauber konvertiert.

Kann ich mit diesen beiden Tools JSON ↔ Protobuf hin und zurück fahren?

Größtenteils ja. JSON zu Protobuf liefert dir ein Schema; Protobuf zu JSON liefert eine Probe. Die Formen passen bei Feldern, in denen die JSON-Probe einen repräsentativen Wert hatte. Wo das JSON null oder leere Arrays hatte, ist der inferierte Protobuf-Typ geraten, und der Round-Trip stimmt erst exakt, nachdem du den Typ korrigiert hast.

JSON-zu-Protobuf-Konverter