次の方法で共有

メディア タイプ ネゴシエーション

  • [アーティクル]

アプリケーション層のインターネット プロトコルの多くは、MultiPurpose Internet Mail Extensions (MIME) と呼ばれるシンプルで柔軟な形式でのメッセージ交換に基づいています。 MIME は電子メール メッセージを交換するための標準として誕生しましたが、現在では相互に理解されるデータ形式を MIME (メディア タイプ) として指定するために、さまざまなアプリケーションで使用されています。 このプロセスはメディア タイプ ネゴシエーションと呼ばれます。

メディア タイプは、タイプとサブタイプ (「text/plain」や「text/HTML」など) を示す単純な文字列です。 これらは、データにラベルを付けたり、要求を修飾したりするために使用されます。 たとえば、Web ブラウザーは、HTTP データ要求または情報要求の一部として、「image/gif」または「image/jpeg」メディア タイプを要求していることを指定し、Web サーバーはこれに応答します。適切なメディア タイプを返し、呼び出しがデータ要求の場合は、要求された形式のデータ自体を返します。

メディア タイプ ネゴシエーションは、多くの場合、既存のデスクトップ アプリケーションがシステム クリップボードとネゴシエートして、ユーザーが編集/貼り付けを選択したときに貼り付けるデータ形式を決定したり、ドラッグ アンド ドロップ操作中に IDataObject ポインターを受け取ったときに形式を照会したりする方法に似ています。 HTTP メディア タイプ ネゴシエーションの微妙な違いは、サーバーがどの形式を使用できるかをクライアントが事前に知らないことです。 したがって、クライアントはサポートするメディア タイプを忠実度の高い順に事前に指定し、サーバーは利用可能な最適な形式で応答します。

URL モニカは、インターネット クライアントとサーバーが BindToStorage 操作でデータをダウンロードするときに使用する形式に同意する方法として、メディア タイプ ネゴシエーションをサポートします。 メディア タイプ ネゴシエーションをサポートするには、クライアントは IEnumFORMATETC インターフェイスを実装し、RegisterFormatEnumerator 関数を呼び出してバインド コンテキストに登録します。 形式列挙子には、クライアントが受け入れることができる形式が一覧されます。 URL モニカーは、HTTP URL にバインドするときに、これらの形式をメディア タイプに変換します。

クライアントによって要求される可能なメディア タイプは、バインド コンテキストの呼び出し元によって登録された IEnumFORMATETC 列挙子から利用可能な FORMATETC 構造を通じて URL モニカに表されます。各 FORMATETC は、メディア タイプを識別するクリップボード形式を指定します。 たとえば、次のコード部分は、メディア タイプが PostScript であることを指定します。

FORMATETC fmtetc;
fmtetc.cfFormat = RegisterClipboardFormat(CF_MIME_POSTSCRIPT);
. . .

クライアントは、クリップボード形式を特別なメディア タイプ CF_NULL に設定して、URL が指すリソースの既定のメディア タイプを取得する必要があることを示すことができます。 この形式は通常、クライアントが最後に関心を持つ形式です。 バインド コンテキストに列挙子が登録されていない場合、URL モニカー、cfFormat=CF_NULL を持つ単一の FORMATETC を含む列挙子が利用可能であるかのように動作し、既定のメディア タイプを自動的にダウンロードします。

どのようなメディア タイプが使用される場合でも、クライアントにはその IBindStatusCallback::OnDataAvailable メソッドの pformatetc 引数によって選択が通知されます。 コールバックは、クライアントによる BindToStorage 呼び出しのコンテキスト内で発生します。

Note

受信したコンテンツが認識できないメディア タイプである場合、クライアントは自動的に RegisterMediaTypes を呼び出して新しいタイプを登録します。

 

URL モニカー