Data URI 和 MHTML

YanKavenのウェブサイト: http://dancewithnet.com/

データURI

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

データ:[][;base64],<データ>

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

HTML 4.01 は、前世紀にデータ URI スキームを導入しました。現在、IE6 と IE7 を除くすべての主流ブラウザは、データ URI のサポートに制限があります(画像のみ)。 CSS の img、input type=image、link および 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 は柔軟性がなく、使用が便利ではありません。 mht ファイル内のリソース参照は相対アドレスにすることができますが、それ以外の場合は絶対アドレスにする必要があります。 hedger の IE 向けソリューション「HTML に埋め込まれたクロスブラウザ Base64 エンコード画像」では、Content-type: message/rfc822 が宣言されているため、IE が MHTML に従って解析するように相対パスを使用します。Content-type を変更しない場合は、次のことが必要です。 MHTML プロトコルを使用するには、この時点で「MHTML – データが必要な場合: IE7 以前の URI」のように絶対パスを使用する必要があります。

応用

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

1. 大規模な Web サイトの CSS が大量の画像リソースを参照するようになり、リクエストの数が大幅に減少しました。
2. CSS と JavaScript は両方ともキャッシュでき、間接的にデータ キャッシュを実装できます。
3. CSS を使用すると、データ URI の再利用の問題を解決できます
4. 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/
*/
*背景画像:式(関数(ele){
ele.style.backgroundImage = 'url(mhtml:' +
document.getElementById('data-uri-css').getAttribute('href',4) +
'!03114501408821761.gif)';
}（これ））;

原文：http: //dancewithnet.com/2009/08/15/data-uri-mhtml/