입력

출력

MessagePack 검증기란?

MessagePack을 내보내는 서비스와 연동 중인데 와이어 포맷이 자꾸 발목을 잡습니다 — 바이트 수가 안 맞고, 끝에 이상한 바이트가 붙고, 파서가 어떤 필드에서 죽었는지 단서도 없이 알 수 없는 에러로 사망합니다. 이 도구는 MsgPack 페이로드의 hex 또는 base64 덤프를 받아 실제 디코더에 통과시키고, 반대편에서 실제로 무엇이 나왔는지 알려줍니다.

입력을 @msgpack/msgpack 디코더에 통과시킵니다. 파싱되면 바이트 수, 최상위 타입(map, array, string, int…), 키 또는 배열 길이를 알려주므로 머릿속의 스키마와 비교해 검증할 수 있습니다. 실패하면 파서의 에러 메시지를 있는 그대로 보여줍니다 — 보통 깨진 오프셋을 정확히 가리킵니다.

hex와 base64는 자동으로 감지됩니다. 공백, 쉼표, 0x 접두사, \xNN 이스케이프도 허용되므로 Wireshark 캡처, 서버 로그, Python의 repr() 덤프에서 그대로 붙여넣을 수 있습니다. 데이터는 브라우저 밖으로 나가지 않습니다 — 디코더는 로컬에서 실행됩니다.

MessagePack 검증기 사용법

붙여넣기만 하면 됩니다. 검증기는 키 입력마다 동작하므로(300ms 디바운스) 버튼을 누를 필요가 없습니다.

hex 또는 base64 MsgPack 붙여넣기

인코딩된 페이로드를 왼쪽 패널에 떨어뜨리세요. 샘플 MsgPack을 누르면 hex로 인코딩된 작은 주문 객체가 로드됩니다 — 유효한 결과가 어떤 모습인지 보고 싶을 때 유용합니다. 디코더는 MessagePack 사양을 따르므로 표준에 맞는 인코더가 만든 것은 깔끔하게 라운드트립됩니다. 예시 hex (단일 int 1):

이것이 양수 fixint 1의 와이어 바이트입니다. 더 큰 페이로드(map, array, string)는 0x80~0x9f (fixmap/fixarray) 또는 0xa0~0xbf (fixstr) 같은 포맷 바이트로 시작합니다.

검증 리포트 읽기

오른쪽 패널이 자동으로 채워집니다. 성공하면 작은 리포트를 받습니다 — 감지된 입력 포맷(hex 또는 RFC 4648 기준 base64), 인코딩된 바이트 수, 최상위 타입, 키/배열 개수, 그리고 디코딩된 값의 JSON 미리보기(패널 가독성을 위해 2KB에서 잘림).

실패 조사하기

파싱 실패 시 오른쪽 패널에 ✗ Invalid MessagePack과 디코더의 에러 문자열이 표시됩니다. 흔한 것들: "Insufficient bytes" (hex가 잘림), "Unrecognized type byte" (실수로 JSON이나 텍스트를 붙여넣었거나 입력이 깨짐), "Extra bytes were found" (길이 접두사나 프레이밍 바이트가 섞여 들어감). 머릿속에서는 바이트 스트림을 Uint8Array로 다루세요 — 대부분의 실패는 인코딩 버그가 아니라 프레이밍이나 길이 문제입니다.

실제로 사용하게 되는 상황

캐시 미스 디버깅

Redis 키에 MessagePack으로 인코딩된 주문(orderId: 'ORD-7421', items, customer)이 들어 있고 컨슈머가 역직렬화에서 예외를 던집니다. redis-cli --no-raw GET의 hex를 붙여넣어 와이어 포맷이 일단 유효한지 확인하고, 최상위 타입이 디코더가 기대하는 것과 일치하는지 확인하세요.

와이어 캡처 검증

Wireshark나 tcpdump로 네트워크에서 프레임을 캡처하고 바이트를 내보낸 다음, 프레이밍을 손으로 추적하기 전에 안의 MsgPack이 잘 만들어졌는지 알고 싶습니다. 붙여넣고 타입과 바이트 수를 보고 다음 작업으로 넘어가세요.

프로듀서 동작 확인

Go나 Rust로 자체 인코더를 만들었나요? 알려진 픽스처({sku: 'SKU-101', qty: 2})를 인코딩해 hex로 덤프하고 여기에 붙여넣으세요. 작성한 그대로의 map으로 다시 읽힌다면 인코더가 MessagePack 포맷을 잘 따르고 있는 것입니다.

버그 리포트 전 프리플라이트

업스트림 라이브러리에 이슈를 올리려고요? 페이로드가 정말로 유효한 MsgPack인지 먼저 확인하세요 — "라이브러리 버그" 리포트의 절반은 잘못된 입력입니다. 여기서 30초 붙여넣기로 한 번의 핑퐁을 줄일 수 있습니다.

자주 묻는 질문

페이로드가 브라우저 밖으로 나가나요?

아니요. 디코딩은 이 페이지의 JavaScript에서 @msgpack/msgpack 디코더로 수행됩니다. 업로드, 로깅, 백엔드 전송 모두 없습니다 — 탭을 닫으면 데이터는 사라집니다. 데스크톱 hex 뷰어와 같은 모델이 브라우저 안에서 도는 것뿐입니다.

바이너리 파일 업로드를 받나요, 아니면 hex/base64만 받나요?

hex와 base64만 받습니다. 브라우저는 파일 선택기 없이는 파일 바이트를 페이지에 노출하지 않으며, 대부분의 복사-붙여넣기 워크플로는 이미 hex(xxd, hexdump -C, 디버거 툴팁에서)나 base64(REST API 응답, 로그 라인에서)를 만들어 줍니다. 원본 .msgpack 파일이 있다면 먼저 xxd -p file.msgpack이나 base64 file.msgpack을 실행하세요.

hex와 base64를 어떻게 구분하나요?

hex를 먼저 감지합니다: 입력(공백, 쉼표, 0x 접두사, \xNN 이스케이프 시퀀스를 제거한 뒤)이 모두 hex 문자이고 길이가 짝수면 hex로 취급합니다. 그렇지 않으면 atob에 base64로 넘깁니다. 리포트의 "Detected input format" 줄이 어느 경로를 탔는지 알려줍니다 — deadbeef처럼 두 인코딩 모두에서 유효한 모호한 문자열일 때 유용합니다.

왜 가끔 "Extra bytes were found"가 뜨나요?

MessagePack 스트림은 정확히 하나의 최상위 값이어야 합니다. 길이 접두사 프레임(예: 프레이밍 전송 프로토콜이 추가하는 4바이트 빅엔디언 길이)이나 두 페이로드를 이어 붙인 것을 붙여넣으면 디코더는 첫 값을 읽고 남은 부분에 대해 불평합니다. 프레이밍을 잘라내거나 개별 메시지로 나누세요.

MessagePack 확장(timestamp, 커스텀 타입)도 디코딩하나요?

기본 @msgpack/msgpack 디코더는 내장 timestamp 확장 타입(-1)을 기본 지원하며 미리보기에서 JS Date로 표시합니다. 사용자 정의 확장 타입(0~127)은 일반적인 {type, data} 형태로 디코딩됩니다 — 검증기는 페이로드를 여전히 유효하다고 보고하지만, 내용을 해석하려면 자체 ExtensionCodec이 필요합니다.

이것과 MessagePack 뷰어의 차이는 무엇인가요?

뷰어는 둘러보기용입니다 — 각 키와 값을 트리 형태로 분해해 보여줍니다. 이 검증기는 "이게 유효하기는 한가?"라는 질문에 답합니다 — 빠른 예/아니오와 바이트 수, 최상위 타입을 줍니다. 검증기가 파싱된다고 하고 타입이 맞다면 뷰어로 전환해 실제 내용을 읽으세요.

다른 MessagePack 도구

페이로드가 유효함을 확인했다면, 이 도구들이 나머지를 처리합니다: