Indata

Utdata

Vad är MessagePack-validatorn?

Du integrerar mot en tjänst som spottar ut MessagePack och wire-formatet fortsätter att överraska dig — fel bytecount, konstiga avslutande bytes, parsern dör kryptiskt utan en aning om vilket fält som gick sönder. Det här verktyget tar en hex- eller base64-dump av en MsgPack-payload, kör den genom en riktig avkodare och berättar vad som faktiskt kom ut på andra sidan.

Vi skickar din input genom avkodaren i @msgpack/msgpack. Om det parsas berättar vi bytecount, top-level-typen (map, array, string, int…) samt nyckel- eller arraylängd så du kan stämma av mot schemat du har i huvudet. Misslyckas det visar vi parserns felmeddelande ordagrant — det pekar oftast rakt på den offset som gick sönder.

Hex och base64 detekteras automatiskt. Whitespace, kommatecken, 0x-prefix och \xNN-escapes tolereras, så du kan klistra in direkt från en Wireshark-capture, en serverlogg eller en Python-repr()-dump. Inget lämnar din webbläsare — avkodaren körs lokalt.

Så använder du MessagePack-validatorn

Klistra in. Validatorn kör vid varje tangenttryck (300 ms debounce) så du behöver inte trycka på någon knapp.

Klistra in hex eller base64 MsgPack

Släpp din kodade payload i vänsterpanelen. Tryck på Exempel-MsgPack för att ladda ett litet orderobjekt kodat som hex — bra när du bara vill se hur ett giltigt resultat ser ut. Avkodaren följer MessagePack-specen, så allt en konform encoder producerar gör en ren round-trip. Exempel-hex (en enda int 1):

Det är wire-byten för positivt fixint 1. Större payloads — maps, arrays, strängar — börjar med formatbytes som 0x80–0x9f (fixmap/fixarray) eller 0xa0–0xbf (fixstr).

Läs valideringsrapporten

Högerpanelen fylls i automatiskt. Vid framgång får du en kort rapport — detekterat indataformat (hex eller base64 enligt RFC 4648), kodad bytecount, top-level-typ, antal nycklar/array-element, plus en JSON-förhandsvisning av det avkodade värdet (kapad vid 2 KB så panelen förblir läsbar).

Undersök misslyckanden

Vid ett parsefel visar högerpanelen ✗ Invalid MessagePack följt av avkodarens felsträng. Vanliga: "Insufficient bytes" (din hex blev avhuggen), "Unrecognized type byte" (du klistrade in JSON eller text av misstag, eller indata är trasig) och "Extra bytes were found" (ett längdprefix eller en framing-byte smög sig in). Tänk på den underliggande byteströmmen som en Uint8Array i huvudet — de flesta misslyckanden är framing- eller längdproblem, inte kodningsbuggar.

När du faktiskt skulle använda detta

Felsöka en cache miss

Din Redis-nyckel håller en MessagePack-kodad order (orderId: 'ORD-7421', items, customer) och konsumenten kastar fel vid deserialisering. Klistra in hex från redis-cli --no-raw GET, se om wire-formatet ens är giltigt och bekräfta att top-level-typen matchar det din avkodare förväntar sig.

Validera en wire-capture

Du har fångat en frame från nätverket med Wireshark eller tcpdump, exporterat byterna och vill veta om MsgPack-en inuti är välformad innan du spårar framingen för hand. Klistra in, kasta ett öga på typ och bytecount, gå vidare.

Sanity-checka en producent

Skrivit en egen encoder i Go eller Rust? Koda en känd fixture ({sku: 'SKU-101', qty: 2}), dumpa som hex och klistra in här. Om vi läser tillbaka det som samma map du skrev är din encoder konform mot MessagePack-formatet.

Pre-flight innan en buggrapport

Ska du öppna en issue mot ett upstream-bibliotek? Bekräfta först att payloaden faktiskt är giltig MsgPack — hälften av "biblioteksbugg"-rapporterna är felformad indata. 30 sekunder att klistra in här sparar en runda fram och tillbaka.

Vanliga frågor

Lämnar payloaden min webbläsare?

Nej. Avkodningen körs i JavaScript på den här sidan med @msgpack/msgpack-avkodaren. Inget laddas upp, loggas eller skickas till någon backend — stäng fliken och datan är borta. Samma modell som en hex-viewer på skrivbordet, fast i din webbläsare.

Tar den emot binäruppladdning, eller bara hex/base64?

Endast hex och base64. Webbläsare exponerar inte filens bytes till sidan utan en filväljare, och de flesta copy-paste-flöden producerar redan hex (från xxd, hexdump -C, debugger-tooltips) eller base64 (från REST-API-svar, loggrader). Har du en rå .msgpack-fil, kör xxd -p file.msgpack eller base64 file.msgpack först.

Hur skiljer den hex från base64?

Hex detekteras först: om indatan (efter att whitespace, kommatecken, 0x-prefix och \xNN-escapesekvenser strippats) består uteslutande av hex-tecken och har jämn längd behandlar vi det som hex. Annars skickar vi det till atob som base64. Raden "Detected input format" i rapporten talar om vilken väg som togs — användbart när en tvetydig sträng som deadbeef råkar vara giltig i båda kodningarna.

Varför säger den ibland "Extra bytes were found"?

En MessagePack-ström ska bestå av exakt ett top-level-värde. Om du klistrade in en längd-prefixad frame (t.ex. en 4-byte big-endian-längd som ett framing-transportprotokoll lagt till) eller två hopslagna payloads läser avkodaren första värdet och klagar på resten. Klipp bort framingen eller dela upp i enskilda meddelanden.

Kan den avkoda MessagePack-extensions (timestamp, custom-typer)?

Standard-@msgpack/msgpack-avkodaren hanterar den inbyggda timestamp-extensiontypen (-1) direkt och visar den som JS Date i förhandsvisningen. Anpassade extensiontyper (0 till 127) avkodas till en generisk {type, data}-form — validatorn rapporterar fortfarande payloaden som giltig, men du behöver din egen ExtensionCodec för att tolka innehållet.

Vad är skillnaden mellan denna och MessagePack Viewern?

Viewern är till för att botanisera — den visar en trädvy av varje nyckel och värde. Den här validatorn svarar på frågan "är det ens giltigt?" — snabbt ja/nej plus bytecount och top-level-typ. Säger validatorn att det parsas och typen stämmer, byt till Viewer för att faktiskt läsa innehållet.

Andra MessagePack-verktyg

När du har bekräftat att payloaden är giltig tar dessa verktyg dig resten av vägen: