Fügen Sie ein CloudEvents-Objekt oder ce-*-Header mit Body ein, um fehlende Kontextattribute und Payload-Konflikte zu prüfen. Kopieren Sie das normalisierte JSON oder die HTTP-Header für den Binärmodus.
Läuft lokal in deinem BrowserVerwenden Sie strukturiertes JSON oder den HTTP-Binärmodus. Das Werkzeug veröffentlicht kein Event und ruft keinen Endpoint auf.
Der CloudEvents-Inspektor liest jeweils ein Ereignis in einer der beiden Formen, die die HTTP-Bindung definiert: als JSON-Umschlag (strukturierter Modus) oder als Block aus ce-*-Headern mit optionalem Body (Binärmodus). Er prüft die Kontextattribute gegen CloudEvents 1.0 und schreibt dasselbe Ereignis als normalisiertes strukturiertes JSON und als Header im Binärmodus neu.
Alles läuft in diesem Tab. Das Werkzeug veröffentlicht kein Ereignis, ruft keinen Endpunkt auf und fragt keine Schema-Registry ab; das Netzwerkprotokoll bleibt leer, während Sie einfügen und umwandeln.
Eine Eingabe, die mit einer geschweiften Klammer beginnt, wird als JSON-Umschlag gelesen. Alles andere gilt als Headerblock; ein Block mit dem Content-Type application/cloudevents+json wird als strukturiertes JSON mit dem Body unter den Headern dekodiert.
Im Binärmodus ist der Body alles nach der ersten Leerzeile. Wenn der Content-Type JSON angibt, wird der Body zum Objekt, andernfalls bleibt er eine Zeichenkette, sodass Text- und JSON-Payload nicht verwechselt werden.
Die vier Pflichtattribute specversion, id, source und type werden getrennt gemeldet, wenn sie fehlen oder leer sind und wenn sie den falschen Typ haben; specversion muss 1.0 sein, source muss eine nicht leere URI-Referenz ohne Leerzeichen sein und time muss ein RFC-3339-Zeitstempel samt Offset sein. data und data_base64 schließen sich aus, data_base64 muss gültiges Base64 sein, und ein Ereignis ohne Payload ist eine Warnung statt eines Fehlers, weil die Spezifikation es zulässt.
Erweiterungsattribute werden gezählt und mitgeführt. Ein JSON-null in einem Kontextattribut gilt als nicht gesetzt, wie es die JSON-Formatspezifikation verlangt: subject: null verschwindet aus der normalisierten Ausgabe, während data: null als ausdrücklich leerer Payload erhalten bleibt.
Das normalisierte strukturierte Ereignis listet zuerst die Kernattribute, dann die Erweiterungen alphabetisch und zuletzt den Payload. Kopieren übernimmt den Bereich unverändert, sodass das Ergebnis direkt in eine Testdatei oder ein Diff passt.
Die Header im Binärmodus enthalten je Kontextattribut einen ce-*-Header, Erweiterungen eingeschlossen, und einen Content-Type-Header nur, wenn ein Payload zu beschreiben ist. Der Payload folgt nach einer Leerzeile; data_base64 wird unverändert übernommen und die angezeigte Größe ist die der dekodierten Bytes, nicht die des Base64-Texts.
Dies ist eine Umschlagprüfung. Der Payload wird nie gegen ein Schema validiert, CloudEvents-Signaturen werden nicht geprüft, und brokerspezifische Regeln bleiben außen vor. Auch die Namen der Erweiterungsattribute werden nicht gegen die Namensregeln der Spezifikation geprüft.
Ein grünes Ergebnis heißt, dass das Ereignis wohlgeformt ist, nicht dass ein Empfänger es annimmt. Scheitert eine Integration weiterhin, vergleichen Sie das Ereignis mit der Dokumentation Ihres Brokers oder den Konformitätstests der Spezifikation, bevor Sie den Produzenten ändern.