MessagePack Converter: แปลง JSON เป็น binary ขนาดกะทัดรัด และถอดกลับได้
แปลง JSON เป็น MessagePack binary และถอด hex กลับเป็น JSON ได้ในเบราว์เซอร์ พร้อม hex preview, รองรับ UTF-8 และดาวน์โหลดไฟล์ สำหรับ payload จาก Redis, IoT และ API
Table of Contents
MessagePack Converter: แปลง JSON เป็น binary ขนาดกะทัดรัด และถอดกลับได้
ข้อมูลจำนวนมากที่ไหลอยู่ในระบบสมัยใหม่ไม่ได้ปรากฏอยู่ในรูปแบบข้อความธรรมดา ไม่ว่าจะเป็น payload ที่จองคิวอยู่ใน Redis, ข้อมูล telemetry ที่ส่งมาจากอุปกรณ์ IoT ผ่านช่องสัญญาณวิทยุที่จำกัด หรือ response จาก API ที่เน้นประสิทธิภาพ ล้วนถูก serialize ด้วย MessagePack ซึ่งเป็น binary format ขนาดกะทัดรัดที่เมื่อเปิดดูในเทอร์มินัลจะเห็นเป็นตัวอักษรที่อ่านไม่ออก ถ้า payload เหล่านี้เกิดปัญหา คุณไม่สามารถเปิดแก้ไขเหมือนไฟล์ข้อความได้ แต่ต้องถอดรหัส byte ก่อนจึงจะเห็นว่าข้างในมีอะไรอยู่จริง ๆ
ช่องว่างนี้คือเหตุผลที่เราสร้าง MessagePack Converter ขึ้นมา วาง JSON เพื่อดู encoding แบบ MessagePack ที่แท้จริง หรือวาง hex dump ของ MessagePack เพื่อถอดกลับเป็น JSON ที่อ่านได้ เครื่องมือมี hex preview ในตัวที่แสดง output ทีละ byte, จัดการ UTF-8 อย่างถูกต้องด้วย TextEncoder และ TextDecoder และดาวน์โหลดผลลัพธ์เป็นไฟล์ได้ในคลิกเดียว
ที่สำคัญคือเครื่องมือนี้ทำงานฝั่ง client ทั้งหมด จึงปลอดภัยกับ payload ที่มีข้อมูลลูกค้า token หรือข้อมูลที่ไม่อยากส่งขึ้นเซิร์ฟเวอร์ใด ๆ เพราะไม่มีอะไรออกจากเบราว์เซอร์ของคุณเลย
ทำไมต้องใช้ MessagePack Converter?
- เห็น byte จริง ไม่ใช่แค่สรุปผล — การ debug ข้อมูล binary ด้วย print statement หรือ output บางส่วนจาก library มักซ่อนสิ่งที่อยู่บนสายข้อมูลจริง เครื่องมือนี้แสดง payload ที่ encode แล้วทั้งหมดเป็น hex ทีละ byte
- ใช้ได้สองทิศทางในที่เดียว — encode JSON เป็น MessagePack และถอด MessagePack กลับเป็น JSON ในแท็บเดียว ทำให้การตรวจ round-trip ใช้เวลาไม่กี่วินาที แทนที่จะต้องเขียนสคริปต์เอง
- เรียนรู้ hex ได้ทันที — hex preview จับคู่ทุกค่าใน JSON กับ byte ที่ถูก encode ทำให้ format นี้เลิกน่ากลัว คุณจะเห็นด้วยตาตัวเองว่าเลขจำนวนเต็มเล็ก ๆ ยุบลงเหลือเพียง byte เดียว
- จัดการ UTF-8 อย่างถูกต้อง — TextEncoder และ TextDecoder ช่วยให้ข้อความหลาย byte อย่างภาษาไทย อีโมจิ และอักษร CJK encode และถอดรหัสได้ครบถ้วนไม่เพี้ยน
- ข้อมูลไม่หลุดออกจากเบราว์เซอร์ — การแปลงทั้งหมดเกิดขึ้นฝั่ง client ไม่มีการอัปโหลด ไม่มีการสมัครสมาชิก และไม่มีการเรียกเซิร์ฟเวอร์
- ดาวน์โหลดผลลัพธ์ได้ — บันทึก byte ที่ encode แล้วเป็นไฟล์ เอาไปใช้กับ Redis fixture, test bench ของ firmware อุปกรณ์ หรือ integration test ของ API ได้ทันที
ฟีเจอร์หลัก
| ฟีเจอร์ | สิ่งที่ทำ |
|---|---|
| แปลงสองทิศทาง | encode JSON เป็น MessagePack และถอด MessagePack กลับเป็น JSON |
| Hex preview | แสดง binary output ทั้งหมดเป็นเลขฐานสิบหก ทีละ byte |
| รองรับ UTF-8 | TextEncoder และ TextDecoder ทำให้ข้อความหลาย byte ไม่เสียหาย |
| ดาวน์โหลดไฟล์ | บันทึก payload ที่ encode แล้วเป็นไฟล์ binary สำหรับ test หรืออุปกรณ์ embedded |
| ทำงานฝั่ง client 100% | แปลงทุกอย่างในเบราว์เซอร์ ไม่มีการอัปโหลด ไม่มีบัญชีผู้ใช้ |
- ตั้งค่าศูนย์ รอศูนย์ — ไม่ต้องติดตั้ง SDK ไม่ต้องรอเซิร์ฟเวอร์ ผลแปลงแสดงทันทีที่วางข้อมูล
- เป็นเครื่องมือสอนในตัว — เพราะ hex preview อัปเดตตามทุกการแก้ไข เครื่องมือนี้จึงเป็นบทเรียนเชิงโต้ตอบเรื่อง binary serialization ไปในตัว
วิธีใช้ MessagePack Converter
- เปิด MessagePack Converter แล้ววางเอกสาร JSON ของคุณลงในช่อง input
- กด encode แล้วสังเกต hex preview โดยแต่ละคู่อักขระคือหนึ่ง byte และ byte แรกของทุกค่าคือ type prefix
- ถ้าต้องการ binary ดิบ ให้กดปุ่มดาวน์โหลดเพื่อบันทึก payload ที่ encode แล้วเป็นไฟล์
- ถ้าต้องการถอดกลับ ให้วาง hex dump ของ payload MessagePack ลงในช่องถอดรหัส แล้วกด decode เพื่อรับ JSON ที่อ่านได้
- ตรวจสอบ round-trip โดยเทียบผลที่ถอดได้กับเอกสารต้นฉบับ ถ้าโครงสร้างซับซ้อนให้จัดรูปแบบด้วย JSON Formatter ก่อนเทียบ
ทำไม MessagePack จึงเหนือกว่า Base64-JSON
เมื่อนักพัฒนาต้องส่งข้อมูลที่มีโครงสร้างผ่านช่องทางที่รับเฉพาะ byte วิธีแก้แบบที่เจอบ่อยคือเอา JSON ไป Base64 ก่อน วิธีนี้ใช้ได้ แต่ทำให้ขนาดโตขึ้น 33 เปอร์เซ็นต์ และฝั่งรับต้อง parse สองชั้น MessagePack แก้ปัญหานี้ตั้งแต่ต้น และการเข้าใจเหตุผลจะทำให้คุณใช้ hex preview ได้คุ้มค่าขึ้นมาก
เทคนิค type prefix
ทุกค่าใน MessagePack เริ่มต้นด้วย byte เดียวที่บอกชนิดข้อมูล และสำหรับค่าที่เล็ก byte นั้นยังฝังค่าไว้ในตัวด้วย จำนวนเต็มบวก 0 ถึง 127 ใช้เพียงหนึ่ง byte เท่านั้น ข้อความยาวไม่เกิน 31 byte เก็บความยาวไว้ใน prefix byte ตัวแรก และ map ที่มีไม่เกิน 15 รายการก็เก็บจำนวนรายการแบบเดียวกัน ตรงข้ามกับ JSON ที่ต้องจ่ายค่าเครื่องหมายคำพูดครอบทุก key, โคลอน และคอมมา ซึ่งเป็น overhead โครงสร้างล้วน ๆ ที่ MessagePack ไม่มีเลย
เทียบขนาดจริง: JSON กับ MessagePack
ลองดู telemetry จากเซ็นเซอร์แบบสมจริง: {"deviceId":"sensor-42","ts":1726123456,"temp":22.5,"hum":48,"status":"ok"} ในรูป JSON ที่บีบช่องว่างออกหมดแล้วจะได้ 75 byte แต่เมื่อ encode เป็น MessagePack จะเหลือประมาณ 53 byte หรือเล็กลงราว 30 เปอร์เซ็นต์โดยไม่ต้อง compression เลย ยิ่ง key สั้นและค่าเป็นตัวเลขมาก ยิ่งประหยัด เพราะค่าความชื้น 48 กลายเป็น byte เดียวคือ 0x30 และอุณหภูมิกลายเป็น float32 ห้า byte ส่วน gzip บีบ JSON ตัวใหญ่ได้มากกว่า แต่แลกมาด้วย CPU ทั้งสองฝั่ง และผลลัพธ์ถอดอ่านบางส่วนไม่ได้ ในขณะที่ MessagePack เล็กตั้งแต่การออกแบบ และยังถอดรหัสแบบ stream ได้
MessagePack อยู่ที่ไหนบ้าง
- การ serialize ใน Redis — client จำนวนมากเก็บ cached object และ job ในคิวเป็น blob แบบ MessagePack เพื่อลดการใช้ memory และการถ่ายโอนข้อมูล เทียบกับการเก็บเป็น JSON string
- Telemetry จาก IoT — อุปกรณ์บนเครือข่าย LPWAN และ NB-IoT จ่ายค่าเวลาวิทยุทุก byte การตัดเครื่องหมายคำพูดและโคลอนออกจึงช่วยยืดอายุแบตเตอรี่ได้จริง
- msgpack-rpc — รูปแบบ framing ของ request และ response ที่กระชับ ใช้ในเครื่องมืออย่าง RPC API ของ Neovim และการส่ง log ของ Fluentd
พื้นฐานการอ่าน hex dump
byte แรกของทุกค่าคือ type prefix และเครื่องมือจะไฮไลต์รูปแบบนี้ให้ดู prefix 0x82 หมายถึง fixmap ที่มีสองรายการ, 0xA2 หมายถึง fixstr ความยาวสอง byte, 0x18 คือ fixint เลข 24, 0xCB คือ float32 และ 0xC4 ใช้นำหน้า binary blob ที่ประกาศความยาวแบบ 8 บิต พออ่าน dump ลักษณะนี้คล่องแล้ว การไล่ดูค่าดิบจาก redis-cli --no-raw หรือ hexdump ของ frame จากอุปกรณ์จะกลายเป็นเรื่องที่อ่านออก ไม่ใช่การเดาสุ่มอีกต่อไป
กรณีใช้งานจริง
Debug ค่าใน Redis
consumer ของคิวเริ่มพังด้วยข้อความ "unexpected field" ทั้งที่ฝั่ง producer ยืนยันว่าไม่ได้แก้อะไร ลองดึงค่าที่น่าสงสัยด้วย redis-cli --no-raw แล้วเอา byte ที่ escape ไว้มาวางในตัวถอดรหัส ภายในสามสิบวินาทีคุณจะเห็นว่า producer เขียน status เป็น string "pending" แทนที่จะเป็น boolean ซึ่งเป็น drift แบบที่มองไม่เห็นใน application log
ถอดรหัส telemetry จากอุปกรณ์ IoT
ทีม firmware มักนิยามรูปแบบ uplink เป็น MessagePack แล้ว debug จาก frame ที่ capture ได้ วาง hex ของ telemetry frame ลงในตัวถอดรหัสเพื่อยืนยันชื่อ field, สเกลของค่า และรูปแบบ timestamp ถ้าเซ็นเซอร์วัดอุณหภูมิได้เป็นสองเท่าของที่ควรจะเป็น การถอดรหัสด่วน ๆ มักเผยว่า scale factor ถูกคูณซ้ำสองรอบ ไม่ใช่ฮาร์ดแวร์เสีย
ตรวจสอบสัญญาของ API
API แบบ binary มักเปลี่ยนเงียบ ๆ ลอง encode fixture ตามที่เอกสารระบุด้วยตัวแปลง แล้วเทียบ hex output ทีละ byte กับ request ที่ capture ได้ หรือถอด payload ที่ capture มาแล้ว diff JSON ที่ได้กับ schema วิธีนี้จับได้ทั้งกรณี integer กลายเป็น float, optional field หายไป และ encoding ของข้อความผิด ก่อนที่มันจะไปถึง consumer ใน production
ทำความเข้าใจ binary protocol
วิธีที่ดีที่สุดในการซึมซับ wire format คือลองจับต้องมัน ลอง encode object สอง field แล้วอ่าน byte ทั้งห้าหกตัว ทาย byte ถัดไปก่อนมองผล พอทำได้คล่อง format ที่ใกล้เคียงกันอย่าง CBOR และ Protocol Buffers จะดูไม่น่ากลัวอีกต่อไป เพราะทุกตัวใช้แนวคิด length prefix และ type tag เหมือนกัน
แนวปฏิบัติที่ดีเมื่อใช้ MessagePack
- ตกลง schema ให้ตรงกันทั้งสองฝั่ง — MessagePack ส่งชนิดข้อมูลได้ แต่ไม่ได้แนบเอกสารอธิบาย field มาด้วย ควรมี schema หรือ interface definition ที่ใช้ร่วมกัน เพื่อไม่ให้ producer กับ consumer เข้าใจ field เดียวกันคนละอย่าง
- ใช้ชื่อ field สั้นสำหรับ IoT — ทุก key ถูกส่งไปทุกข้อความ การเปลี่ยน temperatureC เป็น tc กับอุปกรณ์ที่ส่งวินาทีละครั้ง ประหยัดได้หลายเมกะไบต์ตลอดอายุ fleet ทั้งกอง
- ตรวจ round-trip ทุกครั้ง — เมื่อเปลี่ยน encoder หรือ schema ให้ encode fixture แล้วถอดกลับ จากนั้น diff กับต้นฉบับ ตัวแปลงนี้ทำขั้นตอนนี้ให้เป็นเรื่องกดสองคลิก
- ระวังชนิด integer กับ float — ค่า 22.5 ใน JSON จะถูก encode เป็น float32 แต่ค่า 22 ยังเป็นจำนวนเต็ม consumer ที่คาดหวังอีกแบบจะทำงานผิดพลาด จึงควร fix ชนิดตัวเลขไว้ใน schema
- แยกให้ออกระหว่าง byte ดิบกับ hex — hex preview ของเครื่องมือเป็นข้อความ แต่ไฟล์ที่ดาวน์โหลดเป็น binary จริง อย่าสลับสองอย่างนี้ใน test fixture ไม่งั้นจะเจอบั๊ก encode ซ้อน
- ใส่เวอร์ชันให้ payload — เพิ่ม field v เล็ก ๆ หรือ type byte นำหน้า เพื่อให้พัฒนา schema ต่อได้โดยไม่ทำอุปกรณ์และ consumer ที่ยังรันโค้ดเก่าพัง
พร้อมถอดรหัส payload แรกของคุณหรือยัง?
ลองหยิบ hex dump จากค่าใน Redis, frame จากอุปกรณ์ หรือ request ที่ capture ไว้ มารันผ่าน MessagePack Converter ดู การเห็น byte ที่อ่านไม่ออกค่อย ๆ กลายเป็น JSON ที่คุ้นเคยคือวิธีเร็วที่สุดในการสร้างความมั่นใจจริง ๆ กับข้อมูล binary
Related Tools You Might Like:
- JSON Formatter — จัดรูปแบบและตรวจสอบ JSON ที่ถอดได้ โดยเฉพาะ payload ที่ซ้อนกันลึก
- Base64 Tool — encode และ decode Base64 และ Base64URL ซึ่งเป็นตัวห่อข้อความที่มักปนอยู่ใน pipeline แบบ binary
- ASCII Binary Converter — แปลงข้อความเป็น binary และกลับ เพื่อดูว่าอักขระแต่ละตัวกลายเป็น byte อย่างไร
ขอให้สนุกกับการ encode!
คำถามที่พบบ่อย
ถ: MessagePack เล็กกว่า JSON เสมอไปหรือไม่?
ตอบ: โดยทั่วไปจะเล็กกว่า 20 ถึง 50 เปอร์เซ็นต์สำหรับ payload แบบ API และ telemetry ทั่วไป เพราะตัดเครื่องหมายคำพูด โคลอน และคอมมาออก พร้อมบีบค่าเล็ก ๆ ให้เหลือ byte เดียว ข้อความที่บีบอัดได้ดีอาจเล็กลงมากกว่าด้วย gzip แต่ต้องแลก CPU ทั้งสองฝั่ง และไม่สามารถอ่าน field ตรง ๆ ได้
ถ: เก็บค่า MessagePack ใน Redis ได้ปลอดภัยหรือไม่?
ตอบ: ปลอดภัยครับ เพราะผลลัพธ์ของ MessagePack ก็คือ byte ธรรมดา และ Redis เก็บ byte ได้ ใช้คำสั่งที่รองรับ binary อย่าง GET และ SET และให้ทุกตัวที่อ่าน key นั้นใช้ deserializer ตัวเดียวกัน
ถ: ตัวแปลงนี้อัปโหลดข้อมูลขึ้นเซิร์ฟเวอร์ไหม?
ตอบ: ไม่ขึ้น การ encode และ decode ทำงานในเบราว์เซอร์ด้วย JavaScript ทั้งหมด โหลดครั้งแรกแล้วใช้แบบออฟไลน์ได้ และไม่มี payload, ไฟล์ หรือ hex dump ใดถูกส่งไปที่เซิร์ฟเวอร์ใดเลย
ถ: ถอดรหัส MessagePack ได้ทุกชนิดหรือไม่?
ตอบ: รองรับชนิดพื้นฐานครบ ได้แก่ nil, boolean, จำนวนเต็ม, float, string, binary blob, array และ map ส่วน extension type ขึ้นกับการ implement ของแต่ละระบบ payload ที่พึ่งพา extension เฉพาะทางอาจต้องใช้ library ฝั่งผู้สร้างถึงจะถอดได้ครบ
ถ: MessagePack ต่างจาก JSON ที่ถูก Base64 อย่างไร?
ตอบ: Base64 เป็นการห่อ binary ไว้ในข้อความและทำให้ขนาดโตขึ้นราวหนึ่งในสาม ขณะที่ JSON ข้างในยังต้อง parse แยกอีกชั้น MessagePack คือ binary format ตัวจริง กล่าวคือเล็กกว่า มีชนิดข้อมูลในตัว และถอดรหัสได้ในขั้นตอนเดียว โดยไม่ต้องลอกตัวห่อข้อความออกก่อน