[フロントエンド戦略]: 画像で遊ぶ Base64 エンコーディング_html/css_WEB-ITnose

はじめに

フロントエンドの仕事において画像処理は非常に重要な役割を果たします。画像の Base64 エンコードに馴染みのない人もいるかもしれませんが、この記事は純粋に技術的な観点から画像の Base64 エンコードについて説明するものではありません。ちょっと大げさなタイトルですが、簡単な説明を通じて、画像の Base64 エンコードとは何か、なぜそれを使用するのか、どのように使用して便利に使用するのか、そしてそれをどのように実行するのかを知っていただければ幸いです。フロントエンドの実際の作業を使用します。

Base64 エンコードとは何ですか?

概念について話したいわけではありません。早速ですが、画像の Base64 エンコードとは、画像データを文字列にエンコードすることです。画像アドレスを置き換える文字列。

こんなことをする意味は何ですか？私たちが目にする Web ページ上のすべての画像は、http リクエストを使用してダウンロードする必要があることを知っています (これが csssprites テクノロジーが登場した理由ですが、csssprites には独自の制限があり、これについては後述します)。

そうなんです、どうしても写真のダウンロードにはサーバーへのリクエストが必要です 写真のダウンロードはサーバーへのリクエストを必要とせず、同時にローカルにもダウンロードできればいいのですが。 HTML のダウンロードと同様に、base64 はこの問題を解決できます。

では、画像のbase64エンコードはどのようになっているのでしょうか？栗をください。 www.google.com のホームページの検索ボックスの右側にある小さな検索アイコンは、base64 エンコードを使用しています。

1 //在css里的写法2 #fkbx-spch, #fkbx-hspch {3     background: url(data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5B…EoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs=) no-repeat center;4  5     ...6 }

1 //在html代码img标签里的写法2 <img src="data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5B…EoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs=">

上記はそれぞれ、画像のbase64エンコーディングがcssにどのように記述されるか、およびそれがhtmlタグにどのように記述されるかを示しています。 Base64 エンコーディングは次のようになります。 もちろん、base64 エンコーディングは画像エンコーディングだけでなく、次のようにも使用されます。

へー、そうだね, Xunlei の「専用アドレス」 こちらも Base64 で暗号化されていますので、興味のある方はご自身でググっていただければと思いますので、詳細は省きます。

なぜBase64エンコーディングを使うのでしょうか？

では、なぜ画像ファイルを転送するためにbase64:URLを使用する必要があるのでしょうか?これは http リクエストを保存できるため、上記でも説明しました。画像の Base64 エンコードは、フロントエンドの最適化の一部とみなすことができます。利益は小さいですが、合計すると少額になります。

これに関して言えば、CssSprites テクノロジーについて触れなければなりません。これは、http リクエストを減らすために、ページ上の多数の小さな画像を 1 つの大きな画像に結合します。では、画像の Base64 エンコードと CssSprite の類似点と相違点は何でしょうか。また、どちらを選択するかを選択する方法は何でしょうか?

したがって、base64 を使用するための前提条件をここで明確にする必要があります。つまり、base64 でエンコードされた画像が十分に小さいということです。 Blog Park のロゴを例に挙げます。

以下の図に示すように、Blog Park のロゴはわずか 3.27KB で、すでに非常に小さいですが、これを生成して Base64 エンコーディングに変換すると、生成されるbase64文字列エンコードは個別に4406になります。 Base64 エンコーディングが gzip で圧縮できたとしても、CSS スタイルで記述された要素が 2000 文字を超えると、圧縮率は 50% を超える可能性があり、これは CSS の全体的な読みやすさに大きな影響を与えます。冗長性があるため、ここで Base64 エンコードを使用するのはお金の無駄になります。

ということは、base64エンコードはダメということでしょうか？さもないと。ページ上の画像が次の要件を満たしている場合、base64 が有効になります。

画像が十分に小さく、特定の用途によりスプライト (CssSprite) にできない場合は、Web サイト全体での再利用性が高く、基本的に更新されません

。したがって、この時点で画像を送信するために Base64 エンコードを使用することは、ブレードに使用される優れた鋼材であると言えます。よく考えてみると、このルールに適合するものの 1 つは、背景画像です。ページ。多くの場合、数ピクセル*数ピクセル程度の非常に小さな画像を作成し、ページを背景画像としてタイル表示します。これは背景画像であるため、スプライト画像に含めることはできませんが、このような画像は多くの場合、数十バイトしかありませんが、http リクエストを必要とするため、Web サイトの多くのページに存在します。では、この際、base64 エンコーディングに変換してみてはいかがでしょうか? 以下はわずか50バイトの2*2の背景画像です。 http リクエストと比較して、この変換は間違いなく賞賛に値します。

CssSprites と Base64 エンコーディング

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

CssSprite を使用して 1 つの大きな画像に結合します:

ページにはさまざまなスタイルがあります。スキンを変更する必要がある場合は、CssSprites を使用できます

ウェブサイトは完璧になり、3 日ごとに変更されることはありません (ボタンのサイズ、色など)

いいえ。使用時にグラフィック コンテンツを繰り返す必要があります

Base64 エンコードのコストがかからないため、画像更新のメンテナンスの困難さが軽減されます。 (ただし、CSS と画像を同時に変更する場合、スプライトが負担になる場合があることに注意してください)

base64 を使用して画像を文字列に直接エンコードし、CSS ファイルに書き込みます:

追加のリクエストはありません

非常に小さい画像や非常に単純な画像の場合は、gzip 圧縮できます。 (gzipによるbase64データの圧縮能力は通常、画像ファイルと同等かそれより強力です)

CSSメンテナンスの難易度を軽減します

背景画像の繰り返し使用など、別の画像のように使用できます

クロスドメインの問題はなく、キャッシュ、ファイルヘッダーやクッキーの問題を考慮する必要はありません

画像をより便利に Base64 エンコーディングに変換します

画像を Base64 エンコーディングに変換するツールはたくさんあります (私が使用したツールなど)この記事では http://www.pjhome.net/web /html5/encodeDataUrl.htm を参照していますが、これらの Web サイトの多くは海外の Web サイトであり、多くの場合ブロックされ、ログインできません。ここでは、Chrome ブラウザを使用する、より高速な方法を示します (すべての FEer は Chrome ブラウザを持っているべきだと思います =.=)。

Chromeで新しいウィンドウを作成し、変換する画像をブラウザに直接ドラッグし、コンソールを開き、以下に示すように「ソース」をクリックし、画像をクリックすると、画像のbase64エンコーディングが右側に表示されます、とても便利ですね。

限られた文体と浅い知識によるオリジナル記事です 記事に何か間違っている点がございましたら、ご指摘ください。