Eingabe (.proto-Schema)

Ausgabe (JSON-Beispiel)

Was dieses Tool macht

Du hast ein Protocol Buffers-Schema und brauchst ein JSON-Beispiel davon, wie eine dieser Messages aussieht — für eine Test-Fixture, ein OpenAPI-Beispiel, eine gestubte gRPC-Antwort, was auch immer. Eine JSON-Form aus einer langen .proto-Datei von Hand abzutippen ist mühsam und fehleranfällig. Dieser Konverter liest das Schema, nimmt das zuletzt deklarierte message (typischerweise der "äußere" Typ) und gibt feldweise ein passendes JSON-Objekt aus.

Die Ausgabe benutzt die offiziellen proto3-Default-Werte: leerer String für string und bytes, 0 für numerische Typen, false für bool, [] für repeated, {} für map und die Null-Enum-Konstante für enum-Felder. Verschachtelte Messages werden rekursiv aufgeklappt. 64-Bit-Integer kommen als JSON-Strings raus, passend zur proto3-JSON-Mapping-Spec — du kannst int64 nicht ohne Präzisionsverlust in eine JS-Number stecken.

Alles passiert lokal im Browser — kein .proto-Upload, kein Schema, das an einen Server geht, kein Inferenz-Aufruf. Nur ein selbstgebauter Parser, der mit syntax/package/import-Direktiven, Kommentaren (Zeile und Block), verschachtelten message- und enum-Blöcken, oneof, map<K, V>, repeated, optional und Feld-Optionen (gelesen, aber ignoriert) umgeht. Wenn du eine vollwertige Runtime im Stil von protobufjs brauchst, ist das ein anderes Thema — aber für "gib mir eine JSON-Form aus diesem Schema" ist das hier schneller.

So benutzt du es

Drei Schritte. Das ausgegebene JSON kannst du direkt in eine Fixture, einen Beispielblock oder einen Request-Body kleben.

.proto-Schema einfügen

Wirf das Schema in den linken Editor. syntax = "proto3"; ganz oben ist okay, aber optional — den Parser interessiert das nicht. Kommentare, package-Deklarationen und import-Anweisungen werden alle sauber übersprungen. Wenn du mehrere Messages hast, nimmt der Parser das letzte message auf oberster Ebene (typischerweise der äußere/komponierte Typ) als Wurzel.

Willst du eine andere Message konvertieren? Verschiebe die gewünschte Message ans Ende der Datei. Das Schema kann verschachtelte Typen, Enums und oneof-Blöcke enthalten — alles wird aufgelöst.

Auf Convert klicken

Klick auf den grünen Convert-Button. Der Parser tokenisiert das Schema, baut einen Message-Baum und läuft die Wurzel-Message ab, wobei er für jedes Feld proto3-Defaults ausgibt. Verschachtelte Messages werden inline aufgeklappt. repeated-Felder erzeugen ein Array mit einem Element als Hinweis auf die Element-Form — leere Arrays würden die Struktur nicht zeigen.

JSON benutzen

Kopier das Ergebnis in deine Test-Fixture, deinen OpenAPI-Beispielblock, deinen gRPC-Web-Mock oder wo immer du eine Request/Response-Form brauchst. Die Schlüssel passen exakt zu den Feldnamen aus dem .proto — auf camelCase umstellen kannst du später, falls dein Codegen das so macht.

Wann das wirklich Zeit spart

gRPC-Antworten für Tests stuben

Dein Service-Handler liefert eine Protobuf-Antwort zurück. Der Unit-Test braucht eine JSON-Fixture, die zur Message passt. <code>.proto</code> einfügen, JSON greifen, in den Fixtures-Ordner werfen. Schluss damit, 30 Felder von Hand zu tippen und eines zu vergessen.

OpenAPI-Beispiele für ein gRPC-gateway

Du fährst grpc-gateway oder Ähnliches, um Protobuf-Services als REST anzubieten? Jede Operation braucht ein JSON-Beispiel. Konvertier jede .proto-Message in ein JSON-Skelett und kleb es unter den example-Schlüssel deiner Spec.

JSON Schema starten

Du willst JSON-Requests gegen einen <code>.proto</code>-Vertrag validieren. Erst in ein JSON-Beispiel konvertieren, das einem JSON-Schema-aus-Beispiel-Tool geben — und du hast in Sekunden ein Start-Schema.

Request-Bodies in API-Clients ausfüllen

Testest du eine HTTP-transcodierte gRPC-API in Postman oder mit curl? .proto einfügen, JSON-Skelett in den Request-Body kopieren, die Werte ausfüllen, die du wirklich senden willst.

Häufige Fragen

Wird mein .proto-Schema irgendwohin geschickt?

Nein. Das Parsing passiert komplett im Browser per JavaScript. Nichts von deinem Schema — Message-Namen, Feldnamen, Package-Pfade — verlässt deine Maschine. Mach die DevTools auf und schau auf den Network-Tab, während du Convert klickst. Null Requests.

Geht proto2 genauso wie proto3?

Größtenteils. Der Parser kommt mit proto2-Syntax-Tokens wie required und optional klar, aber die Ausgabewerte nutzen proto3-Defaults (das, was das proto3-JSON-Mapping vorgibt). Wenn du eine proto2-Datei mit explizit gesetzten Defaults via [default = ...] hast, werden diese Defaults nicht in die Ausgabe übernommen.

Wie wählt es, welche Message es konvertiert?

Es nimmt das letzte top-level message, das in der Datei deklariert ist. In echten Schemas wird der äußere/komponierte Typ meistens nach seinen Abhängigkeiten deklariert, also passt das oft zu dem, was du willst. Wenn die falsche genommen wird, sortier die Datei so um, dass die gewünschte Message ganz unten steht.

Warum sind int64-Werte in der Ausgabe Strings?

Weil JSON nur IEEE-754-Doubles kennt, die ab 2^53 an Präzision verlieren. Das offizielle proto3-JSON-Mapping verlangt, dass int64, uint64, fixed64, sfixed64, sint64 als JSON-Strings codiert werden. Wir folgen dieser Konvention.

Was ist mit oneof, map und repeated?

Alle drei funktionieren. oneof-Felder werden wie normale Felder geparst (das JSON-Objekt enthält alle, statt eins auszuwählen — du löschst typischerweise die, die du nicht willst). map<K, V> liefert ein leeres {}-Objekt. repeated liefert ein Array mit einem einzigen Element, das die Element-Form zeigt — duplizieren oder löschen, um deine echten Daten abzubilden.

Verfolgt es imports?

Nein. import-Anweisungen werden erkannt und übersprungen. Message-Typen aus anderen Dateien lösen in der Ausgabe zu null auf. Wenn du dateiübergreifende Auflösung brauchst, kleb die relevanten Messages aus den importierten Dateien in dieselbe Eingabe.

Wie groß darf das Schema werden?

Zehntausende Zeilen, kein Problem. Alles ist lokal, also gibt es keinen Upload, kein Rate Limit, keine Netzwerk-Latenz.

Protobuf-zu-JSON-Konverter