Finder是Mac OS X的主程序。 从您登入系统的那一刻起就开始运行，它协同系统软件来跟踪和管理Dock，文件系统（包括已装载的网络卷），以及所联接的设备。通过Finder视窗，用户可直观的操作文件系统中的目录，应用程序及文档等内容。
本章并不讨论Finder用户界面组成细节，而着重讲述了Finder那些对Mac OS X 软件开发者有意义的方面。这些内容包括如下：
- Finder的应用程序接口
- Finder维护的信息存储
- Finder如何处理应用程序和文档
- Finder如何在不同格式的卷之间进行文件操作
- Finder如何在用户双击文档时判定启动哪个应用程序
- Finder如何处理文件排序
一般来说，Mac OS X 中Finder的本质及扮演角色与Mac OS 9 中非常相似，它是一个程序，更确切的说，是一个Carbon程序，它管理着用户桌面，作为用户访问文件系统中应用程序，文档及其它项目的媒介。用户通过Finder界面运行程序以及打开文档。在某种意义上说，它是用户登入系统时就一直运行的主程序。
然而，在Mac OS X 中其又有几个显著的特征：
- Aqua人性化用户界面：此界面不仅影响了桌面组件的外观，同时也影响了其使用上的逻辑性与结构。举个例子，Finder视窗的Dock和控件引入了Mac OS 9中未曾出现的操作模式。
- 多用户：当然，Mac OS 9也支持多用户系统（通过多用户控制面板实现），但它只是可选的，而在Mac OS X系统中多用户是默认标准。必须以用户的身份登入系统（即使他们要求自动登入系统），一旦登入后，用户便可以在根据自身情况定制的环境中工作了。
- 多元应用程序环境：然而，在这方面的差别不是很明显，如果将Java纳入考虑，Mac OS 9也是（或者说可以算是）拥有多元应用程序环境。但Mac OS X 的层度更深，其必须处理Carbon，Cocoa，Java，Classic 等应用程序环境及在某些情况下的BSD命令程序环境。
- 多卷格式：Mac OS X支持多种卷格式。包括多分支格式（如： HFS+）和平文件格式（如：UFS）。它试图尽可能在不同格式卷之间对文件系统进行一致的操作。更多相关信息请参见“Finder及文件操作”一节。
Finder努力使用户在所有应用程序环境中的体验尽可能的保持一致。然而，在Classic 环境中还有点小问题，Classic 程序只能在HFS或HFS+格式的卷上运行。而其他环境的应用程序可以不用考虑卷的格式问题，同样Classic 程序也不能在任何非HFS或HFS+格式下打开或保存文件。关于Classic 环境更多信息，请参阅“Classic环境与您的程序”一节。
目前，Finder提供了信息属性列表作为程序的一个接口，通过这个接口，应用程序可以向Finder传送必要的数据信息。
Finder同时也定义了一组“Apple事件”，应用程序可以用其完成大量任务，包括打开文档及启动应用程序。
应用程序可以向Finder发送Apple事件来完成若干操作，这些操作包括：
- 启动其他应用程序
- 打开URL
- 打开文档
Cocoa 为在Finder与应用程序间传递Apple事件提供了一个面向对象机制。您可以发消息给NSWorkspace类所分配的一个实例（每个程序都有一个实例），这个实例用来处理发送给Finder的Apple事件的合成与发送，当Finder将Apple事件发送给Cocoa 程序时，应用程序包会将其转换成消息传给应用程序实例对象。
当您为Mac OS X 开发某个应用程序或任何其他束时，您必须为束的信息属性列表写明若干键值对（key-value pairs），作为工程项目的一个部分。这个属性列表保存在一个名为Info.plist的文件中。当应用程序被创建时，它被打包进束，并作为其的一个部分。信息属性列表包含以下可由Finder识别的特性信息：
- 应用程序名称（由Finder来显示）
- 类型代码与创建者代码（应用程序类型代码为“APPL”）
- 图标名称
- 版本字符串
- 描述信息（由Finder来显示）
- 此应用程序所处理的文档，包括：文档名，图标，角色（role），类型及扩展名
- 此应用程序所处理的URL，包括URL名称，图标及协议
属性列表传递信息在使用上比其他接口更为被动。开发人员只需要向Finder提供这些信息，当Finder检测到一个应用程序时，会将信息从Info.plist中解读出来并将其存入自己的数据库中（请参见“Finder的存储信息”一节）
关于属性列表更多信息及Finder特性的关键字，请参见“软件配置”一章中的“信息属性列表”一节。相关信息请参见“束”和“应用程序打包”等章节。
Finder维护着大量的（私有的）某种特定数据库，这些数据库为Finder提供了一个用于描述桌面、应用程序、文档及其他项目的综合（但不是完全完整的）视图，它们是用户体验的一部分。这节描述了Finder如何改写这种数据库，并介绍了驻留在数据库中的信息。同时也描述了对Finder有特殊重要意义的文件属性。
在Mac OS X中Finder存储文件系统信息的方法与Mac OS 9的方法有所不同。Mac OS 9中，Finder将加载到系统上的每个卷分别与一个桌面数据库关联起来。每个数据库包含了这个卷上所有文件和目录的信息。当系统启动时，Finder就会创建这些数据库，此后，当文件或目录增加，修改或删除时，Finder会动态的更新它们。
在Mac OS X中的情形有所不同，由于Mac OS X 多用户的特性，Finder为每个用户维护着一个应用程序数据库，这些用户在系统上都拥有一个（本地或网络）帐号。这个数据库为其用户存储了Finder检测到的所有应用程序信息，包括每个应用程序识别的文档类型信息。Finder协同"启动服务"来解读应用程序信息属性列表。（关于这一内容概要，请参见“信息属性列表”一节）
Mac OS X 创建数据库的方法也与Mac OS 9有所不同：
- Finder在启动时首先通过检测应用程序在“用户”，“本地”（加上“系统”）及“网络”域中的标准位置来将其加入到数据库中。
- 当用户浏览文件系统时，Finder会将其访问过的每个目录中的应用程序加入到数据库中去。
- 当用户试图打开一个文档或是其他任何操作，需要一个应用程序，而Finder又无法找到一个合适的应用程序时，就会显示一个对话框，允许用户自己选择一个应用程序。这个应用程序也会被加入到用户应用程序数据库中。
由于文件系统中某些地方用户从未访问过，或是有某类型文档用户从未打开过，Finder或许只掌握了一个不完整的用于描述系统中可用应用程序的视图。它具备了一种内置的能力，用于“懒惰地”更新文件系统的描述视图。
Mac OS 9系统和Mac OS X系统中Finder都将用户桌面内容放在一个文件夹中。这个文件夹在两个操作系统中的位置及“桌面”的含义如下：
- 在Mac OS 9系统中，每个卷的根目录下有一个名为“Desktop Folder”的隐藏目录;在Mac OS X系统中，在每个用户的个人（home）目录下有一个可见的名为“Desktop”的目录（~/Desktop/）。
- 在Mac OS 9 中，桌面上显示的是所有卷中“Desktop Folder”目录的集合;而在Mac OS X 中，桌面所显示的是所登录用户个人目录中“Desktop”目录的内容。
Finder属性（也称作“Finder信息”）与Mac OS X 文件系统中的文件和目录相联系。这些属性影响Finder如何显示和处理这些文件及目录。Finder在Mac OS X中所能识别的这种属性要比在Mac OS 9中少，Mac OS X 所支持的属性如下：
- 束位（bundle bit），用于确定文件夹是否是一个束
- 隐藏位（invisible bit），用于确定文件是否隐藏
- 类型代码（type code）和创建者代码（creator code）
- 用户定制图标
不支持的类型如下：
- 图标位置
- 视图类型
- 标签
在Mac OS X 系统中，Finder将属性存放在每个文件夹中的一个隐藏文件里，它包含了一个数据结构，这个数据结构是可扩展的且与卷的格式无关。
在Mac OS X中，Finder是应用程序及文档的主要接口。以下章节描述了Finder用来显示文档及响应用户与这些文档交互的技术。
如同在“Finder存储的信息”一节描述的，Finder从文件系统中的应用程序收集信息再将这些信息写入若干数据库中。当Finder检测到某个文件或文件夹时，通常根据这些信息决定如何显示文件和文件夹及如何处理用户与其交互。
Finder用一组束位，类型代码，创建者代码及文件扩展名信息来识别并适当地处理这些文档、应用程序及可装载的束。以下步骤列出了Finder遇到文件系统中某个项目时的一般逻辑判断：
1.判定是文件还是文件夹
如果是文件夹，Finder就会判定是否是束（步骤2）;如果是文件，判定是何种类型的文件（步骤4）。
2.判定这个文件夹是束还是普通文件夹。
Finder根据束位或是文件夹扩展名来判定文件夹是否是一个束。 束位并不是必须要的，事实上，Apple提供的系统框架都并没有设置束位。
3.找出束的类型
Finder从存放在束中的信息里获得类型代码和创建者代码（请参见“束”中“束的结构”一节）。从类型代码（或没有提供类型代码时，从扩展名中）判定束的类型。除非这个束是一个框架，否则Finder都将其作为一个文件处理（换句话说，它是一个文件包）。
4.判定这个文件（包括步骤3的文件包）是否是个应用程序
如果这个文件是个束，而这个束又是一个应用程序（由类型代码或文件扩展名来决定），Finder将会隐藏其.app扩展名（如果存在这个扩展名）。Finder把应用程序信息属性列表中的信息加入到用户的应用程序数据库中（假如这些信息在数据库中不存在）；在“收集应用程序信息”一节中有其相关描述。如果文件不是应用程序，它便是文档（步骤5）。
5.适当地显示文档
Finder参照应用程序数据库并将文档图标紧挨着文件名显示，如果数据库中此类图标不存在，它便显示默认文档图标。
影响Finder向用户显示文件的两个额外特性是文件扩展名的隐藏和文件名的本地化。它们都只是修饰性的附加特性，用于使Aqua用户界面改变文件显示名称，但并不会改变文件系统中真实的文件名。Finder采用由“启动服务（Launch Services）”中提供的程序来为每个文件获得一个可显示的名称。有关隐藏文件扩展名的更多信息，请参见“隐藏文件扩展名”一节，而有关文件名本地化的更多信息请参见“本地化文件系统中的名称”一节。
Mac OS X为用户提供了许多使用Finder来排序和组织文档的方法。
在Mac OS 9中，用户可以通过文件名，文件大小及修改日期等来进行文件排序。然而，在文本字符串的排序方式上，Mac OS X有别于Mac OS 9。在Mac OS X中，排序是基于Unicode整理算法（UTS#10技术标准），它是由Unicode联盟定义的。这个标准为所有Unicode字符提供了一套完整清晰的排序指令，可以在Unicode联盟网站（http://www.unicode.org）获得它。
Mac OS X中的Finder利用一些获许可的方法改变了Unicode标准定义的默认排序方法。另外，Finder还支持以下排序规则：
- 标点符号对排序有作用
- 排序时，数字子字符串被作为数字值而非文字字符
- 大小写不影响排序
当用户双击或以其他方式打开文件系统中的文档时，Finder会检测文档的类型代码和创建者代码（如果是HFS或HFS+文件格式）或文档的文件扩展名，它用这些信息获得一个可以打开此类文档的应用程序的列表，然后用合适的应用程序将文档打开。以下列表说明了，Finder选择适当的应用程序所遵循的规则：
1.选择用户选定的应用程序打开文档。
2.选择用户选定的应用程序处理与这个文档类似的那些文档，指那些创建者代码，类型代码及文件扩展名相同的文档。
3.选择已被注册用于处理与其具有相同类型或扩展名的文档的默认应用程序。
4.选择与这类文档类型相关联的应用程序。
Finder 给予Mac OS X本机应用程序优先权高于Classic程序。同时也给予最新版本的应用程序和最近修改的应用程序以较高的优先权。
5.如果已经有一个拥有相同创建者代码的应用程序在运行，将选择那个应用程序来代替现有的程序。
6.如果Finder仍不能找到一个合适的应用程序，它会弹出一个对话框请用户选择一个适当的应用程序。
如果用户选择了一个应用程序，Finder会将其信息放入这个用户的应用程序数据库中以备将来引用。
一旦一个适合的应用程序被发现，Finder便开始启动这个程序并将其作为这个文档的一个引用。
对于大多数（但不是全部）发生在Mac OS X上的文件操作而言，Finder往往扮演着“传输管理者”的角色。除了用shell命令如cp 和 mv（一般不建议使用）、AppleScript或其他某些程序方式，您都必须用Finder来进行文件复制，移动，删除及制作替身。很明显，对于这些操作，也存在着一些与多卷格式相关的问题。本节讨论Finder如何跨越不同格式的卷来处理文件操作。
当Finder复制或移动一个文件时，针对起始卷和目标卷格式，Finder采用了的尽可能丰富的有效模式。最易受到这些操作影响的卷格式是HFS+（HFS）和 UFS。这些操作尤其影响了HFS和HFS+的资源分支和Finder属性，特别是类型代码及创建者代码。
如同有人可能预计那样，当Finder复制文件到一个HFS+（或HFS）卷上时，Finder将“原封不动地”保留HFS+文件的资源分支和Finder属性。然而，更有趣的是Finder复制HFS+文件到一个UFS卷上，当发生这种情况时，Finder分隔出并不在数据分支中的那些信息（特别是类型代码和创建者代码），并将这些信息写入同一目录位置下的一个隐藏文件来作为被复制的文件。这个隐藏文件拥有这个UFS文件相同的名称，只是在词首加了一个“._”前缀。因此，如果您有一个名为MyMug。jpeg的HFS+文件，当您将其复制到一个UFS卷上，在相同的位置将会有一个名为“._MyMug。jpeg”的文件。
当Finder复制一个UFS文件到一个 HFS 或HFS+的卷上时，它便要寻找隐藏的“._”文件。如果存在，它便会使用隐藏文件中用来重建文件资源分支和Finder属性的信息来创建一个HFS+（HFS）文件。如果隐藏文件不存在，所复制的文件将没有资源分支。
请注意Finder是通过它所基于的Carbon API来完成这些操作的。
注意：您可以在应用程序包（或其它任何束）上使用BSD 的cp或mv命令，而不会有任何负面影响。但，如果您在一个单一文件的 CFM应用程序上使用这些命令时，被复制（或移动）的应用程序将导致无法使用。为了后者这个目的，Apple包含了Apple命令行实用程序。
Mac OS 标准（HFS） 和Mac OS 扩展（HFS+）文件系统包含了被称为“替身”的文件系统实体，“替身”拥有与UFS文件系统中符号连接的一些相似之处，但其区别也很明显，关于这些区别的描述请参见“文件系统”一章中“替身与符号连接”一节。
Finder管理着一个能使“替身”和“符号连接”同时并存的文件系统，对于它的实现非常简单。Finder识别符号连接，但只创建替身（当被给予适当的菜单命令），甚至当它检测到文件系统中的一个符号连接时，它会将其显示为一个替身--也就是说，在这两者之间没有可见的区别。在Mac OS X中，产生符号连接的唯一方法是使用BSD命令ln -s。
[ 返回 ]