Eingabe (.proto-Schema)

Ausgabe (Validierungsbericht)

Was dieses Tool macht

Du speicherst eine Protocol-Buffers-Datei, lässt protoc oder buf laufen, und der Build stirbt mit einer kryptischen Zeilen-/Spaltenmeldung. Dieser Validator parst dein .proto mit denselben Regeln, die ein strenger Compiler anwendet, und sagt dir in Klartext, was schiefläuft — bevor du commitest und die CI-Pipeline es für dich entdeckt.

Über das reine "wurde geparst?" hinaus läuft ein Lint-Durchlauf mit den Checks, die die Spec tatsächlich verlangt: Feldnummern müssen in 1..536870911 liegen, der Bereich 19000..19999 ist intern von Google reserviert, jede Feldnummer in einer Message muss eindeutig sein, und Feldnamen dürfen sich nicht wiederholen. Genau diese Verstöße erzeugen die echten Build-Failures, und der Validator zeigt sie alle auf einmal — nicht ein Fehler nach dem anderen wie der Compiler.

Alles läuft in deinem Browser — dein .proto, deine Message-Namen, deine Package-Pfade verlassen deinen Rechner nie. Der Parser handhabt syntax-/package-/import-Direktiven, Zeilen- und Block-Kommentare, verschachtelte message- und enum-Blöcke, oneof, map<K, V>, repeated, optional, Services (übersprungen) und Field Options. Gebaut für denselben Workflow wie der offizielle proto3-Sprachleitfaden.

Wie du es benutzt

Drei Schritte, läuft beim Tippen. Der Output-Editor aktualisiert ~300 ms nach dem Tippstop.

Füge dein .proto-Schema ein

Wirf das Schema in den linken Editor — eine einzelne Datei, beliebig lang. syntax = "proto3"; oben ist okay, aber optional. Der Parser kennt import-Statements (sie werden übersprungen — dateiübergreifende Auflösung ist hier nicht im Scope; falls du importierte Messages mit validieren willst, klebe sie inline rein). Alle Kommentare werden vor dem Parsen entfernt.

Wenn dein Editor beim Einfügen typografische Anführungszeichen einfügt, kann der Validator einen Tokenisierungsfehler werfen. Entferne sie oder füge aus einer reinen Textquelle ein.

Lies den Bericht

Rechts: ein grüner Haken, wenn das Schema sauber ist, sonst eine Liste der Probleme. Jedes Problem zeigt auf die exakte Message und das exakte Feld, sodass du im Editor reparieren kannst, ohne zu greppen. Der Bericht summiert außerdem Message-Anzahl, Enum-Anzahl und Gesamtfeldanzahl.

Reparieren und neu einfügen

Wende den Fix im Editor an, füge das aktualisierte Schema ein. Der Output revalidiert in unter einer Sekunde. Kein Reload, kein Rebuild, kein Warten auf rote CI. Wenn das Schema sauber ist, kopiere den Bericht in einen PR-Kommentar, falls du die Validierung dokumentieren willst.

Wann das wirklich Zeit spart

Fehler abfangen, bevor du auf CI pushst

Dein Team lässt buf lint in der CI laufen. Vorher lokal zu validieren bedeutet: kein push, warten, rot sehen, fixen, push — der ganze Zyklus schrumpft auf einen Browser-Tab.

Ein Protobuf-PR von Kollegen reviewen

Du reviewst eine Schema-Änderung, hast aber keine protoc-Toolchain lokal installiert. Klebe das neue .proto hier rein, prüfe, ob es strukturell sauber ist, und hinterlasse ein fokussiertes Review statt eines "sieht gut aus, ship".

Von proto2 auf proto3 migrieren

Alte Schemas verwenden oft required (in proto3 weg) oder haben Feldnummern, die okay aussehen, bis man sie überprüft. Der Validator findet Duplikate und Out-of-Range-Nummern in einem Durchgang, was schneller ist, als 800 Zeilen .proto per Hand zu lesen.

Ein generiertes .proto aus einem Code-Gen-Tool prüfen

Generatoren (z. B. JSON Schema → Protobuf, OpenAPI → Protobuf) produzieren manchmal Schemas mit Edge-Case-Fehlern — doppelte Feldnummern, Treffer im reservierten Bereich. Schick den Output durch den Validator, bevor du ihm vertraust.

Häufige Fragen

Wird mein .proto-Schema an einen Server geschickt?

Nein. Parser und Lint-Checks laufen komplett in deinem Browser als JavaScript. Öffne die DevTools und schau in den Network-Tab, während du einfügst — null Requests. Praktisch für Schemas mit internen Typnamen, Package-Pfaden oder allem, was du nicht an einen fremden Validator schicken willst.

Was prüft der Lint-Pass eigentlich?

Feldnummern müssen in 1..536870911 liegen (ohne den von Google reservierten Bereich 19000..19999), jede Feldnummer in einer Message muss eindeutig sein, und jeder Feldname in einer Message muss eindeutig sein. Alles, was an einer dieser Regeln scheitert, wird mit dem exakten Pfad message.field gemeldet. Der Parser scheitert außerdem an fehlenden Semikolons, nicht passenden Klammern, unerwarteten Tokens etc.

Validiert es gegen die proto3- oder proto2-Spec?

Es akzeptiert beide Syntaxen (proto3 default-zero, proto2 required/optional-Qualifier etc.). Die Lint-Checks sind in der Spec definiert und gelten für beide. Die strengsten Checks wie "kein required in proto3" werden hier nicht erzwungen — protoc selbst fängt die ein.

Warum wird meine Feldnummer 19000 markiert?

Der Bereich 19000..19999 ist intern von Google für die Protocol-Buffers-Implementierung reserviert. Wenn du eine Feldnummer aus diesem Bereich vergibst, lehnt der echte protoc das Schema ab. Der Validator fängt das früh ab, damit du es von diesem Tool erfährst und nicht von einer verwirrenden Build-Meldung.

Folgt es Imports?

Nein. import-Statements werden erkannt und übersprungen — Message-Typen aus anderen Dateien lösen zu "unknown" auf und werden nicht validiert. Wenn du eine Message validieren musst, die von importierten Typen abhängt, klebe die importierten Messages in dieselbe Eingabe.

Wie groß darf das Schema sein?

Zehntausende Zeilen sind kein Thema. Validierung ist lokal, kein Upload, kein Rate-Limit, kein Netzwerk-Roundtrip — klebe das ganze Repo rein, wenn du willst; das Limit ist dein Browser-Speicher.

Protobuf-Validator