MessagePack-validator
Lim inn MessagePack som hex eller base64 og se om det parses rent. Viser byteantall, topp-nivå-type og parserens feil ordrett hvis det feiler.
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.
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):
01Det er wire-byten for positiv fixint 1. Større payloads — maps, arrays, strenger — starter med formatbytes som 0x80–0x9f (fixmap/fixarray) eller 0xa0–0xbf (fixstr).
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).
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: