C:\ ONGRTLNS.OSX

或者:Snow Leopard中的创作者代码没有替代品

暂时忽略创建者代码如何工作的具体技术细节(或者,更好的放置,工作)重要的是它们启用的行为,即在不同的应用程序中打开相同类型的文档的能力默认情况下一个非常常见的情况:HTML文件对于从Web上下载的自述文件和其他文件的内容read作为呈现的HTML内容,是的,我希望它们默认在我的Web浏览器中打开但对于我自己创建的“.html”文件,我希望它们默认在我的文本编辑器中打开That used to work; now, in Snow Leopard, it does not.

Launch Services是Mac OS X的子系统,用于确定默认情况下哪个应用程序将打开文件“默认情况下”的含义是,您(用户)表示您要打开文件,而不直接指定要在其中打开的应用程序最常见的是,双击Finder中的文件会在其默认处理程序中打开文档。

Starting in Snow Leopard, these default file bindings are determined entirely by file name extensions; HFS+ creator codes, if present, are now ignoredSnow Leopard设置文档以使用应用程序而不是声明文档的文件扩展名所有权的应用程序打开的唯一方法是使用Finder的“获取信息”窗口手动进行分配在幕后,这为文档的资源分支添加了一个“usro”资源,即资源的内容(如应用程序的包标识符“com.apple.TextEdit”)而是一个硬编码的字符串,其中包含应用程序本身的路径(例如“/Applications/TextEdit.app”)。

就是这样 - 文件扩展名和这些“usro”资源是将文件绑定到应用程序的唯一剩余方法并作为Chris Suter在他的博客上记录了这篇文章,将这样的资源添加到文件的唯一方法是通过a私人的启动服务API用户可以手动使用Finder的信息窗口,但没有支持公共API开发人员可以使用第三方软件(cf。这个主题在Apple的Cocoa-Dev邮件列表中从两个星期前)。

现在,关于类型和创建者代码的实际技术细节,毫无疑问它们已经过时了(但不像文件扩展名那样过时。)它们可以追溯到1984年的原始Macintosh,一台128千字节RAM的机器,使用400千字节的软盘进行存储每个字节都很珍贵,因此类型和创建者代码(以及原始Mac OS的许多其他方面)都使用简洁但神秘的四字节代码(“OSTypes”)实现作为人类可读性的辅助,四字节代码通常呈现为四字符MacRoman编码的字符串其中许多字符串都是自然的助记符:纯文本文件的类型代码是“TEXT”,应用程序的类型代码是“APPL”我打赌你可以猜测为JPEG文件类型代码Application creator codes were often cute: the Finder’s creator code is “MACS”; BBEdit, created by Rich Siegel, has the creator code “R*ch”.

但只有你可以做四个字节今天没有充分的理由将所有内容塞入四字节代码中(也没有任何理由对字符串使用单字节文本编码)Mac OS X 10.0引入了一种独特的识别应用程序的方法:包标识符Bundle identifiers like “com.apple.Safari” and “com.apple.iTunes” are more expressive, informative, and obvious than creator codes like “sfri” and “hook”.

正如John Siracusa指出的那样他的“元数据疯狂”一块,不需要一个新的“替换”创造者代码替换是捆绑标识符,它自2001年以来一直在这里每个Mac应用都已拥有唯一的捆绑标识符但是,缺少的是将捆绑标识符与单个文件相关联以指示哪个应用创建了该文件的任何支持方式。

在旧类型/创建者代码系统中,文件是基于个人分配给应用程序的在Snow Leopard中,Launch Services仅考虑文件的类型,类型来自文件扩展名,默认绑定只能在类型和应用程序之间进行管理,而不是单个文件和应用程序。

Snow Leopard实际上为我们提供了Windows 3.0的文件到应用程序绑定策略。

插值关于统一类型标识符和传说声称他们“修复”创造者代码

每次我与覆盖其他关于雪豹否认造物主的代码,一些读者请发邮件给我链接丹尼尔·伊兰迪尔格主题的文章,题为“Snow Leopard里面的UTI:Apple修复了Creator Code“,假设该文章证明了它的主张它不是我一手包办称之为“喋喋不休”上周,促使几位读者问为什么我会这么说。

好的,我会咬人的。

这篇文章的标题声称“Apple修复了Creator Code”然后在第一段:

Instead, Apple has invented a superior alternative for the old Creator Code in order to support a variety of new features. Here’s why, and what the new Uniform Type Identifiers offer.

这听起来很有趣,特别是以后我对UTI的理解是因为他们不以任何方式取代创作者代码的功能。

然后来了2,900个单词,其中没有一个单词解释了标题和第一段中所承诺的内容。

然后是倒数第二段,Dilger写道:

Users who miss being able to automatically open a file using the app that originally created it can pester their app’s developer to get on the ball with UTIAny application that has been updated since 2005’s Tiger, but which does not yet support UTI, has opted not to support an important feature of the Mac platform.

这简直是​​错误的任何开发人员都无法使用UTI或任何其他支持的技术来恢复Snow Leopard中创建者代码的功能这是错的UTI表示文件的类型,而不是默认情况下应该打开的应用程序此外,开发人员甚至无法直接将UTI分配给文件UTI源自文件扩展名。

然后我们来到最后一段:

Everyone else, including many of us who didn’t ever understand why the system launched files using a specific app rather than the one we had defined for that given file type, can continue using the Finder’s Open With menu, drag and drop app launching, or set a permanent per-item default “creator” app for opening a selection of documents by using the Get Info panel.

So, after claiming at the outset that Apple has “fixed” creator codes by “inventing a superior alternative”, followed by 3,000 words of muddled technical information regarding a technology that is unrelated to binding files to applications, Dilger admits that there is no replacement for creator codes in Snow Leopard, but it’s good news anyway because he never liked the previous behavior in the first place他的结尾段落在技术上是准确的,但与文章的标题和开放前提完全不一致 - 除非他的意思是Apple有“固定”创作者代码,就像一个“修复”狗一样。

人们想要相信苹果公司不会拿出一个流行的功能而不用什么来代替它,但这是明确的事实。

插值结束,回到主要点,作为一个温和的后插值提醒,留下了关于Snow Leopard的文件到应用程序绑定策略与Windows 3.0的有效相同的Snide备注

退一步,认为这个词creator code本身就展示了今天的不同之处Mac创立之时,几乎所有文档都是专有的二进制文件格式唯一可以读取MacWrite文件的应用是MacWrite等即使应用程序可以读取其他应用程序的文件格式,它们通常也只能通过导入/导出过程执行此操作比方说,您可以将Word文档导入ClarisWorks,但不能直接打开文件并写回文件。

另一方面,今天,我们使用的许多文件都使用常见的开放文件格式:文本文件,JPEG和PNG图形,MP3音频,MP4视频等当您在1985年双击MacPaint文件时,毫无疑问您要打开它的应用程序:MacPaint但是,今天,您的系统上可能会有十几个应用程序可以打开JavaScript源代码文本文件或MP3音频文件“创建它的应用程序”可以不再被认为是问题的答案”,应用程序将默认你喜欢打开这个文件吗?”

今天情况因此复杂得多Apple处理这种复杂性的一种方法是在Finder中最近添加“Open With ...”上下文菜单,其中显示了声称能够打开所选项目类型的文件的应用程序列表还有总是拖放。

很久以前创建者代码停止意味着“创建文件的应用程序”,而是意味着“应用程序此文件应默认打开”重要的是,该功能现在已经消失,而不是它的名称,或将来会被称为假设的实际替代品。

需要明确的是,Snow Leopard的新绑定策略受到许多用户的欢迎If you really want all files of the same type to open in the same app by default, then a system based exclusively on file name extensions worksApple可能已经用基于包标识符的优势替换了创建者代码,但他们没有即使他们计划将来这样做,1没有充分的理由从Launch Services中删除创建者代码支持现在,在更换到货之前简单的事实是,许多人 - 显然包括Apple--更喜欢通过文件扩展名将文件绑定到应用程序。

“Make it a preference” is often (if not usually) the wrong way to solve a problem, but a case like this, where many people prefer/expect it one way and many prefer/expect it the other, is exactly the sort of situation that calls for a preference setting.

我可以继续并咆哮在一个字段中存储文件的元数据,名称和类型的两个基本部分的固有不足 - 束缚Apple这样宣称从1981年开始成为MS-DOS元数据限制的“世界上最先进的操作系统” - 但是没有必要为溢出的牛奶哭泣。


  1. 不要屏住呼吸。↩︎

以前: 雪豹采用率
下一个: 微软的Windows 7竞赛