51

基本的に質問はタイトルにあります。

多くの人が、データ URI の作成方法とその中​​の問題について、stackoverflow という質問をしています。

私の質問は、なぜデータ URI を使用するのですか?

することの利点は何ですか：

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

やり過ぎ：

<img src="dot.png" alt="Red dot" />

サーバー側のオーバーヘッドが少ないことは理解していますが（おそらく）、data URIを使用することの実際の利点/欠点は何ですか?

4

5 に答える 5

61

ウィキペディアによると：

利点:

  • 埋め込みデータには HTTP 要求とヘッダー トラフィックは必要ないため、インライン コンテンツをデータ URI としてエンコードするオーバーヘッドが HTTP オーバーヘッドよりも小さい場合は常に、データ URI が消費する帯域幅が少なくなります。たとえば、長さが 600 バイトの画像に必要な base64 エンコーディングは 800 バイトになるため、HTTP 要求に 200 バイトを超えるオーバーヘッドが必要な場合、データ URI の方が効率的です。

  • 多数の小さなファイル (それぞれが数キロバイト未満) を転送する場合、これはより高速になる可能性があります。TCP 転送はゆっくりと開始する傾向があります。各ファイルが新しい TCP 接続を必要とする場合、転送速度は使用可能な帯域幅ではなく、ラウンドトリップ時間によって制限されます。HTTP キープアライブを使用すると状況は改善されますが、ボトルネックが完全に緩和されるわけではありません。

  • 安全な HTTPS Web サイトを閲覧する場合、Web ブラウザーは通常、Web ページのすべての要素を安全な接続経由でダウンロードすることを要求します。そうしないと、安全な要素と安全でない要素が混在しているため、セキュリティが低下していることがユーザーに通知されます。不適切に構成されたサーバーでは、HTTPS 要求は一般的な HTTP 要求よりもかなりのオーバーヘッドがあるため、この場合、データ URI にデータを埋め込むと速度が向上する可能性があります。

  • 通常、Web ブラウザーは、ドメインへの同時 HTTP 接続を特定の数 (多くの場合 2 つ) だけにするように構成されているため、インライン データによって他のコンテンツのダウンロード接続が解放されます。

  • 外部リソースへのアクセスが制限または制限されている環境では、コンテンツを外部から参照することが許可されていないか、または実際的でない場合に、コンテンツを埋め込むことができます。たとえば、高度な HTML 編集フィールドは、貼り付けまたは挿入された画像を受け入れ、それをデータ URI に変換して、外部リソースの複雑さをユーザーから隠すことができます。または、ブラウザーはクリップボードからの画像ベースのデータをデータ URI に変換 (エンコード) し、それを HTML 編集フィールドに貼り付けることができます。Mozilla Firefox 4 はこの機能をサポートしています。

  • マルチメディア ページを 1 つのファイルとして管理することができます。電子メール メッセージ テンプレートには、"添付ファイル" として表示されることなく、画像 (背景または署名用) を含めることができます。

短所:

  • データ URI は、含まれているドキュメント (CSS または HTML ファイルなど) とは別にキャッシュされないため、含まれているドキュメントが再ダウンロードされるたびにデータがダウンロードされます。変更が行われるたびに、コンテンツを再エンコードして再埋め込みする必要があります。

  • バージョン 7 までの Internet Explorer (2011 年 1 月現在、市場の約 15%) はサポートされていません。ただし、これはブラウザ固有のコンテンツを提供することで克服できます。Internet Explorer 8 では、データ URI が最大 32 KB に制限されています。

  • データは単純なストリームとして含まれており、多くの処理環境 (Web ブラウザーなど) では、コンテナー (multipart/alternative または message/rfc822 など) を使用して、メタデータ、データ圧縮、またはコンテンツ ネゴシエーションなどのより複雑なものを提供することをサポートしていない場合があります。

  • Base64 でエンコードされたデータ URI は、同等のバイナリよりもサイズが 1/3 大きくなります。(ただし、HTTP サーバーが gzip を使用して応答を圧縮すると、このオーバーヘッドは 2 ～ 3% に削減されます) データ URI により、セキュリティ ソフトウェアがコンテンツをフィルター処理することがより困難になります。

他の情報源によると、 データ URL はモバイル ブラウザーでは大幅に遅くなります。

于 2011-07-25T16:36:13.033 に答える
6

データ URI をうまく使用すると、サーバー側の「プロキシ」に頼らずに、クライアント側で生成されたコンテンツをダウンロードできるようになります。ここに私が考えることができるいくつかの例があります:

  • canvas 要素の出力を画像として保存します。
  • テーブルの CSV としてのダウンロードの提供
  • あらゆる種類のオンライン エディター (テキスト、描画、CSS コードなど) の出力のダウンロード
于 2012-05-23T15:06:00.277 に答える
4

いくつかの（C ++、Python）コマンドラインアプリケーションでデータURIスキームを使用し て、データプロットを含むレポートを生成しました。

1つのファイルがあると、レポートを電子メールで送信する（または一般的に移動する）のに非常に便利です。PDFと比較すると、（base64エンコーディングルーチン以外の）追加のライブラリは必要なく、ページ分割の面倒を見る必要もありません（そして、これらのレポートを印刷する必要はほとんどありません）。私は通常、これらのレポートをWebサーバーに配置せず、ブラウザーを使用してローカルファイルシステムで表示するだけです。

于 2012-09-08T09:40:25.560 に答える
4

主に、(何らかの理由で) CSS スプライトを使用できず、スタイリングに使用するすべての小さな画像をダウンロードしたくない場合に、これを使用します。

または、何らかの理由で、外部ページから画像をリンクさせたくない場合があります。これは他の方法論でも実現できますが、埋め込みも同様に機能します。

そうでなければ、個人的には大きな画像を写真としてエンコードしません。メディアを別のサーバーに置くことをお勧めします。Web サーバー関連のソフトウェアがすべてインストールされていないサーバー。単にメディアを配信するだけです。リソースのより良い使用。

于 2011-07-25T18:04:24.490 に答える
2

データ URI の真の価値は、クライアント側で生成されたコンテンツを、サーバーの往復を必要とせずにファイルのダウンロードとして利用できるようにするというBiAiBの意見に同意します。

「CSV としてのテーブルのダウンロードを提供する」ためにデータ URI を使用する実際の例は、私のブログ で説明されています。

私見ですが、パフォーマンス上の理由から画像 (またはその他のバイナリ リソース) データを HTML ファイルに埋め込むことは危険です。HTTP 接続の減少による速度の向上は無視できる程度であり、(テキスト) マークアップとバイナリ リソース (画像ファイル、ビデオなど) を分離するという優れた原則を破っています。

HTTP 1.1 のパイプライン化と、HTTP に対するいくつかの提案された改善は、HTTP ネットワーク速度の問題を処理するためのよりクリーンで優れた方法だと思います。

于 2012-07-21T15:15:42.643 に答える