GzipとDeflateはデータサイズを縮小する圧縮アルゴリズムですが、結果はテキストではなくバイナリです。この圧縮データをテキスト用に設計されたチャネル（URL、クッキー、JSONフィールド）で送る必要がある場合、さらにBase64でエンコードされます——そこから「Gzip/Deflate ↔ Base64」という組み合わせが生まれ、図表ツールがドキュメント全体の状態を共有可能なリンクに詰め込む際などによく使われます。
日本語テキストの圧縮率が英語と単純比較できない理由
日本語の文字はUTF-8で1文字あたり3バイトを使うため、同じ文字数の英語テキストよりバイト数では大きくなりがちです。しかし漢字1文字が英語の単語1つ分に近い情報量を持つことも多く、同じ内容を表すのに必要な文字数自体が英語より少なくなる傾向があります。さらに助詞や敬語表現など決まった言い回しの繰り返しが多いため、Gzipの圧縮効率で見ると、バイト単価の差はかなりの部分が相殺されます。
典型的な処理の順序
- 元のテキストをGzipまたはDeflateで圧縮する——サイズが縮小する。
- 圧縮されたバイナリの結果をBase64でエンコードする——サイズは少し戻るが、データはテキストになる。
- 結果の文字列をテキストチャネル経由で安全に送信する。
デコードは逆順で行われます：まずBase64→バイナリデータ、次にGzip/Deflateの展開→元のテキスト。
よくある用途
- アプリの状態全体をURLに詰め込み、共有したリンクを開けば同じ状態を再現できるようにする。
- 圧縮データをクッキーやデータベースのテキストフィールドに保存する。
- デバッグ：サードパーティのシステムやAPIがこの方法でエンコードしたコンテンツを展開して読む。
Gzipと「生の」Deflateの違い
Gzipは、実質的にはDeflateアルゴリズムを包むラッパー形式です——圧縮データの上に独自のヘッダーとチェックサム（CRC32）を追加します。「生の」Deflateにはこれらの付加バイトがないため結果はやや小さくなりますが、それが生の形式であると明示的に指定しない限り、gzipユーティリティで展開することはできません。この2つを混同することは、データを展開しようとした際に「invalid header」エラーが発生するよくある原因です。