Bundle créateur OS Type code? dans Xcode 4

Ce n'est plus vraiment utilisé. C'est un holdover des jours classiques de Mac OS quand il s'agissait d'un point de données utilisé principalement pour déterminer quelles applications pouvaient créer ou modifier ou lire des types de fichiers. À l'époque, vous deviez les enregistrer avec Apple. Je ne pense même plus qu'ils fournissent ce service. OS X et certaines applications peuvent toujours l'utiliser dans de rares cas sous le capot mais son héritage. Comme vous pouvez l'imaginer, les permutations possibles sévèrement limitées l'ont rendu intenable à long terme.

Les uti sont les approche préférée maintenant. Le système utilise ensuite une combinaison de ces extensions et de fichiers et de nombres magiques. Bien que sur ios Cela peut ne pas être vrai autant que OSX.

C'est juste le code à quatre lettres pour identifier le créateur DE bunder... par exemple, pour apple, il est APPL... Il peut être ???? ou si le nom de votre application est "myApp", vous pouvez donner "MYAP"... Si vous avez de nombreuses applications, vous pouvez donner les 2 premiers caractères avec le nom de votre application et les 2 prochains caractères avec le nom de l'entreprise...

Par exemple, apple utilise CF pour core foundation, AV etc

Http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html

Juste pour donner la perspective historique sur les extensions et les codes de type de fichier et de créateur.

Les extensions de fichiers faisaient partie du système de fichiers dans CP/M et étaient destinées à fonctionner quelque chose comme ce que les types de fichiers et les codes de création faisaient réellement dans MacOS. À l'époque, on s'attendait à ce que chaque application utilise une extension unique et qu'une seule application édite ses propres fichiers. Dans le système de fichiers, le nom de fichier et l'extension ont été stockés dans deux zones différentes, de sorte que le l'extension ne faisait pas partie du nom. Rappelez-vous, à cette époque, la plupart des systèmes n'avaient que quelques applications, et le contenu des fichiers était spécifique à une application. Ils n'ont jamais été destinés à être visibles pour les utilisateurs finaux, mais en raison d'une erreur dans la commande directory dans CP/M, ils ont été affichés comme s'ils faisaient partie du nom de fichier. MS-DOS ramassé la convention, et le reste, malheureusement, est l'histoire.

La conception initiale du système de fichiers D'Apple a vu les lacunes du concept d'extension, le principale étant que certains types de fichiers sont susceptibles d'être utilisés par plus d'une application et à la normalisation des formats de fichier, avoir plus d'une application qui peut fonctionner sur un fichier commun. Par conséquent, Apple a divisé le créateur de fichiers - l'application qui a créé le fichier-à partir du type de fichier. Par défaut, si un fichier a été double-cliqué, l'application créée à l'origine l'ouvrirait. Cependant, si un utilisateur a ouvert un fichier à partir d'une application, tous les fichiers compatibles ont été censé être listé, même si cette application n'était pas le créateur. En outre, il serait possible de lister toutes les applications qui pourraient ouvrir un fichier. Sémantiquement, comme prévu dans CP / M, les codes de type et de créateur étaient séparés du nom de fichier lui-même.

Les développeurs qui ont correctement enregistré leurs applications avec Apple ont obtenu leurs propres codes de créateur. Les problèmes posés par ce concept proviennent de deux sources: 1. Les développeurs qui ont détourné d'autres ou des pommes propres codes de créateur. 2. Les systèmes Unix, qui jamais eu une extension de nom de fichier formelle (tous les noms de fichiers étaient une seule chaîne) a commencé à adopter la convention pour terminer le nom de fichier avec un point et quelques lettres supplémentaires pour indiquer le type de fichier. Dans la convention Unix, L'extension fait partie du nom de fichier lui-même, contrairement à CP / M et MS-DOS.