web-dev-qa-db-ja.com

データURIスキームを使用する理由

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

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

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

実行する利点は何ですか？

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

やりすぎ：

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

サーバー側のオーバーヘッドが少ない（多分）と思いますが、realdata URIを使用する利点/欠点は何ですか？

htmlbrowserclientdata-uri
49
Naftali aka Neal

Wikipedia によると：

利点：

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

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

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

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

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

  • マルチメディアページを単一のファイルとして管理することが可能です。電子メールメッセージテンプレートには、（添付ファイル）のように見えない画像（背景または署名用）を含めることができます。

短所：

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

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

  • データは単純なストリームとして含まれており、多くの処理環境（Webブラウザーなど）では、コンテナー（マルチパート/代替またはメッセージ/ rfc822など）の使用をサポートしていないため、メタデータ、データ圧縮、コンテンツネゴシエーションなどの複雑さを提供できません。

  • Base64でエンコードされたデータURIのサイズは、対応するバイナリのURIの1/3です。 （ただし、HTTPサーバーがgzipを使用して応答を圧縮する場合、このオーバーヘッドは2〜3％に削減されます）データURIにより、セキュリティソフトウェアによるコンテンツのフィルタリングがより困難になります。

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

56
Shaz

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

  • canvas要素の出力を画像として保存します。
  • cSVとしてテーブルのダウンロードを提供
  • あらゆる種類のオンラインエディタ（テキスト、描画、CSSコードなど）の出力のダウンロード
6
BiAiB

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

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

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

4
antitoxic

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

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

4
Andre Holzner

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

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

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

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

2
odoepner