クリエイターコードとは何ですか?
80年代初頭、AppleはMacintoshを直感的に使いやすくするために、魔法のような独自の慣習を数多く開発しました。その一例が、タイプコードとクリエータコードを用いてシステムがドキュメントを識別するのに役立った、目に見えないファイルメタデータです。
各ファイルにはタイプとクリエータの両方のタグが付けられており、システムはファイルを開くことができるアプリケーションと、ファイルを開くべきデフォルトのアプリケーションを区別することができました。Finderは、この目に見えない形で関連付けられたファイルメタデータを使用して、同じ種類だが異なるアプリケーションで作成された異なるファイル（例えば、Graphic Converterで保存されたJPEGファイルとPhotoshopで保存されたJPEGファイル）にカスタムファイルアイコンを表示することもできました。
Finderはアプリケーションとファイルの間にシンプルな関連付けを維持していたため、Wordで作成された文書は自動的にWordで開き、複数の異なるテキスト文書はそれぞれ、作成に使用されたアプリケーションで開きました。ユーザーが少数のシンプルでモノリシックなアプリケーションしか持っていなかった時代には、この「タイプ／クリエーター」という表記は理にかなったものでした。
DOSとWindowsでは、オペレーティングシステムはファイルを開く方法を、ファイル名（例：myfile.doc）に明示的に含まれるファイルタイプ拡張子に基づいてのみ決定できました。DOSとWindowsでは、ファイルが特定のアプリケーションでしか開けない独自の形式で保存されていない限り、ユーザーがそのファイルをどのアプリケーションで作成したかを知るための支援を提供できませんでした。その意味で、Mac Creator Codesは、特定のファイルを特定のアプリケーションに関連付けながら、共通で相互運用可能なファイルタイプの使用を促進しました。
マック島を離れる
Creator Code の規約は、ドキュメントが DOS ディスクや Unix ベースのファイルサーバーに保存されたり、電子メールや Web 経由で他のプラットフォーム間でやり取りされたりするようになるまではうまく機能していました。DOS と Unix は Mac のメタデータを無視するため、Mac ユーザーから受信したファイルを開く方法がわかりませんでした。これらのファイルには、他のシステムがファイルの種類を解釈するために必要な単純なファイル拡張子が付いていないのが一般的だったためです。
さらに、これらのプラットフォームはMacのメタデータも削除していたため、Mac非対応プラットフォーム間でコピーされたファイルは、Mac上で正しく認識されなくなり、開くこともできなくなりました。Appleの魔法が失われたため、ファイルはただ空白の汎用アイコンで表示され、FinderもWindowsと同じように無力でした。Macユーザーにとっての問題は、最終的にクリエータコード情報をHFS以外のフォーマットのディスクで転送できるようにパッケージ化することで解決されました。しかし、他のプラットフォームのユーザーにファイルを送信する必要があるMacユーザーにとっては、これは役に立ちませんでした。
この問題に対する一般的な解決策は、Macファイルに冗長な情報、つまりタイプコードとクリエータコード、そしてファイル拡張子を割り当てることでした。NeXTおよびそれ以降のWindowsでは、UnixやDOS向けのMacスタイルのメタデータをサポートするファイルシステムが基盤になかったため、ファイルにはファイル拡張子のみが付与されていました。NeXTがAppleに与えた影響は、クリエータコードからファイル拡張子への移行において特に顕著でした。
昔からのMacユーザーは、ファイル拡張子を、Macを他のMacと相互運用するために必要な、醜くて不必要な機能だと考えていました。そのため、Mac OS Xが古いMacメタデータをサポートする一方で、Appleの新しいガイドラインで開発者がNeXT形式のファイル拡張子を使用して文字を表現することが義務付けられたとき、MacがMacの独自性を失いつつあるのではないかと懸念が広がりました。
Creator Codes の終焉に対する不満は、Spacial Finder の廃止 (Finder でフォルダーを複数のビューで同時に表示できないようにする、ファイルは最後に保存したビューにロックされ、変更するまでそこに表示されるようにするという考え) など、Apple で進行中の他の変更に対する不安と合致しています。
クリエイターコードが消滅した理由
しかし、Appleがクリエイターコードの廃止を計画したのは、単に面白半分で、あるいは単に怠惰で、あるいは単に最も普及しているオペレーティングシステムに合わせるためだったわけではありません。タイプコードとクリエイターコードは、Appleが計画していた新しいOS機能をサポートするには不十分だったのです。Appleは、機能を少なくしてやり過ごすのではなく、より多くのことを行うことに注力しており、クリエイターコードはその課題に応えられなかったのです。
約30年前に初代Macintoshでドキュメントを識別するために開発された基本的なファイルタイプとクリエータコードのシステムを超えた、高度なデータタイプ管理をオペレーティングシステムが処理する必要がある場面は数多くあります。また、システムは他のプラットフォームで使用されているファイルタイプ拡張子との互換性を維持しながら、これを実行する必要があります。
タイプコードとクリエータコードはそれぞれ4文字のラベルを使用していたため、拡張性は限られていました。これは、DOSの8.3形式の名前体系を改良したもので、ドキュメント、実行ファイル、JPEGファイルは、.doc、.exe、.jpgという難解な3文字のファイル拡張子に短縮されていました。しかし、新しいタイプコードやクリエータコードを作成するには、Appleへの登録が必要でした。これは、0000からZZZZまでの表現力のあるコード数が限られていたためです。
今日では、ファイルの作成に使用されたアプリが、必ずしも多くのユーザーがファイルを開く際に使用するアプリとは限りません。クリエーターコードシステムでは、ユーザーが作成後にクリエーターを個別に、あるいは選択したファイル全体、あるいは特定のファイルタイプのすべてのファイルに対して変更する簡単な方法が提供されていませんでした。2009年におけるユーザーの期待される操作（そして扱うデータの種類）の複雑さは、Appleが比較的シンプルなタイプコードとクリエーターコードを概念化した80年代初頭とは大きく異なります。
MIMEトーキン
Appleは、新しい機能をサポートするために、Uniform Type Identifiersと呼ばれるシステムでファイルとクリエータの情報を表現する柔軟な新しいシステムを発明しました。リッチファイルタイピングというアイデアは、全く新しいものではありませんでした。BeOSは90年代に、ファイルタイプとクリエータコードの概念を拡張するメカニズムとしてMIMEタイプを採用し始めました。しかし、MIMEには独自の問題もありました。
MIMEタイプは、ウェブサーバーや電子メールで、配信または添付されるファイルの種類を表すために使用されます。例えば、ウェブサーバーは、ファイルの拡張子が.jpgまたは.jpegであるのに加えて、画像を「image/jpeg」として識別する場合があります。MIMEでは、開発者が独自のタイプを作成することもできます。具体的には、IANA（ルートDNS命名機関）に特定の名前を登録するか、Appleが登録したタイプコードとクリエータコードを改良したアドホックな名前を作成します。
BeOSはウェブブラウザからコピーしたページを利用して、特定のMIMEタイプのファイルを開く際にどのヘルパーアプリを使用するかをユーザーが指定できるようにしました。BeOSが認識できない特殊なMIMEタイプ（「text/xml」など）に遭遇した場合、プレーンテキストファイルを開くために指定されたプログラムでそのファイルを開くように試みることができました。この「タイプ/サブタイプ」システムは、ファイルタイプを定義するための2つのバケットアプローチを提供し、必要に応じて特殊なファイルをより一般的なアプリで開くことを可能にしました。
しかし、MIMEは元々、インターネットのSMTPメールシステム（プレーンASCIIテキストのみを認識）を介して国際文字やバイナリ添付ファイルを送信するシンプルな方法として開発されました。MIMEは、送信されるデータの種類を識別するための単純で基本的なサポートしか提供していません。Appleは、バイナリデータの基本的なドキュメントタイプだけでなく、より詳細な情報も扱える、よりリッチで堅牢なシステムを求めていました。
3 ページ中 2 ページ目: ファイルを超えたデータの型指定、UTI の紹介。
タイプメタデータは文書作成に役立つだけではありません。クリップボードデータなど、ファイルに保存されていないデータを識別するのにも使用されます。コピー＆ペーストを行う際、Mac OSはコピーするデータのタイプを追跡する必要があります。例えば、特殊な書式のWordファイルから選択範囲をコピーする操作から始めて、そのデータをRTF（テキストエディットなど）やプレーンテキスト（検索フィールドや「名前を付けて保存」ダイアログの名前フィールドなど）のみを認識する場所に貼り付けたい場合があります。
関連するアプリケーションは、異なる貼り付け先に対応するために、可能な限り多くの異なる表現を提供する必要があります。例えば、WordはWord形式のテキスト、RTF、そして単純なプレーンテキストをペーストボードに提供します。クリップボードにコピーされた文書の選択範囲には、グラフィックやテキスト、さらには埋め込みビデオが含まれている場合もあります。ユーザーがコピー＆ペーストを直感的に操作できるようにするには、システムは基本的なデータしかサポートされていない場所にリッチデータを貼り付けられるようにする必要があります。つまり、適切なデグレード方法を認識する必要があります。そのためには、コピーされたデータの異なる表現を識別するための高度なデータ型決定メカニズムが必要です。
AppleはMac OS X Panther以降、ペーストボードデータ（コピー＆ペースト操作で情報を保存するために使用される内部クリップボード）のラベル付けに、柔軟で洗練されたタグ付けシステムを導入しました。このシステムは、データを一般的な用語と具体的な用語の両方で識別します。このシステムは、タグが、より具体的なデータタイプの階層にどのように当てはまるかを記録します。
統一型識別子の導入
AppleはTigerで、ファイルの種類を識別する手段として、これらのUTIタグを導入し始めました。ペーストボードと同様に、ファイルは独自のドキュメントタイプのUTIでタグ付けされる可能性がありますが、そのUTIはシステムに対して、より一般的にはプレーンテキストだけでなくリッチテキスト、あるいは最も単純にファイルとして自身を識別することができます。このUTIによるタイプ識別の階層構造により、システムはデータを一般的な方法と特定の方法の両方で処理できます。
UTI によるデータ型定義の高度な追加レイヤーは、Leopard が従来の Unix スタイルのパーミッションに加えて、ファイルパーミッションで使用する NT スタイルの ACL（アクセス制御リスト）を導入したことといくつかの点で似ています。ACL では、ファイルへの読み取り/書き込みアクセス権（ユーザー、グループ、その他）の 3 つのバケットではなく、任意の数の個別の、かつ非常に詳細なユーザーごとのパーミッションをファイルにタグ付けできます。
同様に、UTI では、ファイル タイプ識別データの 2 つのバケット (タイプと作成者、または MIME の「タイプ/サブタイプ」) ではなく、ファイルまたはコピーの選択に関連付けられた、より具体的なさまざまなタイプ情報が存在するため、その使用方法を豊かに表現できます。
UTIモデル
この魔法のような高度な機能は何をもたらすのでしょうか？まず、ペーストボードのデータ型とファイルの種類を調和させます。また、ドラッグ＆ドロップにも使用されます。これは基本的にワンステップのコピー＆ペースト操作です。さらに、アプリケーションサービスにも使用されます。これは、コピーとペーストの間にデータが変換され、通常はその場で変更される、より高度なコピー＆ペースト形式です。
UTI は、ファイルまたはデータの選択における非常に特定のデータ型を識別するための統一的な方法として確立されているため、オペレーティングシステムは、特定のデータビットが他のアプリケーションでどのように使用されるかについて、単一のモデルを維持できます。これにより、アプリケーションは、UTI でタグ付けされたデータを認識できない場合でも、システムがそのデータと互換性があり、アプリケーションが使用方法を知っている型と互換性があることを認識し、そのデータを使用できるようになります。
Mac OS X は、既存のタイプ/クリエーター コード、MIME タイプ、ファイル名拡張子を統合 UTI モデルに変換し、レガシーを新しい世界に橋渡しすることもできます。
3 ページ中 3 ページ目: UTI の定義、UTI の特徴。
例えば、「public.html」UTIは「public.text」に準拠していると定義されており、テキストを扱うことができるアプリであれば、HTMLの編集を想定していなくても、HTML形式のテキストにもアクセスできます。また、「com.editmax.htmlplus」のような、ベンダー固有の新しいUTIも「public.html」に準拠していると定義されており、これらも利用できます。
同様に、「public.text」は「public.data」と「public.content」の両方に準拠しているため、ファイルやコンテンツを一般的に操作する方法を知っているプロセスは、HTML ファイルや将来発明される新しい特殊な形式の HTML ファイルも具体的に操作できます。
UTI定義には、そのファイルの種類が何であるかを人間が読める（かつローカライズ可能な）形で記述し、そのファイルを表すために使用するアイコンを特定し、そのファイルの種類を表す代替方法の概要も含まれています。例えば、「public.html」UTIは、従来の「HTML」タイプコードと、HTMLファイルで使用される可能性のある.html、.htm、.shtml、.shtmなどの様々なファイル拡張子に関連付けられています。また、「text/html」というMIMEタイプにも関連付けられているため、UTIはデータ型の高度な定義となっています。
開発者は、より一般的な既存のUTIとの関連で定義する独自のUTIを作成できます。正式な登録は必要ありません。ベンダー固有のUTIは、設定ファイルと同様に「逆DNS」命名規則を使用するため、異なる企業が誤って同じラベルを使用することを防ぎます。ファイル拡張子の世界では、「file.doc」に特別な意味はありません。WordPerfectとWordはどちらも.doc拡張子を使用していたからです。UTIでは、Microsoftは「com.microsoft.word.doc」という形式でファイルの固有のデータ型を表現しています。
ちなみに、「逆DNS」が使われるのは、DNS自体が逆順に記述されているからです。「www.apple.com/mac/features.html」のようなWeb URLは、サーバー名階層において最も具体的なものから最も具体的でないものへと進み、スラッシュで始まると（Webサーバーのファイル階層において）より具体的なものへと進みます。これは、1,234.567という数字を4321.567と書くようなものです。おかしな話です。つまり、「逆DNS」は、他のあらゆるWeb URLで犯されている大きな間違いを修正するための試みであり、同様の命名階層が有用である可能性があります。Webを修正するには、もう手遅れです。
UTIの特徴
そのため、開発者はファイルを作成したアプリとその一般的な種類だけで定義するのではなく、ファイルに非常に具体的な作成者と種類を識別するUTIを割り当て、その新しいUTIラベルが、他のアプリ（およびシステム機能）が既に操作方法を知っている、より一般的なファイルの種類とどのように関連しているかをシステムに通知できるようになりました。また、開発者は、UTIタグ付きのファイルを「作成者」アプリで開くように指定することもできます。この機能は、エンドユーザーがFinderの環境設定で上書きできます。
UTI を使用して、Finder でファイルを開くときに使用するアプリケーションを管理したり (Launch Services 経由)、コピー アンド ペースト、ドラッグ アンド ドロップ、アプリケーション サービス (Pasteboard Manager 経由) の実行方法を決定することに加えて、Mac OS X は Spotlight インポーター、Automator アクション、Quick Look プレビュー内で UTI を使用し、またナビゲーション サービスでも UTI を使用して、開くダイアログや保存ダイアログに表示される関連ファイルを絞り込みます。
Appleは、Launch Servicesにおいて、開発者に対し、アプリケーションが作成するドキュメントのUTIを定義し、アプリケーション内に含めるよう指示しています。ベンダー固有のUTIは、従来のTypeとCreatorのように機能しますが、開発者は事前にAppleに定義を登録する必要はありません。そのため、AdobeはPhotoshopファイルに「8BIM」というクリエータと「8BPS」というタイプを登録するのではなく、「com.adobe.photoshop-image」というUTIによって、これらのファイルをPhotoshopで開くエンティティとして、表現力豊かかつ一意に識別します。
Photoshopドキュメントは、他のアプリケーションでも開くことができます。概念的には、既存の「com.adobe.photoshop-image」UTIの特殊バージョンとして定義される新しいUTIを追加するだけで、他のアプリケーションがデフォルトで独自のアプリケーションで開くPhotoshopドキュメントのバージョンを作成することもできます。これにより、システムはPhotoshopファイルに対して既に実行できるすべての操作（コピー＆ペースト、検索用インデックス、Automatorアクションでの使用、クイックルック）を、特殊化された「Photoshop+」UTIで定義された新しいドキュメントに対して実行できます。タイプコード/クリエーターコードではこれは実行できません。
ペーストボードにおけるUTIの使用については上記で紹介しました。iPhone 3.0の新しいコピー＆ペースト機能でもUTIが使用されているのは当然のことです。Appleがこの機能のiPhoneへの導入に「なぜこんなに時間がかかったのか」と疑問に思われた方もいるかもしれません。それは、セキュリティ問題に悩まされるような場当たり的な解決策ではなく、長期的かつ堅牢なソリューションをプラットフォームが選択したためです。
Spotlight検索では、Appleは開発者に対し、インポータープラグインがインデックスできるファイルの種類に応じたUTI定義を提供するよう指示しています。システムは、利用可能な最も具体的かつ特化したインポーターを使用して、そのUTIに一致するファイルをインデックスします。
Automatorアクションの場合、開発者はアクションがデータの入力方法を認識するUTIと、アクションが出力するUTIを指定します。Automatorアクションは基本的に、1つのファイルまたは選択範囲からデータをコピーし、変換して結果を出力するようにコンパイルされた、モジュール化された一連のサービスです。
Quick Lookでは、プラグインは表示可能なファイルのUTIを指定します。これにより、システムは特定のファイルタイプを表示するために最も特化したプラグインを選択できます。つまり、開発者は、Apple独自の基本的なテキストQuick Lookプラグインが提供する機能よりも多くの機能（色分けされたマークアップタグなど）を備えた、XMLなどの複雑なテキストUTIを表示するための専用プラグインを作成できます。Quick LookはUTIの応用でもあり、ユーザーが希望するデフォルトの起動アプリに影響を与えることなく、システム自体がファイルを開いて素早く表示できるようにします。
クリエイターコード中毒者のための解決策
UTIは、システム内のあらゆる場所でデータを定義するための標準化された方法を提供します。これは、特定のファイルタイプを作成する単一のアプリという、Type/Creator Codeの限定的な概念を超越するものです。Snow LeopardがCreator Codeをサポートしていないと不満を言う開発者は、数年前から導入されているUTIをブラッシュアップする必要があります。UTIはCreator Codeのすべての利点を提供しながら、その他多くの最新の新機能も実現します。
ファイルを作成したアプリで自動的に開けなくなったことを懐かしむユーザーは、アプリ開発者にUTIへの対応を急ぐよう強く求めるでしょう。2005年のTiger以降にアップデートされたにもかかわらず、UTIをまだサポートしていないアプリケーションは、Macプラットフォームの重要な機能をサポートしないことを選択したことになります。
システムが、特定のファイル タイプ用に定義したアプリではなく、特定のアプリを使用してファイルを起動する理由を理解していなかった多くのユーザーを含むその他のユーザーは、引き続き Finder の [プログラムから開く] メニューを使用したり、アプリの起動をドラッグ アンド ドロップしたり、[情報を見る] パネルを使用して、選択したドキュメントを開くための項目ごとに永続的なデフォルトの「作成者」アプリを設定したりできます。
Daniel Eran Dilger 氏は、Wiley の新刊『Snow Leopard Server (Developer Reference)』の著者です。現在、Amazon で特別価格で予約注文できます。
