画像のBase64エンコードを詳細に弄るCSS

base64エンコーディングとは何ですか？　　

概念を語る場ではないので、本題に入ります。画像のBase64エンコーディングとは、画像データ一式を文字列にエンコードし、その文字列を画像アドレスの代わりに使用できるようにすることです。

こんなことして何になるんだ？ウェブページで見るすべての画像は、それをダウンロードするためにhttpリクエストを消費することが分かっています（そのためcssspritesが作られましたが、後述するようにcssspritesには独自の限界があります）。

サーバーにリクエストを送る代わりに、HTMLと一緒に画像をローカルにダウンロードできればいいのですが、base64はその問題を解決してくれます。

では、画像のbase64エンコーディングはどのようなものなのでしょうか。例として、www.google.com的首页搜索框右侧的搜索小图标使用的就是base64编码。以下のことがわかります。

//write in css
#fkbx-spch, #fkbx-hspch {
  background: url(data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5B... EoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs=) no-repeat center;
}

//Written in the html code img tag
<img src="data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5B... EoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs=">

上記は、画像のbase64エンコードをcssとhtmlに記述したものです。 タグをそれぞれ使用します。base64エンコーディングはこのようになりますが、もちろんbase64エンコーディングは画像のエンコーディングにのみ使用されるわけではありません。

thunder://QUFodHRwOi8vZG93bi5zYW5kYWkubmV0L3RodW5kZXI3L1RodW5kZXI3LjEuNS4yMTUyLmV4ZVpa （コピーしないでください 私は本当に種ではありません）。

Xunleiの"special address"もBase64で暗号化されており、自分のGoogleに興味を持ち、繰り返さないようにします。

なぜBase64エンコードを使用するのですか？　　

では、なぜ画像ファイルの転送にbase64を使うのでしょうか？前述したように、httpリクエストを1回分節約できるからです。画像のBase64エンコーディングは、フロントエンドの最適化の一部と考えることができます。メリットは小さいが、その不足は大きく積み重なる。

そういえば、CssSpritesというテクニックも、ページ上のたくさんの小さな画像を1つの大きな画像にまとめて、httpリクエストを減らすために重要です。では、画像のbase64エンコーディングとCssSpritesの類似点と相違点、そしてトレードオフとは何なのでしょうか？

ここでbase64を使う前提条件として、base64でエンコードされた画像が十分に小さいことが挙げられますね。たとえば、ブログランドのロゴを考えてみましょう。

写真のように、ブログランドのロゴは3.27KBと非常に小さいのですが、これをbase64エンコーディングに変換すると、生成されるbase64文字列エンコーディングは4406となり、画像をエンコードした後の生成文字列エンコーディングサイズは、元のファイルより若干大きくなることが一般的です。base64エンコーディングはgzipで圧縮でき、圧縮率は50%以上に達するとしても、ある要素のcssスタイルが2000文字以上で書かれていることを想像すると、css全体の可読性に大きな影響を与え、コードの冗長性からここでbase64エンコーディングを使用することは損にならないでしょう。

では、base64エンコーディングは役に立たないということでしょうか？そうではありません。ページ内の画像が以下の要件を満たしている場合、Base64は有用です。

画像が十分に小さく、特定の用途のためにCssSpritesにできない場合、サイト全体での再利用性が高く、更新されることはない。

さて、この時点で画像の転送にbase64エンコードを使うのは、よく考えたら刃物の鋼鉄の上手な使い方とも言えますが、よく遭遇するルールのひとつが、ページの背景画像です。多くの場所で、私たちは非常に小さな画像を生成しますおそらく数px *数pxであり、その後、背景画像としてページをタイル。それは背景画像ですので、それはスプライトマップに置くことができないので、それはサイトの多くのページに存在しながら、この画像は、しばしばわずか数十バイトですが、非常に価値がない、httpリクエストが必要です。だから、なぜこの時点でbase64エンコーディングに変換しない？

ここに、わずか50バイトの2*2背景画像があります。これをbase64エンコーディングに変換すると、100文字強となり、httpリクエストよりも断然望ましいです。

CssSpritesをBase64エンコードしたもの　　

この2つの最適化方法をいつ使うかについて、私の意見を簡単に述べます。

CssSpritesを使用して、1つの大きな画像に統合する。

[...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] 　　 [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...]