第9回 HFS、HFS Plusの基本的概念【後編】：Undocumented Mac OS X（2/4 ページ）

[白山貴之，ITmedia]

クリエータとファイルタイプ

　リソースフォークと並ぶMac OS独特のものがクリエータとファイルタイプといったファイルの属性だ。クリエータおよびファイルタイプはどちらも32ビットのデータで、8ビットごと4つに区切られ4文字のASCIIで表記される。どちらのコードもAppleが管理しており、Appleおよびサードパーティーは割り当てられたコードを使うことでファイルを操作するためのアプリケーションやファイルの形式を指定できる。

　例えば、クリエータコード「MSIE」は「Internet Explorer」を意味する。このクリエータを持ち、ファイルタイプ「APPL」（アプリケーション）はそれがアプリケーション本体を意味する。一方ファイルタイプがHTMLならば、それはHTML文書だ。このHTML文書のクリエータがMSIEならば、ダブルクリックすると同じクリエータを持つインターネットエクスプローラが起動し、ファイルの読み込みが行われる。一方で同じファイルタイプでもクリエータがMOZBならばFirefoxが起動し読み込まれる。拡張子という風習のない旧Mac OSにとってこのクリエータとファイルタイプがアプリケーションを推測する唯一の手段であった。

　しかし、このファイルタイプとクリエータはユーザー自身が修正できないという問題があった。インターネットエクスプローラで保存したHTML文書には無条件でMSIEのクリエータがつき、Firefoxで見たいと思った場合にはいちいちFirefoxを起動してそちらから開くしか手がない。

　わずか4文字のコードは拡張性にも乏しく、Appleによる中央集権的な管理も現代的ではないといえる。ファイルタイプとクリエータは、簡単に変更できてしまう、あまりアテにならない拡張子という機構よりはマシな仕組みではあるが、一方で拡張子をベースとしたWindowsなどとの互換性が低く、ほかの文化との摩擦を生じる要因ともなった。

　HFSはもちろん、HFS Plusにもこのクリエータとファイルタイプを格納する領域が存在する。しかしMac OS Xではクリエータとファイルタイプは起動するアプリケーションを決める唯一の情報ではなく、拡張子などと同じく1つの参考情報にすぎない（前回のコラムおよび以下のコラム1参照）。

コラム1　LaunchServicesとUniform Type Identifier

　Mac OS 9までは、クリエータとファイルタイプがアプリケーションと文書を結びつける唯一の手段であった*。Mac OS XではクリエータやファイルタイプといったHFS独自の情報だけに依存せず、拡張子やMIME TYPEのようなほかの属性情報も参照するようなった。例えば、ディスク上に置かれたファイルをダブルクリックすると、以下の手順でファイルを開くアプリケーションを決定する。

1. ファイルにクリエータが記載されている場合は、そのクリエータを持つアプリケーションを探す
2. 拡張子が指定されている場合は、その拡張子を持つファイルを開けるアプリケーションを探す。このとき、拡張子の大文字小文字は区別されない点に注意（例えば.zと.Zは等価に扱われる）
3. ファイルタイプが指定されている場合は、このファイルタイプを開けるアプリケーションを探す

　なお、アプリケーションを探すときはMac OS Xのネイティブアプリケーションが先で、Classic環境上で動作する古いアプリケーションが後という優先順位を持つ。こうしたアプリケーションの検索を担当するのが、LaunchServicesというフレームワークだ。

　Tiger以前のMac OS Xでは、拡張子やファイルタイプごとにアプリケーションが割り当てられており、LaunchServicesが管理をしていた。つまり、次のようにそれぞれ異なる管理がなされていた。

• htmlという拡張子を持つ場合
• htmという拡張子を持つ場合
• 「HTML」というファイルタイプの場合
• text/htmlというMIME TYPEを持つ場合

　これは極めて煩雑で、事情を知らないユーザーからは謎めいた挙動に見えた。

　Tiger以降の Mac OS Xでは、UTI（Uniform Type Idntifier）が導入された。UTIはファイル形式を抽象化する概念である。例えば、HTML文書は「public.html」というUTIを持つ。拡張子やファイルタイプはこのUTIを推測するために用いられる。拡張子htmlもhtmも、そしてファイルタイプHTMLのファイルも、同じ「public.html」というUTIのファイルなのだ。Tigerでは、アプリケーションは拡張子やファイルタイプではなくこのUTIと関連づけられている。

　残念ながら、いまのところUTIは拡張子やファイルタイプ、MIME TYPEといった情報から間接的に推測されるものであり、UTIを直接ファイルに関連づける方法はない。しかし、Spotlightが採取するメタデータの1つkMDItemContentTypeとしてUTIは記録されている。将来的には、拡張属性としてUTIがファイルに直接記録され、アテにならない拡張子や将来性に欠けるファイルタイプ、拡張性や柔軟性に乏しいMIME TYPEといった情報に代わり、ファイルの種別を識別する手段になるのであろう。

Mac OS 9まではクリエータとファイルタイプがアプリケーションと文書を結びつける唯一の手段：実際には、ほかの環境から渡された、ファイルタイプやクリエータの設定されていないファイルを正しく開くために、拡張子を基にファイルタイプやクリエータを割り当てるMac OS Easy Openという機能が存在した。この機能は、後にFATでフォーマットされたディスクを読むPC Exchangeと統合、File Exchangeに名称が変更された。