Gzip và Deflate là các thuật toán nén giúp giảm kích thước dữ liệu, nhưng kết quả là nhị phân, không phải văn bản. Nếu dữ liệu nén này cần đi qua một kênh dành cho văn bản (URL, cookie, trường JSON), nó sẽ được mã hóa thêm bằng Base64 — vì vậy mới có cặp "Gzip/Deflate ↔ Base64", được nhiều công cụ dùng để đóng gói toàn bộ trạng thái ứng dụng vào một liên kết có thể chia sẻ.
Vì sao chữ Việt có dấu vẫn nén tốt
Mỗi nguyên âm có dấu thanh trong tiếng Việt (à, á, ả, ã, ạ...) chiếm 2-3 byte trong UTF-8 thay vì 1 byte như chữ cái Latin thường, nên về lý thuyết văn bản tiếng Việt có vẻ nén kém hơn. Nhưng thực tế thì không đáng kể: các dấu thanh và nguyên âm lặp lại rất thường xuyên trong văn bản liền mạch, và chính sự lặp lại đó là thứ Deflate khai thác để thay các mẫu lặp bằng tham chiếu ngắn hơn, bù lại phần chi phí byte tăng thêm từ dấu.
Thứ tự thao tác điển hình
- Văn bản gốc được nén bằng Gzip hoặc Deflate — kích thước giảm đi.
- Kết quả nhị phân đã nén được mã hóa Base64 — kích thước tăng nhẹ trở lại, nhưng dữ liệu trở thành văn bản.
- Chuỗi kết quả được truyền an toàn qua một kênh văn bản.
Giải mã diễn ra theo thứ tự ngược lại: trước tiên Base64 → dữ liệu nhị phân, sau đó giải nén Gzip/Deflate → văn bản gốc.
Các trường hợp sử dụng phổ biến
- Đóng gói toàn bộ trạng thái của một ứng dụng vào URL để liên kết chia sẻ mở lại đúng giao diện đã lưu.
- Lưu dữ liệu nén trong cookie hoặc trường văn bản của cơ sở dữ liệu.
- Gỡ lỗi: giải nén và đọc nội dung được mã hóa theo cách này bởi một hệ thống bên thứ ba hoặc API.
Gzip so với Deflate "thô"
Gzip thực chất là một định dạng bọc quanh thuật toán Deflate: nó thêm header riêng và checksum (CRC32) lên trên dữ liệu đã nén. Deflate "thô" không có các byte phụ trợ này, nên kết quả gọn hơn một chút, nhưng không thể giải nén bằng công cụ gzip nếu không chỉ rõ đây là định dạng raw. Nhầm lẫn giữa hai biến thể này là nguyên nhân phổ biến gây ra lỗi "invalid header" khi cố giải nén dữ liệu.