En los marcos de programación macOS , iOS , NeXTSTEP y GNUstep , los archivos de lista de propiedades son archivos que almacenan objetos serializados . Los archivos de lista de propiedades usan la extensión de nombre de archivo y, por lo tanto, a menudo se los denomina archivos de lista p . .plist
Los archivos de lista de propiedades se utilizan a menudo para almacenar la configuración de un usuario. También se utilizan para almacenar información sobre paquetes y aplicaciones , una tarea que se realizaba mediante la bifurcación de recursos en el antiguo sistema operativo Mac.
Las listas de propiedades también se utilizan para las cadenas de localización para el desarrollo. Estos archivos utilizan las extensiones .stringso .stringsdict. El primero es un plist de estilo antiguo "reducido" que contiene solo un diccionario sin las llaves (consulte propertyListFromStringsFileFormat ), [1] mientras que el segundo es un plist completo. Xcode también utiliza una extensión para los plists de estilo antiguo que se utilizan como archivos de proyecto. .pbxproj
Dado que los datos representados por las listas de propiedades son algo abstractos , el formato de archivo subyacente se puede implementar de muchas maneras. Es decir, NeXTSTEP utilizó un formato para representar una lista de propiedades, y los marcos GNUstep y macOS posteriores introdujeron formatos diferentes.
En NeXTSTEP , las listas de propiedades se diseñaron para que fueran legibles y editadas a mano, y se serializaron en ASCII con una sintaxis similar a la de un lenguaje de programación . OPENSTEP utilizó este mismo formato .
"This is a plist string\n"; se permiten cadenas más simples, sin comillas, siempre que consistan en caracteres alfanuméricos y uno de _$+/:.- .< [hexadecimal codes in ASCII] >( "1", "2", "3" ). Se toleran comas finales.{ "key" = "value"; ... }. El lado izquierdo debe ser una cadena, pero puede estar sin comillas./* This is a comment */y // This is a line comment.Una limitación del formato original de la lista de propiedades de NeXT es que no podía representar un objeto NSValue (número, booleano, etc.). Como resultado, estos valores tendrían que convertirse en cadenas y la aplicación los tendría que recuperar de forma "difusa". [2] Otra limitación es que no hay una codificación oficial de 8 bits definida. [3]
La utilidad defaults , introducida en OPENSTEP (1996), se puede utilizar para manipular archivos plist utilizados para el almacenamiento de preferencias (conocidos como defaults en NeXTSTEP, de ahí el nombre) en la línea de comandos a través de su dominio de preferencias, y esta utilidad se puede utilizar para editar archivos plist arbitrarios. Esta utilidad reemplazó a tres comandos más antiguos (dread, dwrite y dremove). [4]
GNUstep adopta el formato NeXTSTEP, con añadidos para representar los tipos de datos NSValue y NSDate. Las nuevas entradas tipificadas tienen la forma <* T ...> , donde T es un código de tipo de una letra. Por ejemplo, un NSValue de tipo booleano YES se representa como <*BY> y los objetos NSDate se representan como . [5] [6] Los datos binarios también pueden utilizar el formato base64 más eficiente como <[ b64... ]> . El problema de los 8 bits también se resuelve implícitamente, ya que la mayoría de las implementaciones utilizan UTF-8. En resumen, NSPropertyListGNUstepFormat aporta la expresividad y la compacidad del formato de texto legible por humanos a la par del formato XML de Apple.<*DYYYY-MM-DD HH:MM:SS +ZZZZ>
GNUstep también tiene su propio formato binario, NSPropertyListGNUstepBinaryFormat , implementado en NSSerialization . Este formato se define recursivamente como los formatos textuales, con un marcador de tipo de un solo byte que precede a algunos datos. Se admite una forma de internación de cadenas a través de un modificador shouldBeCompact de la extensión GS . [7]
En GNUstep se encuentran dos manejadores de plist relativamente independientes: CFPropertyList en libs-core-base (CoreFoundation) y NSPropertyList en libs-base (Foundation Kit). Ambos admiten hasta cierto punto los formatos binarios y XML utilizados por macOS, pero el último es mucho más completo. Por ejemplo, los dos formatos específicos de GNUstep solo se manejan en el último. [8]
GNUstep proporciona un conjunto de herramientas de línea de comandos plist basadas en NSPropertyList , incluida una versión de pl [9] y defaults . [4]
Si bien macOS también puede leer el formato NeXTSTEP, Apple lo deja de lado en favor de dos nuevos formatos propios, uno basado en XML y el otro binario. Apple también tiene un formato JSON parcialmente compatible ( NSJSONSerialization ).
En Mac OS X 10.0 , el formato NeXTSTEP quedó obsoleto y se introdujo un nuevo formato XML , con un DTD público definido por Apple . El formato XML admite caracteres no ASCII y el almacenamiento de objetos NSValue (que, a diferencia del formato de lista de propiedades ASCII de GNUstep, el formato de lista de propiedades ASCII de Apple no admite). [10]
Sin embargo, como los archivos XML no son el medio de almacenamiento más eficiente en cuanto a espacio, Mac OS X 10.2 introdujo un nuevo formato en el que los archivos de listas de propiedades se almacenan como archivos binarios. A partir de Mac OS X 10.4 , este es el formato predeterminado para los archivos de preferencias. En Mac OS X 10.7 , se introdujo la compatibilidad para leer y escribir archivos en formato JSON . Sin embargo, JSON y las listas de propiedades no son totalmente compatibles entre sí. Por ejemplo, las listas de propiedades tienen tipos de datos y fechas nativos, que el formato JSON no admite. Por el contrario, JSON permite nullvalores, mientras que las listas de propiedades no admiten valores nulos explícitos.
La antigua herramienta de valores predeterminados de NeXTSTEP sigue estando disponible. El comando /usr/libexec/PlistBuddy proporciona un editor de listas interactivo. También se puede crear mediante scripts. [11]
La utilidad plutil (introducida en Mac OS X 10.2 ) se puede utilizar para comprobar la sintaxis de las listas de propiedades o convertir un archivo de lista de propiedades de un formato a otro. También admite la conversión de listas plist a literales de objeto Objective-C o Swift. [12] Al igual que la Cocoa NSPropertyListSerialization en la que se basa, acepta entradas de "estilo antiguo", pero no convierte a este tipo. (La Cocoa NSSerializer de antes de Mac OS X 10.2 emite una salida de estilo antiguo).
La utilidad pl se introdujo en Mac OS X v10.5. Toma cualquier entrada e intenta generar plists de "estilo antiguo". [13] [a] Al igual que la versión GNUstep, parece utilizar la propiedad description de los tipos Foundation que se encuentran en plists, que Apple ha especificado para producir plists de estilo antiguo válidos. [b]
En cuanto a los componentes internos, Apple proporciona un analizador de código abierto para formatos antiguos, XML y binarios en su código C Core Foundation llamado CFPropertyList. Sin embargo, todas las utilidades y la mayoría de las partes del sistema utilizan el analizador de código cerrado NSPropertyList del Obj-C Foundation Kit. La reimplementación de Swift es de código abierto, pero no se garantiza que sea idéntica.
Las listas de propiedades XML y JSON se pueden editar manualmente en cualquier editor de texto. Además, Apple proporciona soporte en Xcode para editar listas de propiedades en un visor/editor jerárquico que puede manejar plists formateados en binario o XML , pero no JSON . A partir de Mac OS X 10.4 , Apple proporciona una interfaz AppleScript para leer archivos de listas de propiedades a través de la aplicación Eventos del sistema. A partir de Mac OS X 10.5 , Apple proporciona una interfaz AppleScript para editar, crear y escribir archivos de listas de propiedades también. [14]
Para el formato XML, las etiquetas, las clases Foundation y los tipos CoreFoundation relacionados y los formatos de almacenamiento de datos son los siguientes:
El formato de archivo binario está documentado en un bloque de comentarios en el archivo fuente del código C de Core Foundation ( CF/CFBinaryPList.c ) para la implementación de código abierto de Apple de plists binarios en su biblioteca Foundation. [15] Apple describe la implementación como opaca en la documentación de la página del manual plist(5), [16] lo que significa que no se recomienda confiar en el formato. En el formato de archivo binario, el número mágico (los primeros bytes del archivo que indican que es un archivo plist válido) es el texto bplist , seguido de dos bytes que indican la versión del formato.
El archivo binario puede almacenar cierta información que no se puede capturar en los formatos de archivo XML o JSON. Los tipos binarios de matriz, conjunto y diccionario están formados por punteros (las entradas objref y keyref) que indexan una tabla de objetos en el archivo. Esto significa que las listas binarias pueden capturar el hecho de que, por ejemplo, una matriz y un diccionario separados serializados en un archivo tienen ambos el mismo elemento de datos almacenado en ellos. Esto no se puede capturar en un archivo XML. La conversión de un archivo binario de este tipo dará como resultado una copia del elemento de datos que se colocará en el archivo XML. Además, el archivo binario tiene un tipo UID que se utiliza para identificar elementos de datos cuando se serializan. La lista completa de datos que se pueden almacenar tomada del archivo fuente del código C es la siguiente:
Tenga en cuenta la nota v"1?"+ en muchos tipos. Esto significa que el byte marcador solo se encuentra en archivos con una versión de formato no inferior al número mágico "1?". La forma precisa de analizarlos es más nebulosa que la forma de analizar los tipos heredados, ya que la implementación de CFBinaryPlist solo maneja la versión "0?". En la práctica, estos tipos nunca se encuentran, ya que NSKeyedArchiver ya es capaz de capturar esta información.
A continuación de la tabla de objetos aparece una tabla de desplazamientos, seguida por un final que contiene información sobre el tamaño y la ubicación de las dos tablas.
Dado que las listas de propiedades no capturan toda la información y los tipos de datos necesarios para describir un objeto arbitrario, a menudo se realiza una capa adicional de codificación y decodificación. La especificación OpenStep abstrae la operación de serialización de cualquier NSObject bajo el protocolo NSCoding . Cualquier clase que implemente este protocolo puede tener sus instancias serializadas por una subclase NSCoder en algún otro formato. [18] Existen dos codificadores principales con el propósito de serializar objetos en plists:
Entre otras cosas, el uso de un archivador permite codificar nuevos tipos de datos sin cambiar el formato plist en sí y es la forma preferida de Apple para codificar cosas como NSSets y valores nulos. Analizar los formatos resulta un poco más difícil, ya que se debe seguir una capa más incluso para algunas clases que se supone que deben admitir los plists. Al igual que el formato binario que también tiene una tabla de objetos, es posible crear referencias circulares en NSKeyedArchiver . Dado que no hay un tipo de datos UID en XML, los números enteros se almacenan en un diccionario bajo la clave "CF$UID". [19]
Apple publica un NSKeyedArchiver de código abierto en Swift Corelibs Foundation; al igual que la Apple Foundation de código cerrado, restringe los formatos de salida a binarios y XML únicamente. También tiene algunos casos de prueba que muestran los resultados de la serialización. [20] GNUstep también tiene una implementación compatible, que no limita los formatos de salida. [21]
No existe un lenguaje de ruta único y estandarizado para listas de propiedades como XPath para XML, pero existen convenciones informales utilizadas por varios programas.
(id) -[NSObject(NSKeyValueCoding) valueForKeyPath:]Ningún formato puede expresar una clave con el carácter separador en ella.
Aunque son más conocidos en los sistemas Apple o Darwin, incluidos iOS y macOS, los archivos plist también están presentes en las computadoras Windows cuando se instala el software de Apple, como iTunes [22] o Safari [23] . En Windows, los archivos suelen ser archivos binarios [24] , aunque algunas aplicaciones pueden generar archivos PLIST en otros formatos.
En Windows, los archivos plist de Apple se almacenan en el directorio de inicio del usuario, en %USERPROFILE%\AppData\Roaming\Apple Computer . Estos archivos plist de Windows suelen almacenar preferencias y otra información, en lugar de utilizar el registro de Windows.
Las opciones para editar archivos PLIST en Windows no son tan amplias como en macOS. Si el archivo está en formato XML o JSON, se puede utilizar un editor de texto como Notepad++ . Apple incluye un plutil.exe en su paquete "Apple Application Support" (que forma parte de iTunes ) y es idéntico a su contraparte de macOS.
Introducida en 2006 y publicada por primera vez con NetBSD#4.0 (2007), es una biblioteca proplib que se puede utilizar para serializar datos entre el núcleo y el espacio de usuario. Implementa parte del lenguaje plist de XML. [25]
Uno de los usuarios de muestra de proplib es la segunda revisión del marco sysmon envsys para la monitorización del sistema .
La biblioteca proplib de NetBSD también fue trasladada a DragonFly en 2010 y está disponible desde DragonFly BSD#2.8 . [26]
plistlibmódulo incorporado para leer y escribir archivos plist, en XML de Apple o en binario (desde Python 3.4). [28] ProperTree es un editor multiplataforma que hace uso de esta biblioteca. [29]plistpaquete que admite cuatro tipos de plists: texto OpenStep, texto GNUStep, XML de Apple y binario de Apple. También maneja UID en formatos XML y binarios. [2]descriptionbase Obj-C NSDatatiene errores porque devuelve una representación de diccionario. La base Swift de código abierto no tiene ese problema.Cuando Unmarshal encuentra una lista de propiedades de OpenStep, entrará en un modo de análisis relajado: las listas de propiedades de OpenStep solo pueden almacenar datos antiguos como cadenas, por lo que intentaremos recuperar valores enteros, de punto flotante, booleanos y de fecha donde sea necesario.
El tipo de datos CF$UID en el Listado 2 es un diccionario con una clave única ("CF$UID") seguida de un número entero (este diseño es lo que verá cuando la lista de propiedades se represente en XML; en el formato binario sin procesar, el tipo de datos "UID" es una entidad separada que no requiere la estructura del diccionario). Estos tipos de datos representan una referencia a otra entidad en la matriz "$objects". El número del CF$UID indica la posición de la matriz.