Collez un événement CloudEvents ou des en-têtes ce-* avec leur corps pour repérer les attributs absents et les conflits de données. Copiez le JSON normalisé ou les en-têtes HTTP de mode binaire.
Fonctionne localement dans votre navigateurUtilisez le mode binaire structuré JSON ou HTTP. Cet outil ne publie pas d'événement et n'appelle pas de point de terminaison.
L’inspecteur CloudEvents lit un événement à la fois, dans l’une des deux formes définies par la liaison HTTP : une enveloppe JSON (mode structuré) ou un bloc d’en-têtes ce-* avec un corps facultatif (mode binaire). Il vérifie les attributs de contexte par rapport à CloudEvents 1.0, puis réécrit le même événement en JSON structuré normalisé et en en-têtes de mode binaire.
Tout s’exécute dans cet onglet. L’outil ne publie aucun événement, n’appelle aucun point de terminaison et n’interroge aucun registre de schémas ; le journal réseau reste vide pendant que vous collez et convertissez.
Une entrée qui commence par une accolade est lue comme une enveloppe JSON. Tout le reste est traité comme un bloc d’en-têtes, et un bloc dont le Content-Type vaut application/cloudevents+json est décodé comme du JSON structuré avec le corps sous les en-têtes.
En mode binaire, le corps correspond à tout ce qui suit la première ligne vide. Si le type de contenu annonce du JSON, le corps devient un objet ; sinon il reste une chaîne, ce qui évite de confondre une charge texte et une charge JSON.
Les quatre attributs obligatoires specversion, id, source et type sont signalés différemment selon qu’ils sont absents ou vides ou qu’ils ont le mauvais type ; specversion doit valoir 1.0, source doit être une référence URI non vide et sans espace, et time doit être un horodatage RFC 3339 avec son décalage. data et data_base64 s’excluent mutuellement, data_base64 doit être du base64 valide, et un événement sans charge produit un avertissement et non une erreur, car la spécification l’autorise.
Les attributs d’extension sont comptés et conservés. Un null JSON sur un attribut de contexte est traité comme non défini, conformément à la spécification du format JSON : subject: null disparaît de la sortie normalisée, tandis que data: null est conservé comme charge nulle explicite.
L’événement structuré normalisé place d’abord les attributs principaux, puis les extensions par ordre alphabétique et enfin la charge. Le bouton Copier reprend le panneau tel quel : le résultat peut être collé directement dans un fichier de test ou un diff.
Les en-têtes en mode binaire contiennent un en-tête ce-* par attribut de contexte, extensions comprises, et un en-tête Content-Type uniquement lorsqu’une charge est à décrire. La charge suit après une ligne vide ; data_base64 est recopié tel quel et la taille affichée est celle des octets décodés, pas celle du texte base64.
Il s’agit d’un contrôle d’enveloppe. La charge n’est jamais validée contre un schéma, les signatures CloudEvents ne sont pas vérifiées et les règles propres à un broker restent hors périmètre. Les noms des attributs d’extension ne sont pas non plus confrontés aux règles de nommage de la spécification.
Un résultat correct signifie que l’événement est bien formé, pas qu’un récepteur l’acceptera. Si une intégration échoue encore, comparez l’événement à la documentation de votre broker ou aux tests de conformité de la spécification avant de modifier le producteur.