Base64の徹底理解：原理、応用、およびフロントエンドの実践

フロントエンド開発において、プロジェクトの最適化はパフォーマンスを向上させる上で重要な側面です。一般的な最適化戦略の1つは、埋め込まれた小さな画像をBase64文字列で適切に置き換えて、ページ上のHTTPリクエストの数を減らすことです。一方、これらは小さな画像である必要があり、通常は特定のキロバイト数を超えないサイズであることが強調されています。では、Base64とは一体何なのでしょうか？そして、なぜそれがフロントエンドの最適化において役割を果たすことができるのでしょうか？一緒に深く探求してみましょう。

初期の理解

次のような文字列に見覚えがあるかもしれません。

data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0c......

この固定形式を通じて、画像を表現でき、ブラウザはそれを認識して対応する画像を完全に表示できます。上記の例は、SVG形式の画像を示しています。実際には、ブラウザでサポートされている任意の形式で画像をロードすることもできます。この文字列はBase64エンコードに基づいて生成されており、base64,以降の長い文字列がBase64エンコードされた文字列です。

Base64の登場

インターネットの初期の頃、電子メールは最も効果的なアプリケーションの1つでした。しかし、初期の頃、電子メールのSMTP伝送プロトコルは7ビットのASCIIコードのみを伝送するために使用できました。ASCIIコードは英語に基づいて設計されていたため、英語圏以外の国からのテキストなどのリソースをこのプロトコルを通じて送信することができませんでした。この問題を解決するために、後にMultipurpose Internet Mail Extensions（MIME）が登場しました。MIMEは電子メールの主要な構造を追加し、非ASCIIコードのエンコードおよび伝送ルールを定義しました。これがBase64の起源です。文字エンコーディングの知識を深く理解したい場合は、フロントエンド開発で理解する必要がある文字エンコーディングの知識を参照してください。

基本的な定義

Base64は、64個の印刷可能な文字に基づいてバイナリデータを表現するエンコードおよびデコードの方法です。そのエンコードおよびデコードの特性のため、その主な機能はセキュリティではなく、コンテンツがさまざまなゲートウェイ間でエラーなく伝送されるようにすることです。これらの64個の印刷可能な文字には、26個の大文字A〜Z、26個の小文字a〜z、10個の数字0〜9、合計62文字、および他の2つの文字+と/が含まれています。Base64はインデックスベースのエンコードであり、各文字はインデックスに対応しています。具体的な関係図は次のとおりです。

これも名前の「64」の由来です。

エンコード方法

64は2の6乗に等しいため、Base64文字は実際には6バイナリビット（bit）を表します。ただし、バイナリデータでは、1バイトは8ビット（bit）に対応します。したがって、3バイト（3 x 8 = 24ビット）の文字列またはバイナリデータは、正確に4つのBase64文字（4 x 6 = 24ビット）に変換できます。なぜ3バイト単位でグループ化されるのでしょうか？6と8の最小公倍数は24であり、24ビットは正確に3バイトであるためです。具体的なエンコード方法は次のとおりです。

1. 3バイトごとにグループとして取得します。3バイトには合計24バイナリビットがあります。
2. これらの24バイナリビットを4つのグループに分割し、各グループに6バイナリビットが含まれるようにします。
3. 各グループの6バイナリビットの前に2つの00を追加して、32バイナリビット、つまり4バイトに拡張します。
4. 各バイトは64未満の数値に対応します。これは文字番号です。
5. 次に、文字インデックス関係テーブルに従って、各文字番号が文字に対応し、Base64エンコードされた文字が取得されます。

たとえば、上記の図の文字列twoは、対応するエンコーディングを取得するために変換されます。

ボリュームの増加

3つの文字がBase64変換を通じてエンコードされると、最終的に4つの文字になります。これは、各6ビットの位置に2つの0が埋め込まれて8ビットの位置になり、1バイトに対応するためです。ここでは、正確に3分の1多くなります。したがって、通常、Base64エンコードされたデータのボリュームは、元のデータよりも3分の1大きくなります。これが、前に述べたように、Base64エンコードを使用して画像を最適化する場合、小さなアイコンであることを強調する必要がある理由です。すべての画像をこの方法で処理すると、静的ファイルが大幅に増加し、適切ではありません。

「=」記号

3つの英字は、正確に4つのBase64文字に変換できます。文字の長さが3の倍数でない場合はどうでしょうか？どのようなルールに従うべきですか？Baseエンコーディングの実際の使用では、65番目の文字である=記号の存在がよく見られます。この等号は、この特別な状況を処理する方法です。3バイト未満の部分の場合、実際には24のバイナリビットになるまで、最後に0が追加されます。ただし、バイト数を計算するときは、全長を3で直接割る必要があることに注意してください。余りが1の場合、=が最後に直接追加されます。余りが2の場合、2つの=が追加されます。したがって、トランスコードされた文字列に追加する必要があるサフィックス等号は、1つまたは2つです。具体的な状況は、次の図に示されています。

図の2番目のケースでは、単一の文字dを使用して、インデックス文字テーブルのインデックス0を区別します。このとき、取得されたエンコーディングには、インデックス0に対応するA文字が表示され、2つの=が直接追加されます。

非ASCII文字

Base64はASCII文字のみをエンコードできるため、日本語文字などの非ASCII文字の場合、日本語文字を最初にASCII文字に変換してからエンコードする必要があります。

エンコードおよびデコード方法

btoaとatob

JavaScriptには、Base64エンコードを処理するための2つのネイティブメソッドbtoa()とatob()が用意されています。

• btoa()：文字列またはバイナリ値をBase64エンコードされた文字列に変換します。btoaメソッドはASCIIコード文字のみを直接処理できることに注意してください。非ASCIIコード文字の場合、エラーが報告されます。
• atob()：Base64エンコードされた文字列をデコードします。atobメソッドに渡される文字列パラメータが有効なBase64エンコード（非ASCII文字など）でない場合、またはその長さが4の倍数でない場合、エラーが報告されます。

btoa('you') // 'eW91'
atob('eW91') // 'you'
btoa('馬鹿') // Uncaught DOMException: The string to be encoded contains characters outside of the Latin1 range.
atob('y') // Uncaught DOMException: The string to be decoded is not correctly encoded.

日本語文字の処理

btoaとatobはASCII文字、つまりシングルバイト文字のエンコードのみをサポートしているため、通常遭遇する日本語文字は2〜4バイト文字です。したがって、日本語文字は最初にUTF-8エンコードに変換でき、UTF-8エンコードは文字と見なされるため、複数のシングルバイト文字をエンコードできます。日本語の場合、encodeURIComponent()とdecodeURIComponent()の2つのメソッドを使用できます。

• encodeURIComponent()：非ACSII文字をUTF-8にエンコードします。
• decodeURIComponent()：デコードに使用されます。

日本語をエンコードおよびデコードする方法は次のとおりです。

window.btoa(encodeURIComponent('馬鹿'))
// 'JUU5JUE2JUFDJUU5JUI5JUJG'
decodeURIComponent(window.atob('JUU5JUE2JUFDJUU5JUI5JUJG'))
// '馬鹿'

サードパーティライブラリ

たとえば、js-base64などです。フロントエンド開発では、このようなサードパーティライブラリを使用して、Base64関連の操作をより便利に処理することもできます。

一般的なフロントエンドアプリケーション

次に、フロントエンド開発におけるBase64エンコードの一般的な使用シナリオを見てみましょう。フロントエンドでのBase64のアプリケーションのほとんどは画像処理用であり、通常はDataURLメソッドに基づいています。Data URLは、data:プレフィックス、MIMEタイプ（データタイプを示す）、base64フラグ（テキストの場合はオプション）、およびデータ自体という4つの部分で構成されています。具体的な形式はdata:[<mime type>][;base64],<data>です。4番目の部分<data>、つまりデータ自体はBase64文字列です。

小さな画像のトランスコーディング

これは、最初に述べた画像の最適化のためにBase64を使用してリクエストの数を減らすシナリオです。imgタグまたはcssで使用できます。

<img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0c......Ii8+PC9nPjwvc3ZnPg==">

.icon {
  background: url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0c......Ii8+PC9nPjwvc3ZnPg==);
}

VueまたはReactフレームワークを使用する場合、url-loaderを介して、Base64に変換するアイコンのサイズを設定することもできます。

.loader('url-loader')
.tap(options => {
  options.limit = 10240 // 10kb
  return options
})

ファイルの読み取り

Web環境では、ファイルのデータを読み取るためにFileReader APIが提供されています。そのreadAsDataURL()メソッドを使用して、ファイルデータをBase64エンコードされた文字列データとして読み取ることができます。

let reader = new FileReader()
reader.onload = () => {
  let base64Img = reader.result
};
reader.readAsDataURL(file)

この方法は、画像アップロードでよく使用されます。

Canvasによる画像の生成

Canvasは本質的にビットマップ画像です。Canvasを画像としてエクスポートするためのtoDataURL()メソッドを提供し、この画像はBase64エンコードされた形式で保存されます。

const dataUrl = canvasEl.toDataURL()
// data:image/png;base64,PHN2ZyB4bWxucz0iaHR0c......

その他

画像表示の処理に加えて、Base64エンコードされた文字列は、特殊なデータ伝送、単純なエンコードおよび暗号化、コードの難読化、および一部の証明書でも確認できます。

まとめ

最後に、Base64の特性をまとめましょう。

• バイナリデータを文字列（ASCIIコード）に変換して、データ伝送を容易にします。
• ブラウザはBase64エンコードされた画像を直接表示できるため、リクエストが削減されます。
• エンコードされたデータは少なくとも3分の1大きくなり、エンコードおよびデコードを処理するには追加の方法が必要です。

Base64を深く理解することで、フロントエンド開発でより合理的に使用し、パフォーマンスを最適化しながら、さまざまなデータ伝送および表示要件をより適切に処理できます。

Leapcell: Webホスティングのための次世代サーバーレスプラットフォーム

最後に、Webサービスのデプロイに最適なプラットフォームをお勧めします：Leapcell

1. 多言語サポート

• JavaScript、Python、Go、またはRustで開発します。

2. 無制限のプロジェクトを無料でデプロイ

• 使用量に対してのみ料金を支払います — リクエストも料金も発生しません。

3. 無敵のコスト効率

• アイドル料金なしで従量課金。
• 例：25ドルで、平均応答時間60msで694万件のリクエストをサポートします。

4. 合理化された開発者エクスペリエンス

• 簡単なセットアップのための直感的なUI。
• 完全に自動化されたCI/CDパイプラインとGitOps統合。
• 実用的な洞察を得るためのリアルタイムのメトリックとロギング。

5. 簡単なスケーラビリティと高パフォーマンス

• 高い同時実行性を容易に処理するための自動スケーリング。
• 運用上のオーバーヘッドはゼロ — 構築に集中するだけです。

ドキュメントで詳細をご覧ください！

Leapcell Twitter: https://x.com/LeapcellHQ