Mozilla はどのように MIME タイプを決定するのか

導入

Mozilla ではすべてのデータが MIME タイプに基づいて扱われます。これはつまり、URI が読み込まれる都度 Mozilla はその MIME タイプを把握しなければならないということです。このためのいくつかの方法について解説していきます。

Content-Type「ヒント」

Mozilla には「content-type ヒント」という考え方があります。つまり例えば、<link type="text/css" rel="stylesheet" href="..."> 要素に対しては text/css を想定するということです。しかしこれよりもサーバが実際に送信する MIME タイプが（それが何であれ）優先されます。（この場合については標準準拠モードにおいてのみサーバによる指定が優先されます。Mozilla's Quirks Mode 及び Web 開発者 FAQ を参照のこと）

Mozilla 1.6alpha から <a href="..." type="foo/bar"> についても同様の扱いが可能になっています。

HTTP

HTTP URI については、通常 Mozilla はサーバから送信される MIME タイプを取得してそれを使います。 Internet Explorer の MIME タイプ推測処理とは違い、通常 Mozilla は文書のタイプを判別しません。しかし、Mozilla 1.7alpha からはこのように内容判別を行います。

サーバが次のうちのいずれか（大文字・小文字は区別する）

• text/plain
• text/plain; charset=ISO-8859-1
• text/plain; charset=iso-8859-1

の Content-Type を送信し、かつ Content-Encoding ヘッダは送信しなかったとき、Mozilla は受け取った最初のブロックの中身を見てテキストでないバイトの有無を確認します。テキストのバイトは 9～13、27、31～255 です。テキストでないバイトを見つけるとヘルパーアプリダイアログが表示され、そのファイルの拡張子に対応した MIME タイプが表示されます。

また、<img src> により読み込まれた画像については、Mozilla の画像ライブラリが実際の画像の種類を知るために内容判別を行います（拡張子判別は決してしません）。

サーバが Content-Type ヘッダを送信してこなければ、Mozilla は MIME タイプを知るのに Unknown Decoder を使います。

ファイル URI

file: URI については Mozilla は ExternalHelperAppService に MIME タイプを問い合わせます。

FTP

MIME タイプが指定されない HTTP URI 同様、FTP URI は Unknown Decoder によって調べられます。

Unknown Decoder

netwerk/streamconv/converters/nsUnknownDecoder.cpp に収められており、287 行目以降の sSnifferEntries 配列および DetermineContentType 関数によって決められます。 ここでの処理は次のとおりです。

• ファイルの最初に「マジックナンバー」がないか確かめます。現在これで PDF および Postscript の検出を行っています。
• ファイルが <?xml で始まっていればその URI の MIME タイプを ExternalHelperAppService で調べます。一般的な text/xml MIME タイプでは XUL ファイルが機能せず、XHTML ファイルは text/xml として解釈する際には別の DOM が生成されるためです。
• 画像ライブラリにコンテンツの MIME タイプを問い合わせます。これで Mozilla のサポートするすべての画像の種類について信頼性のある検出ができます。
• 一般的な HTML タグを探すことでデータが HTML であるかどうか調べます。
• MIME タイプ推測のため URI を ExternalHelperAppService に渡します。
• いずれも上手くいかない場合、バッファ（すなわちファイルの最初の 2～3 バイト）にヌル文字が含まれていないか検索されます。ヌル文字が見つからなければ text/plain とし、見つかれば application/octet-stream とします。

ExternalHelperAppService

（uriloader/exthandler/nsExternalHelperAppService.cpp に収められています。）

ファイルと MIME タイプの対応は次のように処理されます。

• BeOS ではオペレーティングシステムにファイルのタイプを問い合わせます。（まだ完全ではありません。バグ 217723）
• MacOS では OS にファイルのタイプを尋ねるのにタイプとクリエータのコードが使用されます。
• ハードコーディングされた拡張子リストを確認します（現時点で 13 項目。nsExternalHelperAppService.cpp 371 行目。これは処理速度のためです。OS に問い合わせたり環境設定を調べたりするよりもハードコーディングされたリストからデータを探す方が速いのです。）
• 拡張子がそのリストにない場合が問題です。まず、オペレーティングシステムに MIME タイプを問い合わせます。
• それでわからない場合、ユーザの指定したヘルパーアプリが拡張子により検索され、指定の MIME タイプが使用されます（編集/設定/ヘルパーアプリケーション のリストを参照）。これでわからなかった場合「その他の」MIME タイプリストが拡張子マッチで検索されます。418 行目のリスト全体も参照のこと。
• これでもわからない場合、読み込まれているプラグインの中に当該拡張子を扱えるプラグインがないか調べ、MIME タイプを問い合わせます。
• プラグインが登録されていない場合、拡張子とタイプが対応付けられた XPCOM カテゴリを拡張子で検索します。これにより拡張子からのさらなる対応付けがなされます。カテゴリ項目のキーは先頭にドットを含まない拡張子であり、値は MIME タイプです。拡張子は必ず小文字です。

ヘルパーアプリケーション

ヘルパーアプリケーションもある程度関係があります。Mozilla が取り扱えないタイプの URI を読み込んだ際にはヘルパーアプリダイアログが表示されます。このダイアログで表示される情報は以下のようにして得られています。

• 拡張子と MIME タイプのペアに対応するハンドラを OS に問い合わせます。ここでの拡張子は Content-Disposition ヘッダがあればそれを、なければ URL により決まることに注意して下さい。これが「デフォルトアプリケーション」として表示されます。
• 「データソース」（要はヘルパーアプリケーションのリスト）の項目を URI の MIME タイプで検索します。データソースはプロファイルディレクトリ内の mimeTypes.rdf です。見つからなければ拡張子（上記のように Content-Disposition）で検索します。いずれかの検索で見つかれば、そのアプリが「次で開く」フィールドに表示され、タイプの説明もこれを基にされます。
• 両方とも見つからない場合、その他の MIME タイプリストを再度検索し、拡張子リストと MIME タイプの説明が表示されます。