gzip / deflate / zlib 圧縮・展開

gzip 圧縮とは？#

gzip は、ウェブ全体で使われる汎用のロスレステキスト・バイト圧縮器です——HTTP の Content-Encoding: gzip、サーバーから取得する .gz ファイル、無数のログ転送ツールの通信フォーマットを支えています。繰り返しのバイトパターンを見つけて短い参照で置き換えることで動くため、繰り返しのあるテキスト（ソースコード、JSON、CSV、ログ行）は劇的に縮みますが、すでに圧縮済みやランダムなデータ（JPEG、暗号化バイト）はほとんど動きません。

このページは、日常会話で「gzip」とひとくくりにされる3 つの関連アルゴリズムを提供します。これらは同じ DEFLATE コアを包むラッパーが違うだけです:

• gzip（RFC 1952）— 完全なパッケージ: マジックバイト付きのヘッダー、圧縮ペイロード、CRC32 + サイズのトレーラー。これが .gz ファイルや HTTP の gzip が使うものです。
• deflate（RFC 1951）— ラッパーなしの生圧縮ストリーム。出力は最小ですが、完全性チェックがなく、一部の API（古い Content-Encoding: deflate）はまさにこれを期待します。
• zlib（RFC 1950）— 軽量な 2 バイトヘッダーに Adler-32 チェックサムを加えたもので、他の 2 つの中間に位置します。

圧縮された出力はバイナリであるため、ツールはそれをBase64 または Hexテキストとして描画し、コピー、JSON への貼り付け、他へのパイプができるようにします。展開はその逆で、Base64 または Hex を読み取り、元の UTF-8 テキストを返します。

使い方#

1. ツールバーでアルゴリズムを選びます: gzip、deflate、zlib。
2. 方向を選びます: 圧縮（テキスト入力 → Base64/Hex 出力）または展開（Base64/Hex 入力 → テキスト出力）。
3. 出力エンコードを選びます: Base64 または Hex（展開モードでは、ツールがエンコードを自動検出するため、このセレクターはロックされます）。
4. 左側の入力ペインに貼り付けます。入力サイズはそのヘッダーに表示されます。結果は出力ペインを埋め、ヘッダーにサイズも示されます。
5. 圧縮後、前後バーチャートが現れ、ペイロードがどれだけ増えたか縮んだかを示します。コピーで結果を取り出すか、ダウンロードで .gz ファイルとして保存します。サンプルは典型的なログ行を読み込みます。クリアはすべてをリセットします。

主な特徴#

• 1 つのコントロールで 3 つのアルゴリズム。 gzip、deflate、zlib を切り替え、同じ入力に対してラッパーのオーバーヘッドが出力サイズをどう変えるかを正確に確認できます。
• 正直なサイズ比較。 前後バーチャートは実際のバイト数と符号付きパーセンテージ変化を示します——圧縮がペイロードを大きくするケースも含みます。これは gzip について知っておくべき最も有用なことの 1 つです。
• 展開時のエンコード自動検出。 Base64 または Hex を貼り付けると、ツールがどちらかを見分けるため、覚えておく必要がありません。
• 戻り方向の厳密な UTF-8。 展開されたバイトが有効な UTF-8 でない場合（アルゴリズムの選択間違い、切り詰められたペイロード）、ツールは間違いを隠す置換文字を出力するのではなく、その旨を告げます。
• ブラウザ内で動作。 圧縮は小さく遅延読み込みされるライブラリ経由でローカルに走ります。貼り付けたものがページから外に出ることはありません。

実例#

単一の短いログ行——サンプル入力 2026-08-06 INFO request handled path=/api/stats status=200（58 バイト）——をgzipとBase64出力で圧縮すると次のようになります:

H4sIAHcNdmoAAzMyMDLTNbDQNTBT8PRz81coSi0sTS0uUchIzEvJSU1RKEgsybDVTyzI1C8uSSwpVgCRpcW2RgYGACs/7EA6AAAA

前後バーチャートは直観に反する部分を明らかにします: プレーンテキストの 58 バイトは、gzip 圧縮し Base64 エンコードすると75 バイトになります。入力が短すぎ、ランダムすぎて DEFLATE が圧縮すべきものを見つけられず、gzip のヘッダー、トレーラー、Base64 のオーバーヘッド（約 33%）がそのまま上乗せされました。これがまさに、小さなペイロードの gzip 化が無意味な理由です。

対照的に、繰り返しのあるテキストです。行 transaction_id=txn_00001 status=paid amount=100 currency=usd\n を 8 つ複製すると合計 488 バイトになり、gzip はそれを84 バイト——元の約 17% まで縮めます。圧縮が報われるのはここです: 繰り返しが多いほど、縮み方は深くなります。

同じ短いログ行をdeflateに切り替えると出力は 57 バイト（ヘッダー/トレーラーなし）に下がり、zlibは 63 バイトに収まります——特定の通信フォーマットをターゲットにし、相手側と正確に一致させる必要があるときに便利です。

よくある質問#

gzip、deflate、zlib のどれを選ぶべきですか？#

相手側に合わせてください。.gz ファイル、HTTP Content-Encoding: gzip、そしてほぼすべての「圧縮された」API ペイロードにはgzipを使います。API が生 DEFLATE を明示的に規定している場合（一部のレガシー Content-Encoding: deflate サーバー）にだけdeflateを使います。ライブラリやプロトコルが明示的に zlib を名指す場合にzlibを使います。迷ったら、gzip が安全な既定です。

出力が入力より大きくなりました。バグですか？#

いいえ——小さな、あるいは高エントロピーの入力に対するロスレス圧縮の仕組みです。ストリームごとに固定のオーバーヘッド（ヘッダー、トレーラー、辞書のウォームアップ）があり、コンテンツの繰り返しが少なければ DEFLATE はそれを取り戻せません。実用的な目安: gzip は数百バイト以上のペイロード、とりわけ繰り返しのあるテキストで安定して勝ち始めます。小さな値には圧縮をスキップしてください。

展開でデータが有効な UTF-8 ではないと表示されます。何が悪かったのでしょう？#

通常は 3 つのうちのいずれかです: アルゴリズムを選び間違えた（データは zlib 圧縮だったのに gzip を選んだ、あるいはその逆）、Base64/Hex が切り詰められたか途中に迷いの空白がある、あるいは元がテキストではなくバイナリだった。他のアルゴリズムを順に試し、貼り付けたペイロードがどこで切り詰められていないか確認してください。

画像、動画、すでに zip 済みのファイルも圧縮できますか？#

何でも貼り付けられますが、得をすることはほぼありません。JPEG、PNG、MP4、.zip/.gz のような形式はすでに圧縮されているため、DEFLATE には絞るものが残っておらず、出力は同じサイズかやや大きくなります。gzip はテキストや構造化データのためのツールであり、バイナリメディアの 2 回目のパスではありません。