仕様書

分類

[4] URL scheme ごとに登録されるプロトコル取扱器と、 MIME型ごとに登録される内容取扱器があります。

[5] ネイティブアプリケーションの取扱器は、伝統的にヘルパーアプリケーションと呼ばれています。

[6] プラットフォーム側で管理される場合もあれば、 Webブラウザー独自で管理している場合、両方の機構を併用している場合もあります。

API

[7] Webページから著者が利用者に取扱器を提示する次の DOM API が用意されています。

文脈

[8] navigate から呼び出されます。

[9] プラットフォームの URL を開く API やファイルを開く API は、 (プラットフォーム側で管理されている) 取扱器を呼び出します。

取扱器データベース

[10] Webブラウザーは、取扱器データベースを持ちます。

[12] 取扱器データベースは、プロトコル取扱器群と内容取扱器群の 2つの集合を持ちます。前者はプロトコル取扱器の、後者は内容取扱器の集合です。

[17] 同じschemeやMIME型の (処理が異なる) 取扱器を集合中に複数含められるかどうかは、実装によります。 実装によっては、複数含まれていれば、利用者にどれを選択するかを都度問い合わせたり、 いずれかを既定のものと選ぶことができたりするかもしれません。

[18] 他に、 registerProtocolHandler や registerContentHandler では、悪意ある (または利用者体験への意識が低い) 著者による乱用を防ぐため、 (利用者が拒否したものも含め) 提示された取扱器 (やメソッドの呼び出しの状況) をある程度記憶しておくことが好ましいとされています。

[23] Unix 系の インターネットメールの MUA の MIME の実装は、 取扱器データベースに相当するヘルパーアプリケーション記述用のファイル形式として mailcap を採用していました。

[24] w3m のように Unix 系のWebブラウザーにも、 mailcap を流用してヘルパーアプリケーションを指定できるものがありました。

取扱器オブジェクト

[13] 取扱器は、次の状態を持ちます。

[14] Webアプリケーションの場合、次の状態を持ちます。

[19] ネイティブアプリケーションの場合、プラットフォーム依存の状態を持ちます。 例えばヘルパーアプリケーションのファイル名や、コマンドライン引数などを保持する必要がありそうです。

[15] プロトコル取扱器の場合、次の状態を持ちます。

[16] 内容取扱器の場合、次の状態を持ちます。

[21] 他に、プラットフォームによっては 「https://example.com/hoge/ 以下の取扱器」といった指定もできることがあります。

[20] その他に、既定の取扱器であるかどうか、利用頻度やアイコンなどの実装やプラットフォームに依存した情報も保持する必要があるかもしれません。

メモ