1. ホーム
  2. Web制作
  3. HTML/Xhtml

すべてのブラウザに対応したデータURIとMHTMLの完全ソリューション

2022-02-04 07:28:44

データURI

データURI が提供するデータURIです。 RFC 2397 は、小さなファイルを文書に直接埋め込むためのスキームです。以下の構文で、指定されたエンコーディングで小ファイルをページに直接埋め込むことができます。

data:[<MIME-type>][;base64],<data>

  1. MIME-type:埋め込むデータの MIME . parameterは追加情報を指定するために使うことができ、より頻繁に使われるのはtext/plainやtext/htmなどのcharsetパラメータを指定するためです。デフォルトはtext/plain; charset=US-ASCIIです。
  2. base64: この後に続くデータのエンコーディングを宣言します。 ベース64 でなければ、データはパーセント記号でエンコードされなければなりません(つまり、コンテンツをurlencodeします)。

前世紀に HTML 4.01 でデータ URI スキームが導入されました。  であり、今日現在では は、IE6 と IE7 を除くすべての主要なブラウザでサポートされています。 しかし IE8では、データURIのサポートにまだ制限があります。 IE8では、URLはobject(画像のみの場合)、img、input type=image、link、CSSにしか対応しておらず、データ量は32K以上にはなりません。

長所

  1. HTTPリクエストの数を減らす TCPコネクションの消費と同一ドメイン下での同時ブラウザ数の制限なし。
  2. 小さなファイルの場合、帯域幅を減らすことができます。エンコードによってデータ量が増える一方で、httpヘッダーが減少し、httpヘッダーのデータ量がファイルエンコードの増加分より多くなると、帯域幅が減少します。
  3. HTTPSサイトの場合、HTTPSとHTTPの混在にはセキュリティ上のヒントがあり、HTTPSはHTTPに比べてオーバーヘッドが大きいので、この点ではData URIの方が明らかに有利です。
  4. マルチメディアページ全体をファイルとして保存することができます。

デメリット :

  1. 再利用ができず、同じ文書に同じ内容を何度も適用するため、何度も反復する必要があり、データ量が大幅に増加し、ダウンロード時間が長くなる。
  2. は単独でキャッシュできないため、その文書を含む文書が再読み込みされると、その文書も再読み込みされなければならない。
  3. クライアントが再デコードして表示する必要があり、ポイント消費量が増える。
  4. データ圧縮には対応しておらず、base64エンコードで1/3、urlencodeでさらにデータ量が増加します。
  5. セキュリティソフトによるフィルタリングに弱く、セキュリティ上のリスクもあります。

MHTML

MHTMLは MIME HTML (Multipurpose Internet Mail Extension HTML)の略。 マルチメディアページのすべてのコンテンツを同じ文書に保存するためのソリューションとして、RFC2557で定義されています。このソリューションはMicrosoftによって提案され、IE5.0とOpera9.0によってサポートされています。Safariは.mht(MHTMLファイルの接尾辞)形式のファイルを保存できますが、表示には対応していません。

MHTML と Data URI は、より強力でより複雑な構文を持ち、Data URI の "not reusable" という欠点がない点で似ていますが、MHTML は柔軟で使いやすくありません。例えば、リソース参照の URL は mht ファイルでは相対指定できますが、それ以外は絶対指定でなければなりません。のヘッダーは クロスブラウザのBase64エンコードされた画像をHTMLに埋め込む"。 IE 用の解決策では、IE が MHTML に従って解析するように Content-type:message/rfc822 を宣言しているため相対パスを使用しています。Content-type を変更しない場合は MHTML プロトコルを使用する必要があるので、次のような絶対パスを使用しなければなりません。 MHTML - データが必要なとき。IE7以下でのURI .

アプリケーション

データURIとMHTMLの組み合わせは、すべての主要なブラウザに対応する完全なソリューションです。キャッシュや再利用ができないという欠点があるため、ページ内で直接使用するには適していませんが、CSSやJavaScriptファイル内で画像を適切に使用することで、大きな利点があります。

  1. リクエスト数を大幅に削減し、大規模サイトのCSSは大量の画像リソースを参照するようになりました。
  2. CSSとJavaScriptの両方をキャッシュすることができ、間接的にデータキャッシュを実現します。
  3. データURIの再利用は、CSSで解決できる
  4. にさよならを告げる。 CSSスプライト CSSスプライトは、リクエスト数を減らすために導入されましたが は、不確実な場合に例外をもたらす また、CSSスプライトは人力による画像の結合が必要で、結合ツールを使っても、いかに効果的にパズルを組み立てるかに人為的に時間を割かなければならず、メンテナンスが大変です。ある設計原則に従えば、CSS Spritesを完全に捨ててCSSを書き、最終的にはサーバーへのアップロード時に画像をData URIとMHTMLに変換するツールを使って、以下のような方法で対応できます。 data-uriでスタイルシートと画像を融合させる でpythonに実装されているツールを使えば、大幅な時間短縮が可能です。
  5. 画像ファイルはbase64で1/3、Data URIとMHTMLは2/3になりますが、CSSとJavaScriptはgzipで圧縮でき、2/3のデータ量になります。 gzip圧縮 圧縮後の最終的なデータ量は

CSSでData URIとMHTMLを簡単に実装できるようにするため、CSSに データ URI & MHTML ジェネレーター を使って見ることができます。 Data URI & MHTMLアプリケーションの生成例 .

CSSファイルでアプリケーションMHTMLを使用する場合、URLは絶対パスを使用しなければならず、非常に柔軟性に欠けるので、これを解決するためにCSS式を使用することを検討してください( DEMO ) のようなものです。

   /*
   http://old9.blogsome.com/2008/10/26/css-expression-reloaded/
   http://dancewithnet.com/2009/07/27/get-right-url-from-html/
   */
  *background-image:expression(関数(ele){)
    ele.style.backgroundImage = 'url(mhtml:' +.
         document.getElementById('data-uri-css').getAttribute('href',4) +。
         '!03114501408821761.gif)';
   }(this))のようになります。