《iOS 6高级开发手册（第4版）》——2.1节秘诀：处理统一类型标识符

本节书摘来自异步社区《ios 6高级开发手册（第4版）》一书中的第2章，第2.1节秘诀：处理统一类型标识符，作者 【美】erica sadun，更多章节内容可以访问云栖社区“异步社区”公众号查看

2.1　秘诀：处理统一类型标识符

ios 6高级开发手册（第4版）

统一类型标识符（uniform type identifier，uti）代表ios信息共享的中心组件。可以把它们视作下一代mime类型。uti是标识资源类型（比如图像和文本）的字符串，它们指定哪些类型的信息将用于公共数据对象。它们不需要为此依赖于老式的指示符，比如文件扩展名、mime类型，或者文件类型的元数据（比如ostype）。uti利用更新、更灵活的技术替代了这些项目。

uti使用反向域名风格的命名约定。常见的源于apple的标识符看起来如下：public.html和public.jpeg，它们分别指html源文本和jpeg图像，二者都是专用的文件信息类型。

继承对于uti起着重要作用。uti使用类似于oo的继承系统，其中子uti具有对父uti的“is-a”（是一个）关系。子uti会继承它们的父uti的所有属性，但是会添加它们表示的数据种类的更多特征。这是由于每个uti都可以根据需要承担更一般或者更特定的角色。例如，以jpeg uti为例。jpeg图像（public.jpeg）是一幅图像（public.image），而图像反过来又是一种数据（public.data），数据反过来又是一种用户可查看（或者可收听）的内容（public.content），它是一种项目（public.item），即用于uti的普通的基本类型。这种层次结构被称为顺应性，其中子uti顺应父uti。例如，更具体的jpeg uti顺应更一般的图像或数据uti。

图2-1显示了apple的基本顺应性树的一部分。这棵树上位于较低位置的任何项目都必须顺应其所有父数据属性。声明一个父uti意味着支持它的所有子uti。因此，可以打开public.data的应用程序必须能够服务于文本、电影、图像文件等。

uti支持多重继承。一个项目可以顺应多个父uti 。因此，你可能设想一种同时提供文本和图像容器的数据类型，它声明了对二者的顺应性。

没有用于uti项目的中心注册表，尽管每个uti都应该遵守约定。public域是为特定于ios的类型预留的，是大多数应用程序所共有的。apple生成了公共项目的一个完整的家族层次结构。可以使用标准的预留域命名方式添加任何特定于第三方公司的名称（例如，com.sadun.mycustomtype和com.apple.quicktime-movie）。

2.1.1 通过文件扩展名确定uti

mobile core services框架提供了一些实用程序，允许基于文件扩展名获取uti信息。在使用这些基于c语言的函数时，一定要包括头文件，并把应用程序连接到框架。当给下面的函数传递一个路径扩展字符串时，它将返回一个首选的uti。首选的标识符是单个uti字符串：

可以使用kuttagclassmimetype作为第一个参数，给uttypecreatepreferredidentifierfortag()传递一种mime类型代替文件扩展名。该函数将为给定的mime类型返回首选的uti：

结合使用这些函数，将允许你从文件扩展名和mime类型转向用于现代文件访问uti类型。

2.1.2 从uti转向扩展名或mime类型

也可以另辟蹊径，从uti产生首选的扩展名或mime类型，这要使用uttypecopy preferredtagwithclass()。当给下面的函数传递public.jpeg时，它们将分别返回jpeg和image/jpeg：

必须在叶子层使用这些函数，这意味着直接在该层级声明类型扩展名。扩展名声明在属性列表中，其中将描述像文件扩展名和默认图标这样的特性。因此，例如，给扩展名函数传递public.text或public.movie将返回nil，而public.plain-text和public.mpeg则将分别返回扩展名txt和mpg。

前面的项目将在顺应性树中处于较高的位置，从而提供一种抽象类型，而不是特定的实现。对于目前为应用程序定义的给定类，没有现成的api函数用于寻找从它传承下来的项目。你可能想在bugreport.apple.com上归档一个增强请求。诚然，所有的扩展名和mime类型都会注册在某个位置（否则，uttypecopypreferredtagwithclass()将怎样从一开始就执行向上查找的工作），因此把扩展名映射到更一般的uti的能力应该是可能存在的。

mime助手

尽管从扩展名到uti的服务是很详尽的，可以为几乎任何扩展名返回uti，但是从uti到mime的结果则很随意，有些漫无目标。通常可以为任何公共项目生成正确的mime表示；公共程度较低的项目则很少见。

下面的代码行显示了各种各样的扩展名、它们的uti（通过首选的utiforextension()获取），以及从每个uti生成的mime类型（通过mimetypeforuti()）。可以看到，其中有相当多的空白。当这些函数不能找到匹配时，它们将返回nil：

为了解决这个问题，用于这个秘诀的示例代码包括了一个额外的mimehelper类。它定义了一个函数，返回所提供的扩展名的mime类型：

nsstring mimeforextension(nsstring extension);

它的扩展名和mime类型源于apache software foundation，它将其列表放入公共域中。对于用于这个秘诀的示例代码中的450个扩展名，ios返回了全部450个uti，但是只会返回88个mime类型。apache列表把这个数字增加到230个可识别的mime类型。

2.1.3 测试顺应性

使用uttypeconformsto()函数测试顺应性。该函数接受两个参数：一个源uti和一个要比较的uti，如果第一个uti顺应第二个uti，就返回true。可以使用这个函数来测试一个更具体的项目是否顺应一个更一般的项目。相等性测试则使用uttypeequal()。下面显示了一个示例，说明了可能如何使用顺应性测试，确定文件路径是否可能指向图像资源：

2.1.4 获取顺应性列表

uttypecopydeclaration()是ios api中的所有uti函数中最一般（并且最有用）的函数，它返回包含以下键的字典。

kuttypeidentifierkey：uti名称，它将被传递给函数（例如，public.mpeg）。

kuttypeconformstokey：类型顺应的任何父项目（例如，public.mpeg顺应public.movie）。

kuttypedescriptionkey：正在考虑的类型（如果存在的话）的现实描述（例如，“mpeg movie”）。

kuttypetagspecificationkey：给定uti的等价ostype（例如，mpg和mpeg）、文件扩展名（mpg、mpeg、mpe、m75和m15）和mime类型（视频/mpeg、视频/mpg、视频/x-mpeg和视频/x-mpg）的字典。

除了这些公共项目之外，还会遇到更多的键，它们指定了导入和导出的uti描述（kutimportedtypedeclarationskey和kutexportedtypedeclarationskey）、与uti相关联的图标资源（kuttypeiconfilekey）、指向描述类型的页面的url（kuttypereferenceurlkey），以及为uti提供版本字符串的版本键（kuttypeversionkey）。

使用返回的字典向上通过顺应性树来构建一个数组，表示给定uti顺应的所有项目。例如，public.mpeg类型顺应public.movie、public.audiovisual-content、public.data、public.item和public.content。通过conformancearray函数将这些项目返回为一个数组，如秘诀2-1所示。

秘诀2-1 测试顺应性