捆绑包创建者操作系统类型代码???在Xcode 4中
我刚刚意识到我的 iOS 应用程序的 Info.plist 中的 Bundle Creator OS Type code 值在 Xcode 4 中是 ??????。什么是值应该是？
I just realized that Bundle Creator OS Type code in my iOS app's Info.plist value is ????? in Xcode 4. What is the value supposed to be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
它用于识别您的应用程序。您不必为 iPhone 应用程序更改它。
看一下这些链接：
信息属性列表键参考
Mac Creator 和文件类型代码
数据类型注册< /a>
It's used to identify your application. You don't have to change it for an iPhone application.
Take a look at these links:
Information Property List Key Reference
Mac Creator and File Type Codes
Data Type Registration
已经不再真正使用了。
这是经典 Mac OS 时代的遗留物
当它是一个数据点时，主要用于确定哪些应用程序可以创建、编辑或读取文件类型。
那时你必须在苹果公司注册它们。
我认为他们甚至不再提供这项服务了。
OS X 和一些应用程序可能仍然在极少数情况下在幕后使用它，但它是非常传统的。
正如您可以想象的那样，可能的排列受到严格限制，使其无法长期维持。
尿路感染是现在的首选方法。然后系统使用这些以及文件扩展名和幻数的组合。尽管在 ios 上这可能不像 OSX 那样真实。
It's not really used anymore.
It's a holdover from the Classic Mac OS days
when it was a datapoint used mainly to determine what apps could create or edit or read file types.
Back then you had to register them with Apple.
I don't think they even provide that service any more.
OS X and some apps might still use it in rare cases under the hood but its very legacy.
As you can imagine, the severely limited possible permutations made it untenable long term.
UTIs are the preferred approach now. The system then uses a combination of these and file extensions and magic numbers. Though on ios that may not be true as much as OSX.
它只是识别边界创建者的四个字母代码...例如对于苹果来说它是 APPL...
可以是？？？或者，如果您的应用程序名称是“myApp”，您可以提供“MYAP”...如果您有很多应用程序，您可以提供前 2 个字符为您的应用程序名称，后 2 个字符为公司名称...
例如，苹果使用 CF 作为核心基金会、AV 等
http://developer. apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
It is just the four letter code to identify the bunder creator... for example for apple it is APPL...
It can be ???? or if your app name is "myApp" you can give "MYAP"... If you have many apps you can give first 2 characters with your app name and next 2 characters with company name...
For example apple uses CF for core foundation, AV etc
http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
只是提供有关扩展名、文件类型和创建者代码的历史观点。
文件扩展名是 CP/M 中文件系统的一部分，其功能类似于文件类型和创建者代码在 MacOS 中实际执行的功能。当时，预计每个应用程序都将使用唯一的扩展名，并且只有一个应用程序可以编辑自己的文件。在文件系统中，文件名和扩展名存储在两个不同的区域，因此扩展名不是名称的一部分。请记住，当时大多数系统只有几个应用程序，并且文件内容特定于某个应用程序。它们本来就不应该对最终用户可见，但由于 CP/M 中的目录命令中的错误，它们显示为就好像它们是文件名的一部分一样。 MS-DOS 继承了这一惯例，不幸的是，其余的都已成为历史。
苹果最初的文件系统设计就看到了扩展概念的缺点，第一个是某些文件类型可能会被多个应用程序使用，并且随着文件格式的标准化，拥有多个可以对一个文件进行操作的应用程序将会很常见。因此，苹果将文件创建者（创建文件的应用程序）与文件类型分开。默认情况下，如果双击文件，最初创建的应用程序将打开它。但是，如果用户从应用程序内打开文件，则应该列出所有兼容文件，即使该应用程序不是创建者。此外，还可以列出可以打开文件的所有应用程序。从语义上讲，正如 CP/M 中的预期，类型和创建者代码与文件名本身是分开的。
向 Apple 正确注册应用程序的开发人员可以获得自己的创建者代码。这个概念的问题有两个来源： 1. 开发者劫持了其他人或苹果自己的创作者代码。 2. Unix 系统从未有过正式的文件扩展名（所有文件名都是单个字符串），开始采用以点结尾文件名的约定和一些附加字母来指示文件类型。在 Unix 约定中，扩展名是文件名本身的一部分，这与 CP/M 和 MS-DOS 不同。
Just to give the historical perspective on extensions and file type and creator codes.
File extensions were part of the file system in CP/M and were intended to function something like what file types and creator codes actually did in MacOS. At the time, it was expected that each application would use a unique extension and only the one application would ever edit its own files. In the file system, the file name and extension were stored in two different areas, so the extension was not part of the name. Remember, at that time most systems had only a few applications, and file contents were specific to an application. They were never intended to be visible to end users, but due to an error in the directory command in CP/M, they were shown displayed as if they were part of the file name. MS-DOS picked up the convention, and the rest, unfortunately is history.
Apple's initial file system design saw the shortcomings of the extension concept, the primary one being that some file types were likely to be used by more than one application and with standardization of file formats, having more than one application that could operate on a file would be common. Therefore Apple split the file creator - the app that created the file - from the file type. By default if a file was double clicked, the originally creating application would open it. However, if a user did a file open from within an application, then all compatible files were supposed to be listed, even if that app was not the creator. Also, it would be possible to list all the applications that could open a file. Semantically, as intended in CP/M, the type and creator codes were separate from the file name itself.
Developers that properly registered their applications with Apple got their own creator codes. The problems with this concept came about from two sources: 1. Developers that hijacked other's or Apples own creator codes. 2. Unix systems, which never had a formal filename extension (all file names were a single string) began adopting the convention to end the file name with a dot and some additional letters to indicate file type. In the Unix convention, the extension is part of the file name itself, unlike CP/M and MS-DOS.