開発者ツール · Base64 エンコーダーおよびデコーダー
データ URI の説明: data:image/png;base64 の仕組みとその出所
· 背景
base64 エンコード
data: URL スキームは、小さなリソースをページに直接埋め込む方法として 1998 で指定されました。この投稿では、Base64 の文法、Base64 がオプションである理由、およびブラウザーが制限する場所について説明します。
1,300 文字の URL だったファビコン — 実環境の data: URI と出会い、その部分を読み取る
データ: URI は、小さなリソースを URL に直接埋め込み、個別の HTTP リクエストを回避します。この形式は RFC 2397 (1998 で定義) で指定されており、スキーム、オプションのメディア タイプ、オプションのエンコード フラグ、およびペイロード自体を含む文法を使用します。たとえば、data:text/plain,hello は、hello という単語を含むプレーンテキスト データ URI です。ブラウザは、HTTP リクエストを処理するのと同じ方法でこれを処理しますが、ネットワーク経由でコンテンツをフェッチする代わりに、URL 自体からコンテンツをデコードします。
データ URI は、小さな画像、CSS アイコン、テスト フィクスチャに最も一般的です。 Base64 エンコーディングの data: URI は次のようになります。 data:image/png;base64,iVBORw0K.... 内訳は次のとおりです。 data: はスキームです。 image/png はメディア タイプです。 ;base64 はエンコードフラグです。長い文字列は、Base64 でエンコードされた画像バイトです。ブラウザがこの URL を認識すると、Base64 をデコードして元のバイトを復元し、それらのバイトを使用して画像をレンダリングします。
目に見える文法からデータ URI を読み取る - メディア タイプ、オプションの Base64 マーカー、およびペイロード
エンコード フラグが省略された場合 (data:text/html,<p>hello</p>), ペイロードは、base64 ではなく、パーセントでエンコードされた UTF-8 テキストです。;base64 の存在により、適用するデコード ルールがブラウザに指示されます。データのメディア タイプ: URI は MIME タイプで、HTTP Content-Type ヘッダーで使用されるものと同じタイプの文字列です。image/png, text/plain, application/json と image/svg+xml は一般的な例であり、メディア タイプが指定されていない場合、デフォルトは text/plain;charset=US-ASCII. です。
ブラウザは、メディア タイプに基づいてバイトをレンダリングする方法を決定する必要があります。image/png, と表示されている場合、バイトは PNG です。 text/html, と表示されている場合、コンテンツは HTML です。間違ったメディア タイプを指定すると、混乱を招く結果が生じる可能性があります。 text/plain というラベルが付いた PNG ファイルは、画像ではなく文字化けとして表示されます。データ: URI では Base64 はオプションです。テキスト コンテンツの場合、パーセント エンコーディング (URL クエリ文字列で使用されるのと同じエンコーディング) は、多くの場合、base64 よりもコンパクトです。データ URI コンシューマーは、メディア タイプとカンマの前のマーカーからペイロードを解釈する方法を決定します。 Base64 エンコーダはペイロード文字のみを提供します。 MIME タイプを追加したり、バイトが PNG と SVG のどちらを記述するかを選択したり、組み立てられたアドレスを検証したりすることはありません。
Base64 がオプションである理由 — SVG およびプレーン テキストのパーセント エンコードされたテキスト ペイロードとバイナリの Base64
URI data:text/html,<p>Hello</p> には、HTML がリテラル文字として含まれます (引用符や山かっこなどの特殊文字はパーセント エンコーディングで行われます)。 Base64 は、テキストとして表現できないバイナリ データや、ペイロードにパーセント エンコーディングでは肥大化する多くの特殊文字が含まれる場合に役立ちます。小さな SVG またはテキスト ファイルは、より小さなパーセント エンコードになる可能性があります。バイナリ ファイルは Base64 である必要があります。データの構築: URI を手動で行うには、メディア タイプとエンコーディングを知っている必要があります。
SVG アイコンの場合は、data:image/svg+xml の後に、パーセントでエンコードされた SVG マークアップ、または ;base64 および Base64 でエンコードされたバイトを使用できます。パーセント エンコードの場合は、SVG を data:image/svg+xml, でラップし、山括弧、引用符、その他の特殊文字をパーセント エンコードします。結果は長いですが、人間が読める形式です。 Base64 の場合は、SVG バイトを取得して Base64 にエンコードし、data:image/svg+xml;base64, を生成してから、base64 文字列を追加します。通常、バイナリでは Base64 の方がコンパクトですが、SVG テキストではパーセント エンコード形式の方が短い場合があります。
作業例: データの構築: 小さな SVG の URI を手動で作成 — マークアップをテキストとしてエンコードし、文字列を組み立てる
ブラウザーや使用するアプリケーションはデータ URI に制限やポリシー制限を課すことができますが、このリポジトリは移植可能な数値の上限を確立しません。メモリ使用量、パーサーの動作、セキュリティ ポリシーも値が表示される場所によって異なるため、記憶されている制限に依存するのではなく、正確なターゲット ブラウザーと埋め込みコンテキストをテストしてください。
すべての HTML ファイルに 5 MB 埋め込み画像があると、ページ サイズが肥大化します。データ URI は、CSS アイコン、小さな画像、テスト データなどの小さなリソースに最適です。大きなファイルの場合、ブラウザが応答をキャッシュして複数のページにわたって再利用できるため、外部リクエストの方が高速です。データ: URI はページが読み込まれるたびにインライン化されます。
ブラウザとセキュリティの境界を想定するのではなく、使用するアプリケーションで検証する
一般的なしきい値は数キロバイトです。その下にある data: URI は効率的です。それ以上では、通常、外部ファイルの方が高速です。セキュリティとブラウザのポリシーにより、データが制限されます。つまり、特定のコンテキストでの URI の使用が制限されます。トップレベルのナビゲーション (データ (HTML コンテンツを含む URI) を指すリンクをクリックすること) は、フィッシングを防ぐためにブロックされることがよくあります。 script src 属性内の data: URI は任意の JavaScript を実行する可能性があり、セキュリティ リスクが生じます。
ブラウザはコンテンツ セキュリティ ポリシー (CSP) ルールをデータに適用します。URI。厳格な CSP はそれらを完全に禁止する場合があります。 img src または iframe src 内の data: URI は通常許可されますが、スタイルまたはスクリプト コンテキストに埋め込まれたものは制限される場合があります。ターゲット環境のブラウザの互換性とセキュリティ ポリシーを常に確認してください。 CSS のデータ URI は、小さな背景画像に一般的です。構文は同じです: url(data:image/png;base64,...).
データの場合: URI は依然として適切なツールです — CSS アイコン、電子メールで安全なインライン画像、テスト フィクスチャ
データが埋め込まれた CSS ファイル: URI はすべての画像を含む単一のファイルとして出荷できるため、HTTP リクエストが削減されます。これは、小さなアイコン セットや単純なグラフィックに役立ちます。 CSS に大きな画像が埋め込まれていると、ファイルが肥大化し、解析が遅くなります。最新のビルド ツール (webpack など) は、小さな画像を CSS の URI や外部画像を通常の URL に自動的に変換して、パフォーマンスのバランスをとることができます。
data: URI 形式は RFC 2397 によって定義されており、文法を指定する短い文書ですが、data: URI を使用できる場所と使用できない場所は定義されていません。ブラウザ ベンダーは、セキュリティとパフォーマンスの懸念に基づいて独自の制限を追加しています。
これでカバーされないもの — BLOB: URL、オブジェクト URL、およびファイル システム アクセス
一部のシステムには非推奨のデータがあります: 悪用を防ぐために、特定のコンテキスト (CSP レベル 3 のフォーム アクションなど) での URI サポート。 data: URI を使用する場合は、ターゲット ブラウザでテストしてください。 RFC ではこの形式は有効であると記載されていますが、ブラウザのセキュリティ ポリシーによってブロックされる可能性があります。
データ: URI を手動で作成することは、運用環境では一般的ではありません。ほとんどのビルド ツールとライブラリは変換を処理します。ただし、形式を理解することはデバッグに役立ちます。 CSS または HTML に長い data:image/... URL が表示された場合は、Base64 エンコーダおよびデコーダ ツールを使用してデコードできます。data:image/...;base64, プレフィックスを削除し、残りの文字列をツールに貼り付け、デコードして実際のバイトを確認します。
要点: 厳密な文法を備えた小さな形式 — Base64 エンコーダーとデコーダーがテキスト エンコード ステップを処理して有効な URI を組み立てる方法
SVG データ: URI の場合、テキスト フォームをパーセント デコードし、XML マークアップを読み取ることができます。データの構造を理解する: URI により、埋め込みリソースのトラブルシューティングが容易になります。データ URI は、リソースを URL として直接埋め込むことができる Web 標準 (RFC 2397) です。これらは、個別のキャッシュの恩恵を受けない、小さく安定したリソースに対して最も効率的です。この形式には、オプションのメディア タイプの指定とエンコード フラグ (base64 または暗黙のパーセント エンコード) が含まれます。
Base64 エンコードはバイナリ データには必須ですが、テキストの場合はオプションです。パーセントでエンコードされた SVG は読みやすくなります。ブラウザのセキュリティ ポリシーにより、データ: URI が使用できる場所が制限されるため、ターゲット環境の制限を理解することが不可欠です。 Base64 エンコーダおよびデコーダ ツールは、リソースを手動でエンコードしたり、埋め込み URI をデコードしてそのコンテンツを検査したりするのに役立ちます。