Base64エンコーディングの知識、すべてが1つの記事に！

今日、ますます多くのWebサイトがユーザーのブラウジング体験を向上させるために画像を使用しており、これらの画像は通常Base64の形式で保存およびロードされます。したがって、すべての開発者はBase64に精通している必要があります。それで、Base64とは何か、Base64を使用する理由、およびBase64の長所と短所を知っていますか？

Base64とは

Base64は、ネットワークを介して保存および送信されるバイナリデータの一般的な使用法です。Base64の1バイトは64ケースのみを表すことができ、エンコード形式の各バイトの最初の2ビットは0のみであり、残りの6ビットはコンテンツを表すために使用されます。

これを見ると、このエンコーディング形式ではストレージリソースを十分に活用できず、効率が低いことも誰もが理解できると思います。では、なぜそれがまだネットワークで一般的に使用されているのでしょうか。

実際、Base64はメール転送プロトコルで最初に使用されました。当時、メール転送プロトコルはASCII文字の送信のみをサポートし、ASCIIコードを使用してすべての英語の文字、数字、および一部の記号を表していました。ここで問題があります。英数字のみがメールで送信される場合、ASCIIを直接サポートできます。ただし、ファイル内の写真、ビデオ、およびその他のリソースを転送する場合、これらのリソースをASCIIに変換すると、英語以外の番号が表示されます。また、メールには多くの制御文字が含まれており、それらは非表示の文字になります。英語以外の文字と制御文字は、送信中にエラーが発生しやすく、メールの正しい送信に影響を与えます。このため、新しいエンコーディングルールが生まれました。バイナリは3バイトでグループ化され、各グループの3バイト（24ビット）は4 6ビットに変換され、各6ビットはルックアップテーブルに基づいています。 ASCIIシンボルに対して、これはBase64です。

Base64インデックステーブル

Base64は、8ビットのバイトデータを6ビットのバイナリセグメントに分割します。各6ビット単位は、Base64インデックステーブルの文字に対応します。簡単な例として、次の図のMのASCIIコードは77であり、バイナリに変換された後の最初の6つのバイナリビットは19に対応します。これは、Base64ディクショナリのTです。

もちろん、ここでも問題があります。エンコードするバイナリデータが3の倍数でない場合は、1バイトまたは2バイトが残ります。このため、Base64は最後に000000バイトの値を使用して補うため、バイト数は3で割り切れる可能性があり、補数は=で表され、=の数は追加されるバイト数を示すことができます。デコード中に自動的に削除されます。全体として、Base64エンコード後の文字は、エンコード前と比較して約33％増加しています。

画像のBase64エンコーディング

先ほど、Base64エンコーディングがWebサイトに小さな画像をロードする主な方法であることも説明しましたが、Base64は画像をどのように正確に処理するのでしょうか。

Webページでの画像の使用は通常imgタグの形式であり、imgタグのsrc属性はリモートサーバー上のリソースを指定することは誰もが知っています。Webページがブラウザに読み込まれると、ブラウザは外部リソースごとにプルリクエストをサーバーに送信します。ただし、これはネットワークリソースを大量に消費します。ほとんどのブラウザでは同時リクエストの数に制限があるため、Webページに埋め込まれている外部リクエストが多すぎると、ページの読み込みが遅くなりやすくなります。

また、Base64エンコーディングでは、データURLテクノロジを使用して、文字列の形式でページに直接埋め込まれた画像を作成し、HTMLと1つにすることができます。これにより、読み込み時に外部リソースの要求が回避されます

データURLを選択する理由

データURLテクノロジーが選択される理由については、従来の外部リソース参照方法と比較して、次の利点があります。

HTTPリクエストを減らします。
クロスドメインの問題を回避します。
背景画像の再利用など、別の画像のように使用できます。

このようにして、Base64エンコーディングは、さまざまなフロントエンド画像リソースをより迅速かつ便利に最適化できます。具体的な例を見てみましょう。

Base64エンコーディングは画像データを文字列にエンコードし、画像アドレスの代わりに文字列を使用していることがはっきりとわかります。一見、画像関連のコンテンツは含まれていないように見えますが、最終的にレンダリングされるのは間違いなく完全な画像です。

もちろん、Base64画像エンコーディングにデータURLを使用することは完全ではありません。これには、無視できない2つの欠点があります。

Base64でエンコードされたデータの量は、通常、元のデータ量の4/3です。つまり、データURL形式の画像は、バイナリ形式の画像よりも1/3大きくなります。
データURL形式の画像はブラウザによってキャッシュされません

ブラウザでキャッシュできないということは、リソースにアクセスするたびにリソースを再要求する必要があることを意味します。これにより、サーバーに大きな負荷がかかります。このデータをブラウザのキャッシュにも入れる方法はありますか？

読み込みのヒントをスピードアップ

実際、ほとんどのWebサイトの背景画像は、幅と高さがわずか数ピクセルの小さな画像で構成されており、背景画像にタイル表示されています。通常、小さな画像をGIFまたはPNG形式で保存してから、CSSのbackground-imageプロパティで画像アドレスを参照します。ただし、ブラウザ自体はURLに何が書き込まれているかを気にせず、必要なデータを取得する必要があります。したがって、CSSスタイルファイルを使用して、CSSスタイルシートにデータURLの形式で画像を保存できます。このようにして、ブラウザはCSSファイルと画像をキャッシュし、ページの読み込み効率をさらに向上させることができます。

上の図は単純な使用例です。このようにして、背景画像がそれ自体でHTTPリクエストを生成するのを回避するだけでなく、背景画像とCSSファイルをブラウザでキャッシュできるようにし、Webページが毎回読み込まれるのを回避します。背景画像の状況により、ユーザーのブラウジング体験がより速くスムーズになります。

日付URLテクノロジーとBase64エンコーディングの組み合わせにより、HTTPリクエストを効果的に削減し、ユーザーアクセスエクスペリエンスを向上させることができます。これは実際には開発プロセスのスキルではなく、読んだ後で役立つことを願っています。