입력

출력

MessagePack to JSON이란?

gRPC 사이드카가 요청 본문을 긴 hex 문자열로 로깅하고 있는데 그 안에 뭐가 들었는지 실제로 봐야 할 때가 있습니다. 또는 Redis가 반환한 값을 이전 서비스가 msgpack으로 저장해 두어 터미널에 \x82\xa7orderId\xa8ORD-7421 같은 게 찍히는 경우도 있죠. MessagePack은 컴팩트한 바이너리 포맷입니다 — 와이어에서는 훌륭하지만 로그 한 줄에서는 읽을 수가 없습니다. 이 페이지는 hex나 base64 덤프를 받아 그것이 표현하는 JSON을 돌려줍니다.

디코딩은 공식 MessagePack 와이어 포맷 사양을 따르며 @msgpack/msgpack JavaScript 라이브러리를 사용합니다. map은 객체로, array는 배열로, 정수와 부동소수는 그대로 JSON 숫자로 디코딩되고, 결과는 RFC 8259에 맞춰 보기 좋게 출력됩니다. 0x 접두사가 붙은 hex, \x 이스케이프, 공백, 쉼표 모두 잘 파싱됩니다. 입력이 base64(RFC 4648)면 자동으로 감지합니다.

업로드도, 백엔드도, 로깅도 없습니다. 디코딩은 평범한 Uint8Array로 브라우저에서 실행됩니다 — 탭을 닫으면 바이트는 사라집니다.

MessagePack to JSON 사용법

붙여넣고, 읽고, 복사. Convert 버튼 없습니다 — 타이핑하면 오른쪽 패널이 갱신되고, 300 ms 디바운스가 걸려 있어 키 한 번마다 돌아가지는 않습니다.

hex 또는 base64 붙여넣기

왼쪽 에디터에 MessagePack 바이트를 떨어뜨리세요. 어떤 형식이든 OK입니다 — 순수 hex(82a7...), 공백 hex(82 a7 6f), \x 이스케이프된 Python 바이트 리터럴, base64 블롭까지. 샘플을 누르면 실제 객체로 디코딩되는 주문 추적 페이로드가 로드됩니다.

82a76f72646572496441 4f52442d3734323120a574 6f74616c cb4056600000000000

이 스니펫은 Order 페이로드의 일부입니다 — orderId, total, items, customer를 포함합니다. 디코딩 후에는 전체 구조가 JSON으로 돌아옵니다.

오른쪽에서 JSON 읽기

오른쪽 패널은 변경마다 다시 디코딩합니다. 바이트가 유효한 MessagePack이면 객체가 보입니다. 잘렸거나, 쓰레기 값으로 패딩됐거나, 사실 다른 포맷(CBOR, BSON)이라면 패널에 파서 에러 메시지가 뜹니다 — 보통 입력의 어디가 잘못됐는지 알아내기에 충분합니다.

필요한 부분 복사

출력 쪽의 복사 버튼으로 JSON을 가져가세요. 유닛 테스트 픽스처에 넣거나, 버그 티켓에 붙이거나, 다른 형식으로 정렬하고 싶다면 JSON 포맷터에 넣어 보세요. 반대 방향(객체 → msgpack)은 JSON을 MessagePack으로를 쓰세요.

실제로 쓸 만한 상황

gRPC 또는 사이드카 로그 본문 읽기

서비스 메시 사이드카가 요청 본문을 hex로 덤프합니다. 본문이 msgpack인 이유는 상위 서비스가 그렇게 직렬화하기 때문이죠. hex를 붙여넣고 객체를 보면, 그 호출이 orderId: "ORD-7421"과 total: 89.50을 들고 있었다는 사실을 추측이 아니라 확인으로 알 수 있습니다.

Redis 값 점검

공간 절약을 위해 msgpack 코덱으로 Redis에 객체를 저장했습니다. 이제 스크립트 없이 session:42에 뭐가 있는지 알고 싶습니다. GET으로 값을 가져와(대부분의 클라이언트는 hex나 base64로 보여줍니다) 여기에 붙여넣으세요.

캐시 엔트리 디코딩

작은 페이로드를 노리는 캐시 — MessagePack, FlatBuffers, 가끔은 순수 protobuf — 가 요즘 어디에나 있습니다. 캐시된 블롭이 msgpack이고 라이브 JSON과 비교해야 한다면, 동일 조건에서 비교하기에 가장 빠른 길입니다.

클라이언트가 보내는 내용 점검

대역폭 절약을 위해 모바일 클라이언트가 요청 본문을 msgpack으로 인코딩하게 만들었는데 회귀가 발생했습니다. 실제 바이트를 캡처(Charles, mitmproxy, 네트워크 탭)해 붙여넣고, 필드명과 값이 서버가 기대하는 스키마와 맞는지 확인합니다. 고객 이름 Ava Chen, 항목 SKU-101 × 2 — 맞는지 아닌지.

자주 묻는 질문

입력한 바이트가 어디로든 업로드되나요?

아니요. 디코딩은 브라우저 안에서 도는 순수 JavaScript입니다 — @msgpack/msgpack 라이브러리가 입력을 Uint8Array로 읽고, 와이어 포맷을 따라가며, 결과 객체를 JSON으로 렌더링합니다. fetch도, 입력에 대한 분석도, 탭을 떠나는 데이터도 없습니다. 로컬 CLI 도구와 같다고 보면 됩니다.

hex랑 base64 중 뭘 붙여야 하나요?

둘 다 됩니다. 도구는 hex를 먼저 시도합니다(0x나 \x 접두사, 공백, 쉼표가 섞인 hex가 로그 형태로 가장 흔하기 때문에), 유효한 hex가 아니면 base64로 떨어집니다. Python의 b'\x82\xa7order' 같은 바이트 리터럴도 디코딩됩니다 — b'...' 래핑은 벗기고 이스케이프는 확장됩니다.

타임스탬프가 이상하게 나오는 이유는?

MessagePack에는 타임스탬프 확장 타입이 내장되어 있고, 라이브러리는 이를 JS의 Date로 디코딩합니다. JSON으로 문자열화하면 ISO 8601 문자열이 됩니다. 출력에 "2026-05-05T12:34:56.000Z" 같은 문자열이 보인다면, 인코더가 심어둔 진짜 타임스탬프이지 버그가 아닙니다.

입력이 부분적으로만 유효하면 어떻게 되나요?

디코더는 와이어 포맷을 한 바이트씩 읽습니다. 길이 접두사가 "다음은 16바이트 문자열"이라고 했는데 8바이트만 남아 있으면 파싱 에러를 던집니다. 오른쪽 패널의 에러 메시지는 어떤 타입 토큰에서 실패했는지와 대략적인 위치를 알려줍니다 — 보통 잘린 붙여넣기나 떠도는 바이트를 찾아내기엔 충분합니다.

바이너리 블롭(bin 패밀리)도 처리되나요?

네. bin 8/bin 16/bin 32 값은 Uint8Array 인스턴스로 돌아옵니다. JSON에는 네이티브 바이트 타입이 없어서 문자열화하면 {"0":1,"1":2,...} 형태로 렌더링됩니다. bin 필드를 꼭 base64로 받고 싶다면 여기서 먼저 디코딩한 뒤 JSON을 Base64로 도구로 변환하세요.

protobuf나 CBOR과 비교하면?

MessagePack은 스키마가 없습니다(키가 바이트 안에 들어 있습니다). CBOR은 비슷하지만 타입이 더 많고 인코딩이 다르며, protobuf는 디코딩 자체에 .proto 스키마가 필요합니다. 바이트가 protobuf라면 이 도구는 실패합니다 — 대신 Protobuf를 JSON으로 페이지를 써 보세요. CBOR이라면 와이어 포맷이 비슷하지만 같지는 않으므로, CBOR 전용 디코더가 필요합니다.

다른 MessagePack 도구

이 도구와 잘 어울리는 MessagePack 도구들 — 반대 방향, 검증, 바이트만 보기 등:

MessagePack을 JSON으로

입력

출력