Protobuf-Wireformat und lokale Schemas prüfen
Protobuf-Wiretypen0/1/2/3/4/5 mit exakten Positionen/Bytes; ohne Schema keine geratenen Namen/Texte.
- Läuft im Browser
- Kein Upload
- Vor dem Download prüfen
Dateien und Schemas bleiben in diesem Tab und in einem lokalen Worker. Es gibt keinen Upload und keine automatische Speicherung. Beim Leeren oder Schließen gehen die Eingaben verloren; behalte also die Originale und speichere die Ergebnisse.
Protobuf-Wiretypen0/1/2/3/4/5 mit exakten Positionen/Bytes; ohne Schema keine geratenen Namen/Texte. Lokale proto2/proto3-Grammatik mit expliziten Importen, Skalaren/Enums/Nachrichten/Groups, gepackten/wiederholten Feldern, Maps und Oneof. Optionale Felder bleiben abwesend, Pflichtfelder müssen existieren. Einzelne Nachrichtenfragmente werden zusammengeführt; Skalare verwenden den letzten Wert, Oneof das zuletzt aktive Feld. Maps behalten doppelte Einträge zur Prüfung statt kanonischem Protobuf-JSON. Editions/Extensions nicht unterstützt. Keine Remote-Imports, generierten Konstruktoren/Codecs, eval oder Anwendungsausführung. Integer als Dezimaltext, Bytes als Hex. Prüfung von Namen/unbekannten Feldern bestätigt keine Anwendungssemantik. Wire-/dekodierten Bericht und Original speichern; schemas.json erhält lokale Schemas. Nachrichtenfragmente innerhalb eines Map-Werts werden zusammengeführt; Map-Einträge bleiben getrennt, Skalare verwenden das letzte Vorkommen.
Datei höchstens 16 MiB; Protobuf höchstens 1 MiB; Schema höchstens 256 KiB, zusammen höchstens 1 MiB. Tiefe 64, 20.000 Metadaten- und Wire-Knoten, 100.000 physische bzw. erhaltene Werte; Dekodierung 32 MiB; Ergebnisse 8 MiB plus Original. Vorschau 200 Zeilen, Export 10.000 Zeilen. Der Worker läuft höchstens 5 Sekunden. Der lineare SQLite-Speicher von 64 MiB ist nicht der gesamte Browser-Heap.
Methode und Grenzen
Unterstütztes Profil
Protobuf-Wiretypen0/1/2/3/4/5 mit exakten Positionen/Bytes; ohne Schema keine geratenen Namen/Texte. Lokale proto2/proto3-Grammatik mit expliziten Importen, Skalaren/Enums/Nachrichten/Groups, gepackten/wiederholten Feldern, Maps und Oneof. Optionale Felder bleiben abwesend, Pflichtfelder müssen existieren. Einzelne Nachrichtenfragmente werden zusammengeführt; Skalare verwenden den letzten Wert, Oneof das zuletzt aktive Feld. Maps behalten doppelte Einträge zur Prüfung statt kanonischem Protobuf-JSON. Editions/Extensions nicht unterstützt. Keine Remote-Imports, generierten Konstruktoren/Codecs, eval oder Anwendungsausführung. Integer als Dezimaltext, Bytes als Hex. Prüfung von Namen/unbekannten Feldern bestätigt keine Anwendungssemantik. Wire-/dekodierten Bericht und Original speichern; schemas.json erhält lokale Schemas. Nachrichtenfragmente innerhalb eines Map-Werts werden zusammengeführt; Map-Einträge bleiben getrennt, Skalare verwenden das letzte Vorkommen.
Ressourcengrenzen
Datei höchstens 16 MiB; Protobuf höchstens 1 MiB; Schema höchstens 256 KiB, zusammen höchstens 1 MiB. Tiefe 64, 20.000 Metadaten- und Wire-Knoten, 100.000 physische bzw. erhaltene Werte; Dekodierung 32 MiB; Ergebnisse 8 MiB plus Original. Vorschau 200 Zeilen, Export 10.000 Zeilen. Der Worker läuft höchstens 5 Sekunden. Der lineare SQLite-Speicher von 64 MiB ist nicht der gesamte Browser-Heap.
Dateien und Schemas bleiben in diesem Tab und in einem lokalen Worker. Es gibt keinen Upload und keine automatische Speicherung. Beim Leeren oder Schließen gehen die Eingaben verloren; behalte also die Originale und speichere die Ergebnisse.
Sicher prüfen
- Lokale Binärdatei
Lade eine binäre Nachricht. Im Wire-Modus brauchst du kein Schema. Im Schema-Modus brauchst du lokale .proto-Dateien, den Namen der Hauptdatei und den Nachrichtentyp. Mit dem Beispiel startest du mit sample.proto und dem Typ Sample.
- Schema und Metadaten
Die Beispielbytes beginnen mit 08 96 01, danach folgt ein Feld mit angegebener Länge. Mit Sample {int64 id=1; string name=2;} ergeben sie id=150 und name=Café. Im Wire-Modus siehst du Feldnummern, Bytebereiche und Rohdaten, statt dass Namen erfunden werden.
- Exporte prüfen und speichern
Vergleiche die gelesenen Felder mit den Wire-Positionen und der Zahl unbekannter Felder. Speichere report.json, falls vorhanden schemas.json und original.pb. Ganzzahlen stehen als Dezimaltext da, Bytes als Hex und nicht als geratener UTF-8-Text.
Methode und Grenzen
Warum unterscheiden sich Wire-Bericht und Schema-Bericht?
Das Wire-Format allein verrät nicht, ob ein Wert mit angegebener Länge Text, Bytes oder eine Unternachricht ist. Diese Deutung kommt erst vom gewählten Schema. Fehlende optionale Felder bleiben weg, wiederholte Felder behalten alle Vorkommen, und bei oneof gilt das zuletzt gesetzte Mitglied. Der Bericht ist weder kanonisches Protobuf-JSON noch eine Prüfung der Bedeutung in deiner Anwendung.
Warum lässt sich diese Datei oder Auswahl nicht lesen?
Gib den genauen, vollständig qualifizierten Nachrichtennamen an und liefere die lokalen Imports mit. Abgeschnittene Varints, falsche Wire-Typen, fehlende Pflichtfelder und fehlende Schemas führen zu Fehlern. Eine verpackte oder komprimierte Anwendungshülle solltest du nicht wie eine rohe Nachricht lesen.
Was macht dieser Inspektor ausdrücklich nicht?
Geprüft werden lokale proto2- und proto3-Dateien; Editions und Erweiterungen werden nicht unterstützt. Du kannst bis zu 16 lokale Schemadateien mit zusammen höchstens 1 MiB laden, die Nachricht darf höchstens 1 MiB groß sein. Es gibt keine Imports aus dem Netz, keinen erzeugten Anwendungscode und keine Ausführung. Doppelte Map-Einträge bleiben sichtbar.