Mac OSX 文件系统总结

OS X采用的是类UNIX的多用户系统。
通常我们在启动盘下面都只能看到应用程序、资源库、系统、用户这4个目录。但其实还有很多的隐藏目录,如bin、sbin之类的,这些都是系统的一些资源,一般是不用普通用户去访问,是些比较重要的系统文件及配置文件。
所以我这里就只是探讨一下通常在Finder中可以触及的文件项目和资源。
首先我们来了解一下OS X系统的几大组成部分:
文件系统区域:
作为了一个多用户的操作系统,控制系统资源的访问对于保证系统的稳定性是非常重要的。通过目录的设置,由当前用户的操作权限来决定该用户对每部分资源的访问。
在OS X系统中,存在以下4个文件系统区域:
User:这个区域包含了登录到系统的用户可供使用的特定资源。该区域由用户的主目录来定义,在这个区域中,用户具有完全的控制权限。
Local: Local区域包括如文件、程序这些被系统中所有用户共享的资源,但它不是系统运行所必须的。Local区域没有一个相应的单独的目录,它包含于启动卷宗的多个目录中。具有系统管理员权限的用户可以添加、删除或修改此区载的项目。
Network:此区域包含了本地局域网中可被所有用户共享的资源,如文件或应用程序。该区域的代表项目在网络文件服务中的位置,并受网络管理员的控制。
System:包含由Apple安装的系统软件。这此资源是系统正常运行所必须的,位于启动卷宗中,在该区域中,用户不允许添加、删除或更改这些资源。
用户区域包含指定给一个单独的用户的资源。由当前用户的个人目录来表示。每个Mac OS X系统用户必须有一个账号,在文件系统中给每个用户账号指定一个目录空间。目录中包括了用户的应用程序、资源以及文档。用户个人目录以用户账号的短名称来命名,并且是唯一的。
用户区域可以让用户为自己定义一个合理的工作环境,当用户登录时,Finder将恢复用户的工作环境,并按预置设置为用户上次使用时的状态。同样的,应用程序及其它系统软件按程序预置、网络设置、email设置、字体设置及其它设置来进行恢复。
用户的个人目录的位置依赖于用户的账号。如果用户账号是本地账号,那么用户的个人目录则位于启动卷宗的”User”目录中,如果是一个网络账号,则个人目录位于网络服务器中。
无论用户的个人目录实际位置在哪里(实际上,我们还是可以通过终端命令更改个人目录的实际位置的),OS X都使用”~”字符来代表当前登录用户的个人目录。这个符号可以与其它路径来组合使用。
表一:
~ 当前用户目录的顶级目录,相当于”/User/当前用户名”这个目录
~/Library/Fonts 当前用户个人目录中的字体储存位置
~Steve 用户Steve的个人目录。
说明:这里我们需要注意的是,终端或系统中,我们其实都可以多重登录的,因此,在使用”~”的时候,连接的是“当前登录用户“的个人目录。所以,当你登录为不同的用户时,”~”所指的位置并不相当。
表二:
这里我们列出的是个人目录下一些常见的目录:
Applications 包含一些只有当前用户可以使用的程序,比如我们安装了一个程序,安装时选Applications,应用程序将会默认安装到这里!
Desktop:包含当前用户显示在Finder桌面上的所有项目。
Documents:用户个人的一些文档。经常会包含一些程序使用的文件或者下载的文件,以及程序安装的纪录文件。
Library:包括应用程序设置、预置及其它用户指定的系统资源或设置(具体内容将在下一章中进行说明)。
Movies:QuickTime或其它格式的影片
Music:数字音乐文件(如.aiff, .mp3, .m4p或其它格式),包括iTunes自动倒入的歌曲。
Pictures:图片文件,包括iPhoto自动导入的数码相机中的图片
Public:你可以把需要与其它用户共享的文件放在这个目录中,默认状态下,这个目录可以被其它所有用户访问。
Sites:用户的个人站点网页文件。在被其它用户访问之前,你必须在“系统预置-共享-Web共享“中打开共享。
当新建账号时,”Applications”目录并不会自动添加到该用户的个人目录中。用户可以自已手工建议一个”Applications”,并把自己的程序放在该目录中,系统会自动搜索该目录中的项目。
在’/User’目录中包含一个叫”Shared”的子目录,这个目录可以被本地的所有用户访问(不过请不要把应用程序放置在该目录中),所有用户都可以从该目录中读取或写入文件,用于本地用户的文件交换及共享。
本地区域包括本地计算机所使用的资源,但它不是系统运行所必须的。比较典型的包括:应用程序、实用工具、自定义字体、自定义的启动项目以及应用程序全局设置。在”Applications” 以及 “Library”目录中也包含了部分资源,这些资源仅代本地用户使用,而网络用户则无法访问。
如果希望本地所有用户共享资源,那么系统管理员可以安装资源到本地区域,苹果公司开发的应用程序都安装在”/Applications” 及 “/Applications/Utilities “目录中,第三方的程序及工具也可以安装在这些目录中。其它的系统资源,如字体、预置以及插件放置在”/Library”相应的子目录中。
网络部分
网络区域包括本地局域网中的的资源。网络用户可以访问程序、文档以及其它资源,包括AplleShare及 Web共享。
表三:
/Network/Applications 包括可以被本地局域网中其它用户运行的一些应用程序。
/Network/Library 包含如:插件,音频文件, 文档, 框架, 色彩,及字体这些供本地局域网用户使用的资源.
/Network/Servers 包含本地局域网中提供的NFS文件服务的连接
/Network/Users/ 包括所有本地网用户的个人目录。这是个人目录默认的位置。个人目录也可以存储在其它服务器中。
系统区域
系统区域包括了Mac OS X运行所必须的资源,它全部位置于启动盘的”/System”目录中。这些资源由苹果公司提供并只有’root’用户可以修改其内容。管理员用户以及程序将不会安装任何资源在这个目录或直接修改其内容。
默认时,”/System”仅包括一个”Library”子目录,这个子目录包含了许多与其它Library目录相同类型的资源。
请不要手工添加、删除或者修改此目录的资源,否则有可能导致系统无法正常启动。
Library目录
Library目录被用来存储程序及系统特殊资源的一个特殊目录。每个文件系统都有它自己的Library目录。通常,程序可以用它来存储内部数据或临时文件,但不会存储程序本身或用户的数据文件。
它包括很多标准的子目录,系统通常会认为已经存在这些标准的。所以请不要删除Library中的子目录。当然,程序也可以创建新的子目录来储存程序的特殊数据。
Library可以位于启动盘根目录及用户的个人目录中。虽然位置不同,内容及作用大体相同。
唯一的区别就在于:根目录下的Library是本机所有用户的共同设置,而个人目录中的Library则只是该用户的设置。
下面我们将列出在Library常见的一些子目录,你可以通过这个说明来了解这些目录到底有何用途。从而来决定你要作什么。
Library目录中的子目录:
Application Support :包括程序的特殊数据以及支持文件,如第三方插件,帮助程序、模板以及被程序使用但不允许操作的附加资源。通常所有的项目都放置在以程序命名的目录中。例如Adobe公司的程序,都将放在名叫“Adobe“的子目录中,而苹果公司的程序支持则放置在“Apple“这个子目录中。
Assistants:包括程序用来帮助用户设置或完成其它任务的资源。
Audio:包括音频插件及设备驱动。
Caches:再生所必须的缓存数据。
ColorPickers:采集色彩时所依赖的模式的资源。例如HLS或RGB。
ColorSync:色彩管理预置及脚本。
Components:系统组织和功能扩展。
Contextual Menu Items:附加的系统级关联菜单插件,如阿拉丁的解压缩关联菜单、iGetter的关联菜单。
Desktop Pictures:桌面图片目录。
Documentation:文档及用户和管理员使用的苹果帮助文件包(也有的在”Help子目录中”)。
Extensions:包括设备驱动及其它核心功能。类似于OS 9下的”功能扩展”目录。
Favorites:包括经常访问的目录、文件或网站的替身,仅存在于个人目录的库目录中。
Fonts:显示和打印用的字体文件
Frameworks:框架和共享的资源库,开发者可能会安装自己的框架或资源在该目录中。
Image Capture:通常是扫描仪的驱动。
InputManagers:输入法管理,
Internet Plug-ins:网络浏览器使用的插件、库及过滤器。如Flash插件、Realplayer插件。
iTunes:第三方的iTunes的插件及库,
Java:如果你安装了Java,那么就会有这个目录,包括了Java的一些功能扩展及其它资源。
Keyboard Layouts:键盘布局
Keychains:系统中各个钥匙串的内容。
Logs:控制台及系统服务的记录文件,你可以通过:应用程序-实用程序-控制台来查看。
Modem Scripts:调制解调器脚本,也就是猫的驱动了。
Mail:用户的电子邮件内容,这只存在于每个用户的个人目录的库目录中。
Perl:Perl程序的功能扩展及库,比如Cocoa Conler就需要这个功能。
Plug-ins:系统插件,比如磁盘工具的磁盘映像。
PreferencePanes:系统预置插件,一般显示在系统预置的最下方。如安装阿拉丁解压缩软件时生成的StuffIt AVR.prefPane
Preferences:预置目录,包括系统、应用程序及用户的各种设置。通常如果预置文件损坏,会导致程序或系统的操作失常,这个时候可以通过删除相应的预置来尝试解决问题。
Printers:打印机驱动。PPD插件,以及配置打印机所需要的库文件。
QuickTime:QuickTime的插件及功能扩展。
Receipts:安装过的.pkg安装包的替身,但不是.pkg安装包本身。例如系统升级或安装时的.pkg。或vpc安装时的.pkg包。
Screen Savers:屏幕保护文件。
Scripting:AppleScript附加的脚本及脚本资源。
Sherlock Plug-ins:Sherlock兼容的插件及功能扩展。
Sounds:系统警告提示音
StartupItems:系统运行时自动启动的系统及第三方脚本或程序。一般通过系统预置-账号来进行设定。
User Pictures:用户账号中,用户显示的图片的文件。
WebServer:Web服务内容。也就是个人Web共享的内容。包括CGI脚本及网页文件。网页文件放置在Documents子目录中。
文件系统
从体系结构上看,Mac OS X实现了对多文件系统的支持,其中最为重要的文件系统包括有:Mac OS Extended (HFS+),Mac OS Standard (HFS),UFS, ISO 9660, NFS和 AFP。但从用户的角度看,文件系统又是单一的。当用户复制,移动或拖移文件和文件夹时,(会感觉似乎)只存在一个文件系统。
文件系统如何被组织
Mac OS X文件系统中的几乎每个文件都有其适合放置的存储这一类型文件的标准目录区域。而对用户来说,这并不意味着他们就必须把应用程序和应用程序资源放在被推荐的区域。由于应用程序最终会被打包,因此无论他们被安装在哪里,都能满足自身要求。但假如用户没有把某些内容放在系统软件期望的位置。他们有可能会丧失Mac OS X的一些优势。例如,Finder首先通过搜索应用程序的标准位置来导入应用程序数据库(见“收集应用程序信息”一节)。一旦这样做,结果有可能会造成一个隶属于某个应用程序(但不在那一区域)的文档,不能在双击时被立即打开。
文件系统的层次通常被表现为一个以“根(root)”开始的分层结构,在典型的Mac OS X文件系统的根目录中(“根”用起始的“/”符号来表示),它包含以下项目:
/Mac OS X/–一个特殊的卷,操作系统由它开始启动,系统文件和资源也被安装在其上。这个卷通常是一个被格式为Mac OS扩展格式(HFS+,Mac OS Extended)的卷(虽然它也可以是UFS卷)。名称“Mac OS X”是它默认的卷名,但用户也可以修改它。
/Network/–作为装载到用户系统上的本地网络的根目录。无论用户是否连接到网络上,/Network/目录(其图标是一个“地球”)将始终出现。
/OtherVolumes/–显示一个或多个被连接的外部设备或不是启动卷的内部设备。其中可以包括有Zip驱动器,CD-ROM驱动器,数码相机,被装载的网络服务器以及硬盘和它们的分区等。(“OtherVolumes”只是一个真实名称的代表,被连接的卷的实际名称将会是不同的)。
所有非启动卷在它们被装载时出现,被卸载时消失。对此有一个例外,用户的iDisk卷即使在被卸载后也不会消失。
卷的物理结构与Finder向用户所显示的略有不同。假如用Terminal程序看一下目录结构,您会看到启动卷被装载在根目录层(/),而非启动卷被放在/Volumes/目录中。Finder提供了这种抽象方式,用来在基本的UNIX 系统上提供一个更加传统的Mac OS界面。
像/usr, /bin和/etc等目录都是标准的BSD目录,它们也存在于根目录层,但Finder向用户隐藏了它们。
系统域
系统域包含了要求由Mac OS X来运行的资源。系统域中的所有资源被放置在启动卷上的/System目录下。这些资源由Apple提供,只有root用户可以修改这个目录的内容。管理用户和应用程序不能在系统域中安装资源或是直接修改它的内容。
默认情况下,/System目录仅包含了一个Library子目录。与系统中的其他Library目录一样,这个子目录中包含了许多相同类型的资源。然而在系统域中,这个目录还包含了构成Mac OS X系统的许多核心服务,框架和应用户程序。关于Library目录的更多信息,请参见“Library 目录”一节。
——————————————————————
Library目录
Library是一个特殊的目录,用于存储特定的应用程序和特定的系统资源。每个文件系统域都有其自身Library目录的副本,这些Library目录具有不同的访问级别以匹配不同的域类型。虽然一个应用程序可以使用这个目录来存储内部数据或临时文件,但将应用程序的束自身或是用户数据文件存放在Library目录中将是不足取的。应用程序的束应放在一个/Applications目录中,而用户数据应放在用户的home目录中。
Library包含了许多标准的子目录。系统例程要求许多标准子目录必须存在,因此删除Library的子目录决不是一个好主意。然而,当需要存储特定的应用程序数据时,应用程序可以创建一个新的子目录。
Application Support
特定应用程序的第三方插件,帮助程序,模板和其他资源。按规定,这些项目应被放置在以应用程序命名的子目录中。举个列子,应用程序MyApp的第三方资源将被放在Application Support/MyApp/中。注意,一个由应用程序开发者创建的资源应被放置在自己的应用程序包中。更多信息请参见“应用程序包”一章节。
Assistants
帮助用户完成配置和其它任务的程序。
Audio
声音插件和设备驱动。
ColorPickers
根据某一模式取色的资源,例如HLS (Hue Angle, Saturation, Lightness) 取色器或RGB 取色器。
ColorSync
ColorSync描述和脚本
Components
系统中的插件和扩展。
document.tion
文档文件和Apple 的帮助包(在子目录Help中),计算机上的用户和管理员可以使用它们。在本地域中,这个目录包含了Apple安装的帮助包(包括开发者文档)。
Extensions
设备驱动和其他内部扩展(仅为系统域)。
Favorites
时常被访问的文件夹,文件或Web站点的替身(仅为用户域)。
Fonts
用于显示和打印的字体文件。
Frameworks
框架和共享库。
Internet
用于Internet的插件,库和过滤器。
Keyboards
键盘定义。
Mail
包含了用户的邮箱(仅为用户域)。
Preferences
用户预置,请参见“系统预置”一章中的“用户配置”一节。
Printers
打印驱动(由厂商提供)和PPD插件。
QuickTime
QuickTime的插件和扩展。
Scripting Additions
扩充了AppleScript功能的脚本及脚本资源。
Sherlock Plug-ins
扩充了Sherlock功能的插件。
Sounds
系统警告声。
StartupItems
在启动时运行的系统及第三方的脚本和程序,更多信息请参见“引导和登入”一章中“启动项目”一节。
Web Server
Web 服务器的内容,这个目录包含了CGI脚本以及所备置的Web页面。
——————————————————————
Developer目录
用于开发Mac OS X软件的应用程序,工具,文档及其他资源是一个可选的软件安装包。当您安装开发工具时,安装程序会把所有软件组件放到位于启动卷(/Mac OS X)的Developer目录中。
Applications
用户管理和建立软件项目(Project Builder),创建用户界面(Interface Builder)和执行调试程序的应用程序。
document.tion
开发者文档
Examples
分类组织的项目实例(Carbon,Java等等)。
Headers
特殊的头文件,诸如:遗留的简单 Carbon头文件。
Java
在Cocoa应用程序环境中用于Java桥接所需的文件。
Makefiles
用于建立和改变项目所需的makefile(.make文件)和jamfile(.jam文件)。
Palettes
Apple 提供的Interface Builder的调色板。
PBBundles
Project Builder使用的可装载的束。
ProjectBuilder Extras
Project Builder的模板和插件。
ProjectTypes
Project Builder使用的项目类型的定义
Tools
命令行开发工具,包括那些创建和生成HFS资源分支的工具。
Project Builder定义了一组makefile变量,当您的项目在文件系统域中指定位置时,应该会使用到它们。您应该使用这些变量而不是将目录路径硬编码,因为这些位置可能会被改变。
——————————————————————
Classic环境的目录
Classic环境包含了几个用于支持Classic应用程序的目录。这些Classic环境下的目录是一个Mac OS 9安装版本中的目录。Mac OS X 需要为Classic环境安装一个 Mac OS 9.1(或更新的版本)。如果一个系统安装了一个比Mac OS 9更早的版本,用户必须安装一个更新的版本来支持Mac OS X。
一个系统可能有多个Mac OS 9版本安装在不同的分区上。如果是这种情况,系统预置的Classic设置面板将让用户为Classic环境选择使用其中的一个Mac OS 9版本。用户第一次启动Classic时,系统会将一些必要的文件附加到被选取的Mac OS 9卷的系统文件夹内。您也可以使用系统预置中的Classic设置面板随时启动或停止Classic运行环境。用户还可以使用“启动磁盘(Startup Disk)”系统预置来改变启动磁盘,以从Mac OS X变为直接启动进入Mac OS 9。
当您在一个卷上安装了Mac OS 9.1(或更新的版本)时,安装程序会创建几个目录来存储系统文件。表9-6列出了安装程序创建的目录以及关于其内容的描述。如果您已经安装了一个Mac OS X 和 Mac OS 9.1(或更新)的本版,Mac OS 9 的安装程序可能不会创建所有这些目录。
Applications (Mac OS 9)
包含了Mac OS 9(Classic)的应用程序和实用工具。
document.
包含了特定应用程序的信息。这个目录只能由Classic应用程序使用。Mac OS X应用程序会在适当的/Library目录中存储预置和其他应用程序文件。用户应该把他们的文档存放在他们自己的home目录当中。
System Folder
包含了Classic环境的系统文件。
当您在一个已经装有Mac OS 9的系统上安装Mac OS X时,安装程序会执行一些额外的任务来支持Classic环境。尤其Mac OS X安装程序会创建一个Mac OS 9桌面文件夹的替身,并把它放在可以运行安装程序的管理员用户的桌面上。这个替身包含了在Mac OS X 安装之前Mac OS 9桌面上任何文件的链接。
本地化目录名
如果您的应用程序包安装了任何用户支持的目录,那么您不但可以为应用程序提供本地化名称,而且也可以为这些目录提供本地化名称。本地化您特定的应用程序目录名是不必要的,而且可能并不是所有情况下都是有效的。如果您想本地化您的应用程序支持的目录,您应该仅为那些您应用程序预先知晓其名称的目录进行本地化。不建议本地化“用户特定”的目录名。
要本地化目录名,您必须为目录名加上.localized扩展并将其默认设置为隐藏。然后在您的目录中再创建一个名为.localized的子目录。在这个子目录中,为您想支持的每个本地化版本创建一个strings文件。strings文件包含了目录名的本地化版本的单一入口。举个例子,一个用English,,Japanese和 German本地化的Release Notes目录将包含以下结构
Release Notes.localized/
.localized/
en.strings
de.strings
ja.strings
在每个strings文件当中,您要把非本地化目录名转变成本地化目录名。举个例子,要转换目录名“Release Notes”成为一个本地化目录名,每个strings文件都要包含类似以下的条目。
“Release Notes” = ”Localized name”
注意:许多系统定义的目录在他们的名称里并不包含.localized扩展名。因为这些目录在引入本地化文件系统名之前已经存在。对于这些已知的目录,Mac OS X转而在目录中查找名为.localized的空文件。如果此文件存在,那Mac OS X就会显示其本地化目录名文本。
——————————————————————
HFS+ 和 UFS的不同点
在Mac OS X的两种主要文件系统:HFS+和UFS上,有着许多重要的不同点。在许多情况下,这些不同会与在Mac OS X上开发的程序有关联。以下列表总结了在这两个文件系统中的主要不同点(有些陈述既适用于HFS又适用于HFS+):
大小写敏感:UFS对大小写是敏感的,而HFS+对大小写不敏感,但它可以保留大小写。
多分支:HFS+支持多分支(和附加的元数据)而UFS只支持单一分支(Carbon在不支持多分支的系统“如:UFS”上模似多分支结构)。
路径分隔符:HFS+使用冒号作为路径分隔符,而UFS中使用的则是正斜杠。系统能够在这些分隔符间进行转换。
修改日期:HFS+支持对文件的创建和修改日期的记录,它们将作为文件元数据被保存;而UFS只支持对文件修改日期的记录,不支持对文件创建日期的记录。如果您用一条命令来复制一个文件,这条命令将会处理修改日期,但不会处理创建日期,当它为一个副本创建一个新的文件时,这条命令将会重设其修改日期。由于这一原因,很可能会使一个文件的创建日期要比其修改日期更晚。
Sparse文件和零填充:UFS支持sparse文件(稀疏文件),它是一种文件系统存储文件数据的方法,其不存储分配给文件的未被使用的空间。HFS+不支持sparse文件,事实上可以用”零”为文件填充所有未使用的字节直到文件结束。
对文件系统项目的轻量级引用:请见“替身和符号连接”一节。
另外,那些已往与每种文件系统相关联的API有时会具有不同的特性。举个例子,一个使用了BSD (或来源于BSD)API的程序可以删除一个打开着的文件;而另一方面,一个Carbon程序只可以删除一个已关闭的文件。
——————————————————————
替身和符号连接
替身和符号连接是对文件夹和目录的轻量级引用。替身与Mac OS标准格式(HFS)和Mac OS 扩展格式(HFS+)相关联,而符号连接是UFS文件系统的一个特征。替身和符号连接都允许对文件夹和目录多次引用,而不需要为这些项目建立多份副本。Mac OS X 10.2之前,当移动或改变一个被引用的文件或文件夹时,替身和符号连接在处理方式上会有很大不同。
原先,替身首先用文件夹和目录的唯一标识来定位他们,其次才是用他们的路径。如果您在同一个卷上移动一个文件,任何指向那个文件的替身仍会指向原本那个位置。假如您删除某个文件,并用一个同名的文件代替它,替身仍可以工作,因为他们可以用路径来定位文件。而从Mac OS X 10.2起,替身颠倒了其搜索顺序,先使用路径后使用文件标识。
因为替身和符号连接都使用一个文件系统路径来断定文件位置,因此他们都提供了类似的基本工作方式。如果您用一个同名文件替换某个文件,把旧文件移到新的位置上,替身和符号连接都将指向新的文件。然而,如果您移动某个文件而不是替换它,符号连接会产生文件中断,但替身则不会。
在HFS 和HFS+文件系统中,每个文件和目录都会具有一个唯一的固定标识。替身存储了这个唯一标识以及文件或目录的路径信息。如果不能通过替身中的路径信息来找到文件,替身则会试图使用其唯一标识来定位文件。如果找到了文件,替身会用新的路径信息更新其内部记录。同样,如果路径正确,而唯一标识有错误,替身也会用新文件唯一标识来更新其内部记录。
如今Finder和其他系统应用程序用先查找路径的方式来使用替身。然而,通过使用Alias Manager(替身管理器)的方法来处置替身时,将仍会使用先根据文件唯一标识来查找的方式。
如果您的应用程序支持Mac OS X 10.2以前的Mac OS X 版本,则当您修改文件时应该遵守某些准则。首先,当需要编辑文件时,可修改已有的文件。其次,如果您明显需要用一个新版本来替换某个文件,可用FSExchangeObjects来将旧的文件替换成新的。NSdocument.用一种类似的方法来更新文档文件。因此,无论何时替身都能保持有效。
——————————————————————
下图对照早期的Mac OS系统描述了Mac OS X中资源是如何存储的。
虽然Apple支持“在同一文件中存储所有资源(all-resources-in-one-file)”的模式,但强烈建议开发者将他们的资源存放在各自的独立文件中。基于此的一种考虑是为了结合XML的使用来作为来指示资源的一种方式。Carbon具有基于XML的运行时工具,Interface Builder可以使用XML来输出用户界面。
如同应用程序一样,Mac OS X上的文档也可将其资源存放在数据分支中。其原因与应用程序把资源存放在数据分支中的原因是相同的。它使得在Macintosh系统与非Macintosh系统(包括大部分的Web服务器)间交换文档,而不丢失资源数据成为可能。
存放在HFS 和HFS+文件系统中的文件在独立于资源分支和数据分支以外的一个私有分支中存储了Finder属性。这些属性包含了类型代码和创建者代码。Mac OS X保留了这些属性,因为这些属性能使Finder增强用户体验。然而同时,Apple强烈鼓励开发人员选择使用文件扩展名作为识别文件类型的方法。Mac OS X在识别和处理文档扩展名方面做的非常好。正如在“Finder”一章的“复制和移动操作”一节中所描述那样,如果您复制一个HFS 或HFS+文档到不同平台(包括Web服务器)中时,文件扩展名将有助于保证文档的类型信息。
文件编码和字体
虽然Unicode被认为是Mac OS X的基本编码,但并没有一种文件编码对所有情况都是默认的。使用(或应该使用)何种文件编码,取决于您在所使用的API和底层文件系统上具体想要做什么。
举个列子,用于文件名的编码在不同的文件系统中是不一样的。Mac OS 扩展格式文件系统(HFS+)使用一种Unicode的特殊形式为文件名编码,即在UTF-16格式(16位编码序列)中被规范出的Unicode 2.1版本。UFS文件系统使用一种不同的Unicode格式来编码文件名。它包含了Unicode2.1或更新版本中的任何字符,但使用的是UTF-8格式(8位编码序列)。Mac OS标准格式(HFS)使用传统的Mac编码,诸如MacRoman。注意,由于实现方式不同,在HFS+卷上文件名中不正确的Unicode编码有可能会在Mac OS 9系统上正常显示,但通常在Mac OS X上又显示成混淆的字符。
而且,所有调用BSD系统例程的代码都应保证这些例程的const *char参数是以UTF-8编码的。所有BSD系统函数期望其字符串参数以UTF-8编码,而不能是其他的编码。另外要告诫的是文件,路径和其他文件系统实体在作为字符串参数时必须要以规范的UTF-8编码。在规范的UTF-8 Unicode的字符串参数中,所有可分解的字符会被分解;举个例子,é (0x00E9)被表示为e (0×0065) + ′ (0×0301)。在使用在Cocoa和 Carbon (包括Core Foundation)中定义的”文件系统表示”API时,要以规范的UTF-8编码。举个例子,在Cocoa中得到一个规范的UTF-8字符串,要使用NSString的fileSystemRepresentation方法;而对非正规的UTF-8字符串,使用NSString的UTF8String方法。
如果您使用常规的QuickDraw并想绘制文本,您应注意一些潜在的问题。Carbon文件管理器会产生一些返回Mac编码的调用和其他一些返回Unicode的调用。如果您有一个Unicode文本,您在用QuickDraw Text对其绘制时会有一些问题,因为其API不直接支持Unicode。另一方面,如果您得到一个Mac编码的文本并想使用Unicode Imaging (ATSUI) API中Cocoa 和 Carbon的Apple Type Services,您必须首先将其转换成Unicode。
通常,所使用的编码取决于您使用的API而不是字体。字体并不必须限制于特定的编码。举个例子TrueType字体声明了一组字型,他们实现并提供了在特定编码中映射那些字型为字符值的编码表。PostScript字体有类似的编码列表。操作系统的各个部分知道如何映射字符从一种编码到另一种编码。Cocoa 和ATSUI使用Unicode作为一种字体的“目的”映射。Carbon 中的QuickDraw Text使用Mac编码,它是根据字体的’FOND’资源相对应的语系来选择的。
安装在Mac OS X上的字体拥有大量的字符组,它们支持广泛的编码和语系。举个例子,系统字体Lucida支持扩展的拉丁语(Latin), 希腊语(Greek), 斯拉夫语(Cyrillic), 阿拉伯语(Arabic), 希伯来语(Hebrew)和泰国语(Thai)。但如果您通过QuickDraw Text来绘制文本,那您只能访问MacRoman字符表。要访问其余的部分,则您必须使用Cocoa或 ATSUI。同样日语中的Hiragino字体也有一个巨大的字符表,它超越了MacJapanese所支持的范围,它们只有通过Cocoa 或ATSUI才可以访问到。当被请求的其他字体中的字型不可用时,Cocoa 和 ATSUI会将其替代;然而,他们替代字体的算法是不同的。

此条目发表在mac/iphone/ipad/android分类目录,贴了标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据