Eingabe (.proto-Schema)

Ausgabe (formatiertes .proto)

Was dieses Tool macht

Du fügst ein Protocol Buffers-Schema mit gemischter Einrückung, zusammengequetschten Felddeklarationen oder zufälligen Leerzeilen aus einem Copy-Paste ein und willst, dass es aussieht wie der Rest deiner Codebasis. Dieser Formatter schreibt die Datei mit zwei Leerzeichen Einrückung pro Klammerebene neu, mit genau einem Leerzeichen um =, einem Leerzeichen nach , und höchstens einer aufeinanderfolgenden Leerzeile zwischen Blöcken. Kommentare — sowohl //-Zeilenkommentare als auch /* ... */-Blockkommentare — bleiben genau dort, wo du sie gesetzt hast.

Er parst und validiert das Schema nicht, das heißt er funktioniert auch auf leicht kaputten Eingaben, an denen buf format oder das „Format Document" deines Editors scheitern könnten. Wenn dein .proto irgendwo einen Syntaxfehler hat, wird der Rest der Datei trotzdem drumherum formatiert. Der Trade-off: Er kann keine Felder umsortieren, keine Import-Reihenfolge normalisieren und keine ungenutzten Optionen entfernen, wie es ein echter parserbasierter Formatter könnte. Dafür schmeiß buf format in deine Build-Pipeline.

Alles läuft in deinem Browser — kein Upload, kein Rate Limit, kein Schema wird irgendwohin geschickt. Praktisch, wenn das Schema interne Paketnamen, Typnamen oder sonst etwas enthält, das du nicht an eine fremde API schicken willst. Funktioniert mit jeder Dateigröße, die dein Browser im Speicher halten kann; selbst zehntausende Zeilen sind in deutlich unter einer Sekunde formatiert.

So benutzt du es

Drei Schritte. Die Ausgabe aktualisiert ungefähr 300 ms, nachdem du aufhörst zu tippen.

1

Füge dein .proto-Schema ein

Wirf das Schema in den linken Editor. syntax, package, import-Direktiven, message-Blöcke, verschachtelte enums, oneof, map<K, V> — alles wird verarbeitet. Gemischte Zeilenenden (CRLF) werden auf dem Weg nach draußen zu LF normalisiert.

Der Formatter sortiert nichts um — Felder, Imports und Optionen bleiben in der Reihenfolge, in der du sie geschrieben hast. Wenn du eine kanonische Reihenfolge brauchst, lass danach buf format drüberlaufen.

2

Lies die formatierte Ausgabe

Rechts: dasselbe Schema, eingerückt mit 2 Leerzeichen pro {-Ebene. Zeilen, die mit } anfangen, werden vor der Ausgabe ausgerückt. Mehrere aufeinanderfolgende Leerzeilen werden auf eine zusammengefasst. Trailing Whitespace wird entfernt. Kommentare bleiben wortwörtlich erhalten, einschließlich ihrer relativen Position.

3

Nutze das Ergebnis

Kopiere es zurück in deinen Editor oder lade es als formatted.proto herunter. Aus Sicht von protoc ist die Ausgabe Byte für Byte äquivalent zur Eingabe — nur Whitespace ändert sich — du kannst es also einfach zurücklegen, ohne dir Sorgen über Wire-Format- oder Codegenerierungs-Unterschiede zu machen. Verifiziere es, indem du protoc --descriptor_set_out=before.pb input.proto und dasselbe auf der formatierten Ausgabe laufen lässt: Die Descriptors sind identisch.

Wann das wirklich Zeit spart

Aus Chat oder Doku eingefügtes .proto aufräumen

Ein Teamkollege fügt einen Schema-Schnipsel im Slack ein, die Einrückung ist zerschossen, und du willst es im Repo. Hier reinwerfen, formatierte Version kopieren, in deine Datei einfügen. Schneller als der „alles markieren, neu tabben"-Tanz im Editor.

Legacy-.proto-Dateien in einem alten Repo standardisieren

Du hast ein Protobuf-Repo geerbt, in dem jede Datei eine andere Einrückung benutzt. Lass jede Datei durch diesen Formatter laufen, push das als einen einzigen Normalisierungs-Commit und schalte dann buf format in CI ein, damit es so bleibt.

Schnell ein generiertes .proto checken

Manche Codegeneratoren (JSON Schema → Protobuf, OpenAPI → Protobuf) spucken gültige, aber hässliche Schemas aus. Formatiere die Ausgabe, schau drauf, entscheide, ob du den Generator behältst oder per Hand nachbesserst.

Wenn du protoc oder buf nicht installieren kannst

Du sitzt an einer abgeschlossenen Maschine, in einem Gastnetz, oder reviewst gerade nur einen PR im Browser. Der Browser-only-Formatter gibt dir dieselbe lesbare Ausgabe, ohne dass du die Protocol Buffers-Toolchain installieren musst.

Häufige Fragen

Wird mein Schema irgendwohin geschickt?

Nein. Der Formatter läuft komplett in deinem Browser als JavaScript. Nichts vom Schema — Message-Namen, Paketpfade, Kommentare — verlässt deine Maschine. Öffne die DevTools und schau auf den Network-Tab, während du einfügst; du wirst null Requests sehen.

Bleiben Kommentare erhalten?

Ja — sowohl //-Einzeilenkommentare als auch /* ... */-Blockkommentare bleiben genau dort, wo du sie gesetzt hast. Kommentare in eigenen Zeilen behalten ihre relative Position; Trailing-Kommentare am Ende einer Feldzeile bleiben an dem Feld kleben. Der zeilenbasierte Ansatz wurde genau deswegen gewählt, damit Kommentare unbeschadet überleben.

Was ist der Unterschied zu buf format?

buf format parst das Schema in einen Syntaxbaum und gibt es neu aus. Das gibt stärkere Garantien — kanonische Optionsreihenfolge, einheitliche Enum-Schreibweise etc. — setzt aber voraus, dass das Schema sauber parst. Dieser Formatter ist zeilenbasiert, funktioniert also auch auf leicht kaputten Eingaben, die buf ablehnen würde, und erzwingt keine kanonische Reihenfolge. Für fertigen Code lass buf format laufen. Für Schemas, an denen du gerade arbeitest, oder fremde Fragmente nimm diesen hier.

Ändert er die Semantik des Schemas?

Nein — nur Whitespace ändert sich. protoc würde aus Eingabe und Ausgabe denselben FileDescriptorProto erzeugen. Du kannst das mit protoc --descriptor_set_out=before.pb input.proto gegen denselben Aufruf auf der formatierten Datei prüfen; die binären Descriptors sind identisch, abgesehen von eventuellen Source-Info-Span-Änderungen (das sind Reflection-Metadaten, kein Wire-Format).

Was ist mit der Einrückungsbreite — kann ich von 2 Leerzeichen weg?

Die Ausgabe ist fest auf 2 Leerzeichen pro Klammerebene eingestellt, passend zur Konvention im offiziellen Protocol-Buffers-Styleguide. Wenn du 4 Leerzeichen oder Tabs brauchst, lass die Ausgabe durch sed oder die Tab-Konvertierung deines Editors laufen. Die Ausgabe des Formatters kanonisch zu halten vermeidet Konfigurations-Drift zwischen Teams.

Werden CRLF-Zeilenenden behandelt?

Ja — eingegebenes CRLF (\r\n) wird auf dem Weg nach draußen zu LF (\n) normalisiert. Wenn du in der gespeicherten Datei CRLF brauchst, kodiert dein Editor beim Speichern entsprechend seiner Zeilenenden-Einstellung um.

Verwandte Tools

Wenn du mit Protobuf-Schemas arbeitest, passen diese gut dazu: