すべてのブラウザのデータURIおよびMHTML完全なソリューション

データURIは、RFC 2397によって定義されたソリューションで、小さなファイルをドキュメントに直接埋め込みます。次の構文を介して、小さなファイルを指定されたエンコーディングに変換し、それらをページに直接埋め込むことができます。

データ：[<mime-type>] [; base64]、<data>

1. MIMEタイプ：埋め込まれたデータのMIMEを指定します。その形式は[type]/[subtype]です。たとえば、PNG画像に対応するMIMEは画像/PNGです。パラメーターは追加情報を使用して、テキスト/PlainおよびText/HTMなどのCharSetパラメーターを指定できます。デフォルトはテキスト/プレーン、Charset = us-asciiです。
2. base64：後続のデータのエンコードはbase64です。それ以外の場合、データはパーセンテージ数（つまり、コンテンツのurlencode）でエンコードする必要があります。

前世紀に、HTML4.01はデータURIソリューションを導入しました。今日まで、IE6およびIE7を除くすべての主流のブラウザーはサポートされていますが、IE8はまだデータURIのサポートに制限があり、サポートオブジェクト（画像、IMG、入力タイプ=画像、リンク、CSS、およびデータボリュームが32Kを超えることはできません。

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

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

MHTMLは、MIME HTML（多目的インターネットメールエクステンションHTML）の略語であり、RFC 2557で定義され、マルチメディアページのすべての内容を同じドキュメントに保存します。このソリューションは、IE5.0以降にサポートするためにMicrosoftによって提案され、Opera9.0もサポートを開始しました。 Safariはファイルを.mht（MHTMLファイルの接尾辞）に保存できますが、表示することはサポートされていません。

MHTMLとData URIは、より強力な機能とより複雑な構文を備えた類似しており、データURIで再利用できない欠点はありませんが、MHTMLは柔軟性があり、使用するのに十分なほど便利ではありません。たとえば、リソースを参照するURLは、MHTファイルの相対アドレスになる可能性があります。そうしないと、絶対アドレスである必要があります。 「Cross Browser base64エンコードされた画像がHTMLに埋め込まれている」のIEのHedgerのソリューションは、Content-Type：Message/RFC822を宣言してMHTMLに従ってIEを解析するため、相対パスを使用します。コンテンツタイプが変更されていない場合、MHTMLプロトコルが必要です。現時点では、「MHTML-データが必要な場合：IE7以下」などの絶対パスを使用する必要があります。

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

1. リクエストの数は大幅に削減されており、大規模なWebサイトのCSSは現在、多数の画像リソースを参照しています。
2. CSSとJavaScriptの両方をキャッシュでき、データキャッシュを間接的に実装できます。
3. CSSを使用すると、データの再利用問題を解決できます。
4. CSSスプライトに別れを告げると、CSSスプライトはリクエストの数を減らすように見えましたが、不確実な状況で例外をもたらすことに加えて、CSSスプライトは人工画像の合併も必要です。マージツールがあったとしても、効果的にパズルとメンテナンスの困難をもたらす方法に多くの時間を人為的に費やす必要があります。特定の設計原則に従って、CSSスプライトを完全に放棄してCSSを書き込み、最終的にツールを使用して、「Data-URI Merge Styleシートと写真を使用してPythonで実装されているツールなど、サーバーへのアップロード中に画像をURIとMHTMLに変換します。
5. Base64エンコーディングは画像ファイルを1/3増加させ、Data URIとMHTMLの使用を同時に2/3の増加に相当します。ただし、CSSとJavaScriptはGZIP圧縮を使用できます。これにより、データボリュームの2/3を節約できます。そのため、GZIP圧縮を使用した後の最終データボリュームは（1 + 1/3） * 2 *（1/3）= 8/9です。

CSSでのデータURIとMHTMLの実装を容易にするために、データURI＆MHTMLジェネレーターを作成しました。

CSSファイルでMHTMLを使用する場合、URLは絶対パスを使用する必要があります。これにより、非常に柔軟性がありません。したがって、次のようなCSS式を使用して解決する（デモ）を検討できます。

/*

http://old9.blogsome.com/2008/10/26/css-expression-reloaded/

http://dancewithnet.com/2009/07/27/get-right-url-from-html/

*/

*背景イメージ：式（function（ele）{

ele.style.backgroundimage = 'url（mhtml：' +

document.getElementById（ 'data-uri-css'）。getattribute（ 'href'、4） +

'！03114501408821761.gif）';

}（これ））;