データ URI と MHTML がすべてのブラウザー_HTML/Xhtml_Web ページ制作を完全に解決します

データ URI

データ URI は、小さなファイルをドキュメントに直接埋め込むために RFC 2397 で定義されたスキームです。次の構文を使用すると、小さなファイルを指定したエンコーディングに変換し、ページに直接埋め込むことができます:

データ:[][;base64],

1. MIME-type: 埋め込みデータの MIME を指定します。その形式は [type]/[subtype] パラメータです。たとえば、png 画像に対応する MIME は image/png です。パラメータは追加情報の指定に使用でき、多くの場合、text/plain や text/htm などのテキスト エンコード方法の指定に使用されます。デフォルトは text/plain;charset=US-ASCII です。
2. base64: ステートメントに続くデータのエンコードは base64 です。それ以外の場合、データはパーセントでエンコードされる (つまり、コンテンツを URLencode する) 必要があります。

前世紀HTML4.01 ではデータ URI スキームが導入されました。現在IE6 と IE7 を除くすべての主要なブラウザはをサポートしていますが、IE8 のサポートはデータ URI はまだ制限されています 。サポートされるのはオブジェクト (写真のみ)、img、input type=image、リンク、CSS の URL のみであり、データ サイズは 32K を超えることはできません。

利点:

1. HTTP リクエストの数を減らします。TCP 接続の消費がなく、同じドメイン名での同時ブラウザ数の制限もありません。
2. ファイルが小さい場合、帯域幅が減少します。エンコード後のデータ量は増加しますが、http ヘッダーのデータ量がファイルのエンコードの増分よりも大きい場合、帯域幅は減少します。
3. HTTPS サイトの場合、HTTPS と HTTP を併用するとセキュリティ プロンプトが表示されます。HTTPS は HTTP よりも高価であるため、この点ではデータ URI の方が明らかな利点があります。
4. マルチメディア ページ全体をファイルとして保存できます。

欠点:

1. 再利用できません。同じコンテンツを同じドキュメントに複数回適用すると、複数回繰り返す必要があり、データ量が増加し、ダウンロード時間が長くなります。
2. は単独でキャッシュできないため、それを含むドキュメントが再ロードされるときに再ロードされます。
3. クライアントは再デコードして表示する必要があるため、ポイントの消費量が増加します。
4. データ圧縮はサポートされていません。base64 エンコードするとサイズが 1/3 増加し、urlencoding 後はデータ量がさらに増加し​​ます。
5. セキュリティ ソフトウェアのフィルタリングには適しておらず、一定のセキュリティ リスクもあります。

MHTML

MHTML は MIME HTML (MultiPurpose Internet Mail Extension HTML) の略称で、マルチメディア ページのすべてのコンテンツを同じドキュメントに保存するための RFC 2557 で定義されたソリューションです。この解決策は、IE5.0 からサポートするために Microsoft によって提案され、Opera9.0 もサポートを開始しました。Safari はファイルを .mht (MHTML ファイル拡張子) 形式で保存できますが、その表示はサポートしていません。

MHTML はデータ URI に比較的似ており、より強力な機能とより複雑な構文を備えており、データ URI の「再利用できない」という欠点はありません。ただし、MHTML は、次のような柔軟性と利便性を備えていません。リソース参照の URL。mht ファイル内の相対アドレスにすることができます。それ以外の場合は、絶対アドレスにする必要があります。 hedger の 《HTML に埋め込まれたクロスブラウザ Base64 エンコード画像》IE のソリューションでは、Content-type: message/rfc822 が宣言されているため、コンテンツが MHTML に従って解析されます。この場合、《MHTML – データが必要な場合: IE7 以下の URI》 などの絶対パスを使用する必要があります。

適用

データ URI と MHTML の組み合わせは、すべての主流ブラウザの問題を完全に解決できます。これらはキャッシュして再利用できないため、ページ内で直接使用するのには適していませんが、CSS および JavaScript ファイルでの使用には適しています。写真を適切に使用すると、次のような大きな利点があります:

1. 大規模な Web サイトの CSS が大量の画像リソースを参照するようになり、リクエストの数が大幅に削減されました。
2. CSS と JavaScript の両方をキャッシュすることができ、間接的にデータのキャッシュを実現します。
3. CSS を使用すると、データ URI の再利用の問題を解決できます
4. さようならCSS スプライト、CSS スプライトはリクエストの数を減らすように見えましたが、不確実な状況では例外をもたらすに加えて、CSS スプライトには人工画像のマージも必要です。はマージ ツールですが、効果的にパズルを解くには依然として多くの時間を費やす必要があり、メンテナンスが困難になります。特定の設計原則に従う場合、CSS を記述するために CSS スプライトを完全に放棄し、最終的にサーバーにアップロードするときに画像をデータ URI と MHTML に変換するツールを使用できます。たとえば、 "データ URI を使用してスタイル シートと画像「」にある Python で実装されたツールを使用すると、時間を大幅に節約できます。
5. Base64 エンコードでは画像ファイルが 1/3 増加します。データ URI と MHTML を同時に使用すると 2/3 の増加に相当しますが、CSS と JavaScript は gzip 圧縮を使用できるため、画像ファイルの 2/3 を節約できます。データ量が増えるため、gzip 圧縮後の最終データ量 を使用すると、(1 1/3) * 2 * (1/3) = 8/9 となり、最終的なトラフィックが削減されます。

CSS でのデータ URI と MHTML の実装を容易にするために、データ URI と MHTML ジェネレーターを作成しました。生成されたデータ 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(function(ele){
ele.style.backgroundImage = 'url(mhtml:'
ドキュメント。 getElementByid（ 'data-uri-css'）