3

2013 年 4 月 9 日更新 这是对我之前问题的完全转发。随着我对启动服务、UTI 和贬值的创建者代码了解得更多，我觉得我最好从头开始问这个问题。

问题描述：

我们有一个专为 Legacy Mac 9.xx 设计的应用程序，它仍然在 Snow Leopard（带有 Rosetta）上运行。该应用程序使用捆绑文件我们为 Snow Leopard 及其他应用程序开发了我们的新应用程序。问题是启动服务没有根据我们当前使用的 plist 配置正确关联新应用程序，我需要知道我做错了什么。

如果我右键单击捆绑的文档并选择 GetInfo，我可以将捆绑的文件关联到旧应用程序或新应用程序，它会按我的预期工作。我相信那是因为雪豹仍然使用 Creator Code 技术进行这种关联。如果我告诉文件将自身与旧的旧应用程序关联并按“全部更改”，则启动服务将正确关联该类型的所有文件，并且它将按预期工作。如果我告诉文件将自己关联到新应用程序并选择“全部更改”，应用程序将打开，但文件不会。据我所知，启动服务正在为应用程序分配一个动态 UTI，当单击文件时，操作系统不知道要使用哪个应用程序。

我发现一些帖子似乎暗示苹果可能在新的 UTI 方法中犯了一些设计错误。这里的一篇文章展示了如何将一组字符串文件扩展名添加到新应用 pList 的 ExportedUTI 字典中。这会使应用程序正常运行，但这并不能解决问题；如果我们允许我们的用户为他们的文件命名，我们无法在数组中预测他们的文件扩展名将是什么。我们需要启动服务以严格使用 UTI 代码正确运行，或者如何让 OSType 代码正常工作。

关于尿路感染的帖子

一旦新应用程序决定它无法打开它的相关文件，我必须打开 LanchServices.plist，删除条目并重新启动 lsregister 数据库。然后我可以再次使用新应用程序打开一个文件（通过关联它而不按“全部更改”）。

我将一些图像附加到应用 plists 、捆绑的文档 plist 和 Launch Services 条目：

旧应用程序列表

新应用列表

捆绑文档中的 plist

新应用程序的启动服务条目

非常感谢任何帮助和我们的指导。

麦克风

更新日期：2013 年 4 月 16 日

我提供的关于 UTI 的帖子的链接还包括一个名为 RCDefault 应用程序的开源软件应用程序的链接。此应用程序将根据您选择的 UTI、文件扩展名、OSType 代码和文件类型将您的 APP 与给定文件相关联。奇怪的是，这个应用程序能够根据我们 plist 中提供的 UTI 结构将文件与应用程序相关联。

对于这种特定情况，这是否可能只是雪豹启动服务中的一个错误，而苹果此时选择忽略它（考虑到他们不再支持雪）？

4

2 回答 2

1

您缺少 CFBundleTypeExtensions。创建一个数组类型的 CFBundleTypeExtensions，第 0 项应该是您的文件扩展名。

您还缺少 CFBundleTypeName，这是文件将使用的别名类型。让它漂亮漂亮。:)

参考（CFBundleDocumentTypes）：https ://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html

于 2013-04-12T20:50:13.543 回答
0

自从我最初发布此内容以来已经有一段时间了，但为了以防其他人对此感兴趣，我已经做出了一些额外的发现：

这个问题与尝试与旧版应用程序和 OSX 应用程序兼容没有太大关系。捆绑的文件包含一个创建者代码和一个 OSType 代码。只要这两个项目存在于遗留应用程序 plist 中，它就会在被要求时，全局或单独打开。

问题似乎是试图将 ostype 代码包含在较新的应用程序 plist 中，作为导出类型 UTI 下的等效类型。

唯一可行的解​​决方案是将文件扩展名数组添加为与@Derek 开头提到的等效类型。

这是解决此问题的唯一解决方案。具有讽刺意味的是，这违反了苹果的人机界面指南，该指南在某种程度上规定了用户不应被迫接受文件扩展名限制。

似乎 UTI 仅适用于非捆绑文档（文件），这也得到了一些帖子的支持，基本上说苹果真的搞砸了。如果最终您仍然需要扩展数组，那么担心 UTI 有什么意义？

于 2013-10-17T21:13:42.773 回答