Gzip і Deflate — алгоритми стиснення, що зменшують розмір даних, але результат — бінарний, а не текстовий. Якщо стиснені дані потрібно передати каналом, розрахованим на текст (URL, cookie, JSON-поле), їх додатково кодують у Base64 — звідси пара «Gzip/Deflate ↔ Base64».
Чому одного стиснення недостатньо
Стиснені дані містять довільні байти, включно з такими, що конфліктують із синтаксисом текстового формату — наприклад, нульовий байт чи символи, які інтерпретуються як роздільники. Base64 «загортає» ці байти в безпечний текстовий алфавіт так само, як і для будь-яких інших бінарних даних.
Типовий порядок операцій
- Вихідний текст стискається алгоритмом Gzip або Deflate — розмір зменшується.
- Стиснений бінарний результат кодується в Base64 — розмір трохи зростає назад, але дані стають текстом.
- Отриманий рядок безпечно передається через текстовий канал.
Декодування відбувається у зворотному порядку: спершу Base64 → бінарні дані, потім розпакування Gzip/Deflate → оригінальний текст.
Типові сценарії використання
- Компактне представлення довгих JSON-конфігурацій у query-параметрі URL (наприклад, «поділитися посиланням зі станом»).
- Зберігання стиснених даних у cookie чи текстовому полі бази даних.
- Діагностика: розпакувати й прочитати вміст, закодований подібним чином сторонньою системою.
Коли варіант виправданий
Такий підхід має сенс для достатньо великих і стисливих текстових даних (JSON, XML) — на дуже коротких рядках накладні витрати Base64 і заголовків Gzip можуть переважити виграш від стиснення.
Gzip проти «сирого» Deflate
Gzip — це фактично формат-обгортка навколо алгоритму Deflate: він додає власний заголовок і контрольну суму (CRC32) поверх стиснених даних. «Сирий» Deflate не має цих службових байтів, тому результат трохи компактніший, але його не можна розпакувати gzip-утилітою без явного вказання, що це саме raw-формат. Плутанина між цими двома варіантами — поширена причина помилки «invalid header» при спробі розпакувати дані.