Gzip และ Deflate เป็นอัลกอริทึมการบีบอัดที่ลดขนาดข้อมูล แต่ผลลัพธ์เป็นไบนารี ไม่ใช่ข้อความ หากข้อมูลที่บีบอัดนี้ต้องผ่านช่องทางที่ออกแบบมาสำหรับข้อความ (URL, คุกกี้, ฟิลด์ JSON) จะต้องเข้ารหัสด้วย Base64 เพิ่มเติม — นี่คือที่มาของคู่ "Gzip/Deflate ↔ Base64" ที่เครื่องมือแชร์สถานะแอปผ่านลิงก์มักใช้กัน
ทำไมข้อความไทยที่ไม่มีช่องว่างระหว่างคำจึงบีบอัดได้ดี
ภาษาไทยเขียนติดกันโดยไม่มีช่องว่างคั่นระหว่างคำ ต่างจากภาษาที่ใช้อักษรละตินซึ่งช่องว่างช่วยแบ่งขอบเขตคำให้ชัดเจน แต่ในภาษาไทยกลับมีคำเชื่อม คำลงท้าย และวรรณยุกต์ที่ปรากฏซ้ำ ๆ ตลอดทั้งข้อความอย่างสม่ำเสมอ ซึ่งรูปแบบที่ซ้ำกันนี้เองคือสิ่งที่ Deflate ใช้ประโยชน์ได้ดี โดยแทนที่รูปแบบซ้ำด้วยการอ้างอิงที่สั้นกว่ามาก ทำให้ข้อความไทยที่ต่อเนื่องยาว ๆ มักบีบอัดได้อย่างมีประสิทธิภาพไม่แพ้ภาษาที่มีช่องว่างคั่นคำ
ลำดับการทำงานทั่วไป
- ข้อความต้นฉบับถูกบีบอัดด้วย Gzip หรือ Deflate — ขนาดลดลง
- ผลลัพธ์ไบนารีที่บีบอัดแล้วถูกเข้ารหัสด้วย Base64 — ขนาดกลับมาใหญ่ขึ้นเล็กน้อย แต่ข้อมูลกลายเป็นข้อความ
- สตริงที่ได้จะถูกส่งอย่างปลอดภัยผ่านช่องทางข้อความ
การถอดรหัสเกิดขึ้นในลำดับย้อนกลับ: ก่อนอื่น Base64 → ข้อมูลไบนารี จากนั้นคลายการบีบอัด Gzip/Deflate → ข้อความต้นฉบับ
กรณีการใช้งานทั่วไป
- บรรจุสถานะทั้งหมดของแอปพลิเคชันลงใน URL เพื่อให้ลิงก์ที่แชร์เปิดกลับมาเป็นหน้าจอเดิมทุกประการ
- เก็บข้อมูลที่บีบอัดในคุกกี้หรือฟิลด์ข้อความของฐานข้อมูล
- การดีบัก: คลายและอ่านเนื้อหาที่ถูกเข้ารหัสด้วยวิธีนี้โดยระบบภายนอกหรือ API
Gzip เทียบกับ Deflate แบบ "ดิบ"
Gzip แท้จริงแล้วคือรูปแบบห่อหุ้มรอบอัลกอริทึม Deflate: มันเพิ่มส่วนหัวของตัวเองและค่าตรวจสอบ (CRC-32) ทับข้อมูลที่บีบอัดแล้ว ส่วน Deflate แบบ "ดิบ" ไม่มีไบต์เสริมเหล่านี้ ผลลัพธ์จึงกระชับกว่าเล็กน้อย แต่ไม่สามารถคลายด้วยยูทิลิตี้ gzip ได้หากไม่ได้ระบุอย่างชัดเจนว่านี่คือรูปแบบ raw ความสับสนระหว่างสองรูปแบบนี้เป็นสาเหตุที่พบบ่อยของข้อผิดพลาด "invalid header" เมื่อพยายามคลายข้อมูล