Windows メタファイル

Windows メタファイル( WMF ) は、1990 年代にMicrosoft Windows用に設計された画像ファイル形式です。元の Windows メタファイル形式はデバイスに依存しておらず (配置ヘッダーを使用するとデバイスに依存しにくくなりますが)、ベクター グラフィックとビットマップコンポーネントの両方を含めることができます。SVG ファイルと同様に動作します。WMF ファイルは、後にデバイスに依存しない拡張メタファイル(EMF ファイル) に置き換えられました。その後、EMF ファイル自体がEMF+ファイルによって拡張されました。

本質的に、メタファイルは、画面に画像を表示するための描画コマンド、プロパティ定義、グラフィックスオブジェクトで構成されるレコードのリストを格納します。^{[1]使用される描画コマンドは、Microsoft Windowsでの描画に使用される}グラフィックスデバイスインターフェイス（GDI）APIのコマンドと密接に関連しています。

メタファイルには主に3つの種類があります。WMFは、Windows 3.0で導入された16ビット形式です。これは、 Word、PowerPoint、PublisherなどのMicrosoft Officeアプリケーションのネイティブベクター形式です。2023年現在、Windowsメタファイル形式仕様のリビジョン17が利用可能です。^[2] WMFファイルに代わるEMFファイルは、同じ原理で動作しますが、32ビットファイル形式で、「コメント」レコード内にプライベートデータを埋め込むこともできます。^{[3] EMF+はEMFファイルの拡張機能であり、これらのコメントレコードに埋め込まれ、Windows} GDI+に似たコマンド、オブジェクト、プロパティを使用して画像やテキストを使用できます。^{[4][アップデート]}

オリジナルの16 ビットWMF ファイル形式は、1992 年のWindows 3.1 SDK ドキュメント^[5]の第 4 巻で完全に指定されていました (少なくとも、他の巻の個々の関数と構造の説明と組み合わせた場合) が、その仕様ではいくつかの詳細があいまいでした。これらのマニュアルは、書店で入手できる印刷本として発行され、クリックスルー EULAやその他の通常とは異なるライセンス制限はありませんでした (ソフトウェア バンドルの一部として購入された場合、ソフトウェアはバンドルの対象となるという一般的な警告のみ)。

時が経つにつれ、その歴史的な仕様の存在は忘れ去られ、いくつかの代替実装では、既存のWMFファイルからファイル形式を解明するためにリバースエンジニアリングに頼りましたが、これは困難でエラーが発生しやすいものでした。^{[6] 2006年9月、マイクロソフトは、} Microsoft Open Specific Promiseの文脈で、より完全な形式^[7]でWMFファイル形式の仕様を再度公開し、ファイル形式の実装者に特許権を主張しないことを約束しました。^[8]

マイクロソフトはその後、基本的なデバイス独立性を提供する「配置可能な」ファイル ヘッダーを使用しているにもかかわらず、WMF ファイルはデバイス独立性に関する実際の問題を抱えていたため、 32 ビットEMF ファイルを採用して WMF ファイルを廃止しました。マイクロソフトは、この形式を使用する開発者が「メタファイルにアプリケーション、場所、またはスケーリングに関するコメントを埋め込んでいる... 他の開発者は、さまざまなアプリケーション固有の情報を提供するヘッダーをメタファイルに追加している」ため、大きな互換性の問題が発生することを発見しました。^{[9]そのため、1992 年に}Windows NT 3.1で、マイクロソフトは拡張メタファイル形式 (EMF) ^{[10]を導入しました。これは}Win32 APIに基づいており、デバイス独立性を組み込んだ形式です。 ^{[11] [9]}これらは NT メタファイルとも呼ばれていました。^[12] Windows XPと GDI+のリリースにより、レコード セットを大幅に増やす必要があったため、マイクロソフトは既存の EMF ファイル形式の拡張として EMF+ をリリースしました。^{[10] [13]}

WMF、EMF、EMF+ ファイルはすべて、再生されてグラフィック出力を生成する一連のレコードで構成されています。一部のレコードは、グラフィックの描画方法を決定するために使用されるグラフィック オブジェクトを指定できるオブジェクトを定義します (例: ペンは線の色と幅を指定します)。これらの各オブジェクトはメタファイルに格納され、メタファイルの処理中にグラフィック オブジェクトの使用状況を追跡するオブジェクト テーブルに配置されます。オブジェクト テーブルは、メタファイル内で定義されたグラフィック オブジェクト構造へのインデックスの連想配列です。

WMF および EMF ファイルは、EMF ファイルの EMF+ レコードとは異なる方法でオブジェクトを処理します。WMF および EMF ファイルが処理されている間、オブジェクトが定義されると、レコードはオブジェクト テーブルに読み込まれます。オブジェクトが削除されると、オブジェクトはテーブルから解放され、識別子を再利用できます。特に、オブジェクトは、レコードの再生中に明示的に選択されるまで使用されません。^{[14] [15]}これは EMF+ ファイルの場合とは異なります。EMF+ ファイルでも、オブジェクト識別子とともにオブジェクトを記録するハッシュマップを介して連想配列が使用されます。ただし、オブジェクトを削除できる WMF ファイルや EMF ファイルとは異なり、既存のオブジェクトと同じインデックスを持つ新しいオブジェクトが作成されると、テーブル内のエントリが新しいオブジェクトに置き換えられます。EMF ファイルでは、オブジェクトを使用する前に明示的に選択する必要もありません。^[16]

WMF ファイルは元々デバイスに依存しないように設計されていなかったため、ファイルが記録された元のデバイスとは異なる出力デバイスではファイルを再生できませんでした。この問題の部分的な解決策は、Aldus Corporationによって発明され、「APM ヘッダー」と呼ばれる追加の「配置可能な」ヘッダーが追加されました。 ^[18]これにより、境界矩形、メタファイル バージョン、メタファイル サイズ、メタファイル内のオブジェクト数、およびメタファイル内の最大レコード サイズが追加されました。^{[19] [20]これは後に}MicrosoftによってWindows 2000からWMF 形式に組み込まれました。^[21]

WMFファイルは、一連のレコードによって構造化されており、いくつかの制御レコード（ヘッダーレコード^{[19] [22]、}前述のオプションの配置可能レコード^[23]）から始まり、ファイル終了レコードで終了します。^{[19] [24]}

制御レコードには、画像自体を構成するレコードがカプセル化されています。これらのレコードは、再生デバイス コンテキストと呼ばれる領域内で動作します。再生デバイス コンテキストとは、メタファイルがこの出力デバイスで「再生」されるときにデバイスのグラフィカル環境を構成するプロパティとオブジェクトの集合です。^[25]

制御レコード以外のレコードは、ビットマップ レコード、描画レコード、オブジェクト レコード、状態レコード、エスケープ レコードに大別できます。

ビットマップ レコードはビットマップ イメージを管理および出力します。

描画レコードはグラフィック出力を生成します。

オブジェクト レコードは、グラフィックス オブジェクトの作成と管理を行います。WMF ファイルには、グラフィックス オブジェクトと構造オブジェクトという 2 つの大きなカテゴリのオブジェクトがあります。構造オブジェクトは WMF で明示的に作成または削除されるのではなく、複雑な構造になります。たとえば、BitmapCoreHeader には、デバイスに依存しないビットマップの寸法とカラー フォーマットに関する情報が含まれています^。[52]このビットマップ自体は DeviceIndependentBitmap オブジェクトの一部です。^[53]ただし、グラフィックス オブジェクトはグラフィックス出力のパラメーターを指定し、WMF の再生中に再生デバイス コンテキストを設定します。^[54]

グラフィックスオブジェクトには、ブラシ（ブラシのスタイル、色、パターンを定義し、グラフィックスの領域をどのようにペイントするかを定義します）、フォント（テキストの表示方法に影響するプロパティを定義します）、パレット（アプリケーションによって定義されたデバイスに依存しない値として色を指定します）、ペン（線のグラフィック属性を指定します）、および領域（形状を定義する線分と曲線セグメントを指定します）があります。^[54]

状態レコードは再生デバイスコンテキストのグラフィックスプロパティを管理します。^[67]

エスケープ レコードは、WMF レコード タイプとして定義されていないレコードを介してメタファイルの機能を拡張する手段です。各エスケープ レコードには、レコード関数、エスケープ関数、およびエスケープ データが含まれます。

次のエスケープ レコードが WMF ファイルを構成します。

中止エスケープ レコードの周辺で、中止プロシージャ コードをレコード自体に格納するエスケープ レコードに重大な脆弱性が見つかりました。これは、Windows システム ( CVE - 2005-4560 を参照) とWine プロジェクト( CVE - 2006-0106 を参照) に影響しました。Secuniaによると、「この脆弱性は、特別に細工された SETABORTPROC エスケープ レコードを含む Windows メタファイル ファイル (.wmf) の処理エラーが原因で発生します。このようなレコードにより、WMF ファイルのレンダリングが失敗したときに任意のユーザー定義関数を実行できます。」^[142] Windows 3.1 SDK ドキュメントによると、SETABORTPROC エスケープは廃止され、WMF 脆弱性が発見されるずっと前に Windows 3.1 で同じ名前の関数に置き換えられました。^[143]ただし、廃止されたエスケープ コードは、Windows 3.0 用に作成された (または少なくとも下位互換性がある) 16 ビット プログラムとの互換性のために保持されました。この変更は、Microsoft が Windows NT 用の GDI の 32 ビット再実装を作成していたのとほぼ同時に発生し、この作業中に脆弱性が発生した可能性があります。

スティーブ・ギブソンがマイクロソフトが意図的にコードにバックドアを実装したと非難した後、 ^{[144] [145]} マーク・ラッシノビッチは反論し、次のように述べた。

...このフォーマットが設計された当時は状況が異なっていました。Windows 3.1 の「大規模」メモリ モデルでは、コードは本質的に場所に依存せず、Windows はパッチ適用されませんでした。そのため、Windows とアプリケーションの両方が、アプリケーション関数を WMF ファイルにコピーするだけで、後で同じアプリケーションで実行したときにそれが機能すると想定できました。いずれにせよ、開発者がアプリケーションが中止手順を含むディスク上のメタファイルを作成することを想定していたかどうかは明らかではありません。また、Microsoft の Stephen Toulouse が Steve の主張に対する Microsoft の反論で指摘したように、1990 年代初頭のセキュリティ環境は現在とは非常に異なり、WMF ファイルに保存されているものも含め、すべてのコードは本質的に信頼されていました。^[146]

米国シマンテック・セキュリティ・レスポンスのピーター・フェリー氏もギブソン氏に反対し、次のように述べている。

ギブソンは、SetAbortProc ハンドラを実行するためにスレッドが作成されると主張しました。実際には、ハンドラを実行するためにスレッドは作成されません。これはパーサーによって呼び出されるコールバックであり、パーサーはコールバックが返されるまで待機する必要があります。そうしないと、関数の全体的なポイント (印刷を中止する) が失われます。ギブソン自身が認めているように、ギブソンはドキュメントを読んでおらず (実際、Microsoft の Web サイトで無料で入手できるにもかかわらず、見つけられなかったと主張しています)、デバイス コンテキストは関数ハンドラでは利用できないと主張しました。もちろん、デバイス コンテキストは関数ハンドラで利用できます。これは、関数ハンドラに渡される 2 つのパラメータの 1 つであり (上記を参照)、印刷を中止するために必要です。最後に、ギブソンは、制御フローは Windows に戻ることができないと主張しました。これは、関数がスタックに渡されたパラメータを返して破棄するだけのことです。レコードが適切に形成されていれば、Windows は以前と同様にファイルの解析を続行します。 ...ギブソンは多くのことについて推測していたことを認めている。残念ながら、彼の推測は間違っていた。今では私たちはよりよく知っていると思う。^[147]

EMFファイルには3つのバージョンのヘッダーがあります。オリジナルのヘッダーは単なる画像のコンテナで、2番目と3番目のバージョンはオリジナルのヘッダーをカプセル化し、ピクセル形式のレコードとOpenGLレコードのサポートを含みます。3番目のバージョンは2番目のヘッダー拡張をカプセル化し、メートル法を使用してデバイス表面の距離を測定する機能を追加することでEMFの精度とスケーラビリティを向上させます。^[148]

各 EMF ヘッダーは EMR_HEADER レコードで始まり、メタファイル イメージが記録されたデバイスの関連プロパティを記録します。元の EMF ヘッダーには、80 バイトのヘッダーと、オプションの可変長の説明文字列があります。^[149]他のメタファイルには、元のヘッダーをカプセル化する拡張フィールドが含まれています。EmfMetafileHeaderExtension1は、元の EMF ヘッダーの直後に挿入されるレコードで、ピクセル形式記述子があるかどうか、ヘッダー内の記述子オブジェクトへのオフセット、およびメタファイルにOpenGLレコードが存在するかどうかを指定するフィールドを指定します。 ^[150]ピクセル形式記述子は、描画面の機能と、ピクセルがRGBAでエンコードされているか、カラー テーブルへのインデックスであるかを指定します。^[151] EmfMetafileHeaderExtension2は、レコードの直後に挿入されるレコードでEmfMetafileHeaderExtension1、デバイス表面をマイクロメートル単位で測定するための X 値と Y 値の 2 つのフィールドが含まれています。^[152]

WMF ファイルと同様に、レコードは機能別に分類できますが、EMF ファイルには WMF ファイルよりも多くのレコード タイプがあります。レコードは、コントロール、ビットマップ、クリッピング、コメント、描画、エスケープ、オブジェクト作成、オブジェクト操作、OpenGL、パス ブラケット、状態、および変換レコードに分類できます。

Windows XPのリリースにより、Enhanced Metafile Format Plus Extensions (EMF+) 形式が導入されました。EMF+ は、WMF/EMF が GDI への呼び出しを保存するのと同じ方法で、 GDI+ API への呼び出しをシリアル化する方法を提供します。

Windowsメタファイルの圧縮バージョンとして、圧縮Windowsメタファイル(WMZ)や圧縮Windows拡張メタファイル(EMZ) ^[153]も存在し、これらは基本的にgzip圧縮されたWMFファイルとEMFファイルです。

WMF 形式は、画像を復元するために Windows GDI レイヤーによって実行されるように設計されていますが、WMF バイナリ ファイルにはこの画像を構成する GDI グラフィック プリミティブの定義が含まれているため、WMF バイナリ ファイルをレンダリングしたり、他のグラフィック形式に変換したりする代替ライブラリを設計することが可能です。

• ポストスクリプト
• ベクター マークアップ言語(VML)
• スケーラブルベクターグラフィックス(SVG)

• Microsoft の Windows メタファイル形式仕様
• メタファイル – Windows アプリケーション
• fileformat.info のファイル形式の概要
• Windows メタファイルに関する FAQ