Input

Output

Hvad er MessagePack-validatoren?

Du integrerer med en service, der udsender MessagePack, og wire-formatet bliver ved med at overraske dig — forkert byteantal, mærkelige bytes til sidst, parseren dør kryptisk uden et hint om hvilket felt der knækkede. Dette værktøj tager et hex- eller base64-dump af en MsgPack-payload, kører det igennem en rigtig dekoder og fortæller dig, hvad der faktisk kom ud i den anden ende.

Vi sender dit input gennem dekoderen i @msgpack/msgpack. Hvis det parses, fortæller vi dig byteantallet, top-niveau-typen (map, array, string, int…) og længden af nøgler eller array, så du kan tjekke det mod skemaet i dit hoved. Hvis det fejler, viser vi parserens fejlbesked ordret — den peger som regel direkte på den offset, der knækkede.

Hex og base64 registreres automatisk. Whitespace, kommaer, 0x-præfikser og \xNN-escapes tolereres, så du kan indsætte direkte fra en Wireshark-capture, en serverlog eller et Python-repr()-dump. Intet forlader din browser — dekoderen kører lokalt.

Sådan bruger du MessagePack-validatoren

Indsæt det. Validatoren kører ved hvert tastetryk (300 ms debounce), så du skal ikke trykke på en knap.

Indsæt hex eller base64 MsgPack

Smid din kodede payload ind i venstre panel. Tryk på Eksempel-MsgPack for at indlæse et lille ordreobjekt kodet som hex — praktisk når du bare vil se, hvordan et gyldigt resultat ser ud. Dekoderen følger MessagePack-specifikationen, så alt, hvad en konform encoder producerede, går rent gennem round-trip. Eksempel-hex (et enkelt int 1):

Det er wire-byten for positiv fixint 1. Større payloads — maps, arrays, strenge — starter med formatbytes som 0x80–0x9f (fixmap/fixarray) eller 0xa0–0xbf (fixstr).

Læs valideringsrapporten

Højre panel fyldes ud automatisk. Ved succes får du en kort rapport — det registrerede inputformat (hex eller base64 iht. RFC 4648), kodet byteantal, top-niveau-type, antal nøgler/array-elementer plus en JSON-forhåndsvisning af den dekodede værdi (klippet ved 2 KB, så panelet forbliver læsbart).

Undersøg fejl

Ved en parsefejl viser højre panel ✗ Invalid MessagePack efterfulgt af dekoderens fejlstreng. Almindelige: "Insufficient bytes" (din hex blev klippet over), "Unrecognized type byte" (du indsatte JSON eller tekst ved en fejl, eller inputtet er korrupt) og "Extra bytes were found" (et længdepræfiks eller en framing-byte sneg sig ind). Forestil dig den underliggende byte-strøm som et Uint8Array — de fleste fejl er framing- eller længdeproblemer, ikke kodningsbugs.

Hvornår du faktisk vil bruge dette

Debug et cache miss

Din Redis-nøgle indeholder en MessagePack-kodet ordre (orderId: 'ORD-7421', items, customer), og forbrugeren kaster ved deserialisering. Indsæt hex'en fra redis-cli --no-raw GET, se om wire-formatet overhovedet er gyldigt, og bekræft at top-niveau-typen matcher det, din dekoder forventer.

Valider en wire-capture

Du har fanget en frame fra netværket med Wireshark eller tcpdump, eksporteret byterne og vil vide, om MsgPack'en indeni er velformet, før du sporer framingen i hånden. Indsæt, kig kort på type og byteantal, videre.

Sanity-tjek en producent

Skrevet en egen encoder i Go eller Rust? Kod en kendt fixture ({sku: 'SKU-101', qty: 2}), dump som hex og indsæt det her. Hvis vi læser det tilbage som det samme map, du skrev, er din encoder konform med MessagePack-formatet.

Pre-flight før en bug-rapport

Skal du åbne en issue mod et upstream-bibliotek? Bekræft først, at payloaden faktisk er gyldig MsgPack — halvdelen af "bibliotek-bug"-rapporterne er forkert formet input. 30 sekunder med indsættelse her sparer dig en runde frem og tilbage.

Almindelige spørgsmål

Forlader payloaden min browser?

Nej. Dekodning kører i JavaScript på denne side ved hjælp af @msgpack/msgpack-dekoderen. Intet uploades, logges eller sendes til en backend — luk fanen, og dataen er væk. Samme model som en desktop hex-viewer, blot i din browser.

Tager den imod binær fil-upload, eller kun hex/base64?

Kun hex og base64. Browsere eksponerer ikke filens bytes til siden uden en filvælger, og de fleste copy-paste-flows producerer allerede hex (fra xxd, hexdump -C, debugger-tooltips) eller base64 (fra REST-API-svar, log-linjer). Har du en rå .msgpack-fil, så kør xxd -p file.msgpack eller base64 file.msgpack først.

Hvordan skelner den hex fra base64?

Hex registreres først: hvis inputtet (efter at whitespace, kommaer, 0x-præfikser og \xNN-escape-sekvenser er fjernet) udelukkende består af hex-tegn og har lige længde, behandler vi det som hex. Ellers giver vi det videre til atob som base64. Linjen "Detected input format" i rapporten fortæller, hvilken vej der blev valgt — nyttigt når en tvetydig streng som deadbeef tilfældigvis er gyldig i begge kodninger.

Hvorfor siger den nogle gange "Extra bytes were found"?

MessagePack-strømme skal være præcis én top-niveau-værdi. Hvis du indsatte en længde-præfikset frame (f.eks. en 4-byte big-endian-længde tilføjet af en framing-transportprotokol) eller to sammenkædede payloads, læser dekoderen den første værdi og brokker sig over resten. Klip framingen væk eller del op i individuelle beskeder.

Kan den dekode MessagePack-udvidelser (timestamp, custom typer)?

Standard-@msgpack/msgpack-dekoderen håndterer den indbyggede timestamp-udvidelsestype (-1) ud af boksen og viser den som en JS Date i forhåndsvisningen. Brugerdefinerede udvidelsestyper (0 til 127) dekodes til en generisk {type, data}-form — validatoren vil stadig rapportere payloaden som gyldig, men du skal bruge din egen ExtensionCodec for at fortolke indholdet.

Hvad er forskellen på denne og MessagePack Vieweren?

Vieweren er til at bladre — den viser en trævisning af hver nøgle og værdi. Denne validator svarer på spørgsmålet "er det overhovedet gyldigt?" — hurtigt ja/nej plus byteantal og top-niveau-type. Siger validatoren, at det parses, og typen er rigtig, så skift til Vieweren for at læse indholdet.

Andre MessagePack-værktøjer

Når du har bekræftet, at payloaden er gyldig, tager disse værktøjer dig resten af vejen: