Inndata

Utdata

Hva er MessagePack-validatoren?

Du integrerer mot en tjeneste som sender ut MessagePack, og wire-formatet fortsetter å overraske deg — feil byteantall, rare avsluttende bytes, parseren dør kryptisk uten et hint om hvilket felt som røk. Dette verktøyet tar en hex- eller base64-dump av en MsgPack-payload, kjører den gjennom en ekte dekoder, og forteller deg hva som faktisk kom ut på den andre siden.

Vi sender input-en din gjennom dekoderen i @msgpack/msgpack. Hvis det parses, oppgir vi byteantallet, topp-nivå-typen (map, array, string, int…) og lengden på nøkler eller array slik at du kan kontrollsjekke mot skjemaet du har i hodet. Hvis det feiler, viser vi parserens feilmelding ordrett — den peker som regel rett på offsetten som røk.

Hex og base64 detekteres automatisk. Whitespace, komma, 0x-prefikser og \xNN-escapes tolereres, så du kan lime rett inn fra en Wireshark-fangst, en serverlogg eller en Python-repr()-dump. Ingenting forlater nettleseren din — dekoderen kjører lokalt.

Slik bruker du MessagePack-validatoren

Lim det inn. Validatoren kjører ved hvert tastetrykk (300 ms debounce), så du trenger ikke trykke på noen knapp.

1

Lim inn hex eller base64 MsgPack

Slipp den kodede payloaden inn i venstre panel. Trykk på Eksempel-MsgPack for å laste et lite ordreobjekt kodet som hex — praktisk når du bare vil se hvordan et gyldig resultat ser ut. Dekoderen følger MessagePack-spesifikasjonen, så alt en konform encoder produserte vil ta en ren round-trip. Eksempel-hex (en enkelt int 1):

01

Det er wire-byten for positiv fixint 1. Større payloads — maps, arrays, strenger — starter med formatbytes som 0x800x9f (fixmap/fixarray) eller 0xa00xbf (fixstr).

2

Les valideringsrapporten

Høyre panel fylles automatisk. Ved suksess får du en kort rapport — detektert input-format (hex eller base64 iht. RFC 4648), kodet byteantall, topp-nivå-type, antall nøkler/array-elementer, pluss en JSON-forhåndsvisning av den dekodede verdien (kuttet ved 2 KB så panelet holder seg lesbart).

3

Undersøk feil

Ved en parsefeil viser høyre panel ✗ Invalid MessagePack etterfulgt av dekoderens feilstreng. Vanlige: "Insufficient bytes" (hex-en din ble kuttet), "Unrecognized type byte" (du limte inn JSON eller tekst ved en feil, eller input-en er korrupt) og "Extra bytes were found" (et lengdeprefiks eller en framing-byte snek seg inn). Tenk på den underliggende bytestrømmen som et Uint8Array — de fleste feilene er framing- eller lengdeproblemer, ikke kodingsbugs.

Når du faktisk vil bruke dette

Debug en cache miss

Redis-nøkkelen din inneholder en MessagePack-kodet ordre (orderId: 'ORD-7421', items, customer), og konsumenten kaster ved deserialisering. Lim inn hex-en fra redis-cli --no-raw GET, se om wire-formatet i det hele tatt er gyldig, og bekreft at topp-nivå-typen matcher det dekoderen din forventer.

Valider en wire-fangst

Du fanget en frame fra nettverket med Wireshark eller tcpdump, eksporterte byterne, og vil vite om MsgPack-en inni er velformet før du sporer framingen for hånd. Lim inn, kast et blikk på type og byteantall, gå videre.

Sanity-sjekk en produsent

Skrevet en egen encoder i Go eller Rust? Kod en kjent fixture ({sku: 'SKU-101', qty: 2}), dump som hex, og lim det inn her. Hvis vi leser det tilbake som det samme map-et du skrev, er encoderen din konform mot MessagePack-formatet.

Pre-flight før en bug-rapport

Skal du åpne en issue mot et upstream-bibliotek? Bekreft først at payloaden faktisk er gyldig MsgPack — halvparten av "bibliotek-bug"-rapportene er feilformet input. 30 sekunder med inn-liming her sparer deg en runde frem og tilbake.

Vanlige spørsmål

Forlater payloaden nettleseren min?

Nei. Dekodingen kjører i JavaScript på denne siden med @msgpack/msgpack-dekoderen. Ingenting lastes opp, logges eller sendes til noen backend — lukk fanen, og dataen er borte. Samme modell som en desktop hex-viewer, bare i nettleseren.

Tar den imot binær filopplasting, eller bare hex/base64?

Bare hex og base64. Nettlesere eksponerer ikke fil-bytes til siden uten en filvelger, og de fleste copy-paste-flytene produserer allerede hex (fra xxd, hexdump -C, debugger-tooltips) eller base64 (fra REST-API-svar, loggrader). Har du en rå .msgpack-fil, kjør xxd -p file.msgpack eller base64 file.msgpack først.

Hvordan skiller den hex fra base64?

Hex detekteres først: hvis input-en (etter å ha fjernet whitespace, komma, 0x-prefikser og \xNN-escape-sekvenser) bare består av hex-tegn og har partall lengde, behandler vi det som hex. Ellers gir vi det videre til atob som base64. Linjen "Detected input format" i rapporten forteller hvilken vei som ble tatt — nyttig når en tvetydig streng som deadbeef tilfeldigvis er gyldig i begge kodingene.

Hvorfor sier den noen ganger "Extra bytes were found"?

MessagePack-strømmer skal være nøyaktig én topp-nivå-verdi. Hvis du limte inn en lengde-prefikset frame (f.eks. en 4-byte big-endian-lengde lagt på av en framing-transportprotokoll) eller to sammenslåtte payloads, leser dekoderen den første verdien og klager på resten. Klipp bort framingen eller del opp i individuelle meldinger.

Kan den dekode MessagePack-utvidelser (timestamp, egendefinerte typer)?

Standard-@msgpack/msgpack-dekoderen håndterer den innebygde timestamp-utvidelsestypen (-1) ut av boksen og viser den som en JS Date i forhåndsvisningen. Egendefinerte utvidelsestyper (0 til 127) dekodes til en generisk {type, data}-form — validatoren rapporterer payloaden fortsatt som gyldig, men du trenger din egen ExtensionCodec for å tolke innholdet.

Hva er forskjellen på denne og MessagePack Vieweren?

Vieweren er til å bla i — den viser en trevisning av hver nøkkel og verdi. Denne validatoren svarer på spørsmålet "er det i det hele tatt gyldig?" — raskt ja/nei pluss byteantall og topp-nivå-type. Sier validatoren at det parses, og typen er riktig, bytt til Vieweren for å faktisk lese innholdet.

Andre MessagePack-verktøy

Når du har bekreftet at payloaden er gyldig, tar disse verktøyene deg resten av veien: