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 utilizan la extensión de nombre de archivo y, por lo tanto, a menudo se les 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 realizaba la bifurcación de recursos en el antiguo Mac OS.
Las listas de propiedades también se utilizan para cadenas de localización para el desarrollo. Estos archivos utilizan las extensiones .stringso .stringsdict. El primero es un plist "reducido" de estilo antiguo que contiene solo un diccionario sin llaves (consulte propertyListFromStringsFileFormat ), [1] mientras que el segundo es un plist completo. Xcode también usa una extensión para plists de estilo antiguo que se usan 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 usó un formato para representar una lista de propiedades, y los marcos posteriores de GNUstep y macOS introdujeron diferentes formatos.
En NeXTSTEP , las listas de propiedades se diseñaron para que fueran legibles por humanos y editadas a mano, serializadas en ASCII en una sintaxis similar a la de un lenguaje de programación . Este mismo formato fue utilizado por OPENSTEP .
"This is a plist string\n"; Se permiten cadenas más simples, sin comillas, siempre que consten de caracteres alfanuméricos y uno de _$+/:.- .< [hexadecimal codes in ASCII] >( "1", "2", "3" ). Se toleran las comas al final.{ "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 de lista de propiedades NeXT original es que no puede representar un objeto NSValue (número, booleano, etc.). Como resultado, estos valores tendrían que convertirse en cadenas y la aplicación recuperarlos "confusamente". [2] Otra limitación es que no existe 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 valores predeterminados 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. [4]
GNUstep adopta el formato NeXTSTEP, con adiciones para representar los tipos de datos NSValue y NSDate. Las nuevas entradas escritas tienen la forma <* T ...> , donde T es un código de tipo de una letra. Por ejemplo, un NSValue 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. Con todo, NSPropertyListGNUstepFormat aporta la expresividad y compacidad del formato textual legible por humanos a la par con el 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 de forma recursiva como los formatos textuales, con un marcador de tipo de un solo byte precediendo algunos datos. Se admite una forma de pasantía en cadena a través de un conmutador de extensión GS mustBeCompact . [7]
En GNUstep se encuentran dos controladores de plist relativamente independientes: CFPropertyList en libs-core-base (CoreFoundation) y NSPropertyList en libs-base (Foundation Kit). Ambos admiten hasta cierto punto los formularios binarios y XML utilizados por macOS, pero este último es mucho más completo. Por ejemplo, los dos formatos específicos de GNUstep sólo 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 una DTD pública definida por Apple . El formato XML admite caracteres no ASCII y almacena 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, dado que los archivos XML no son el medio de almacenamiento que ahorra más 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 con la lectura y escritura de 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 disponible. El comando /usr/libexec/PlistBuddy proporciona un editor de plist interactivo. También se puede escribir un guión. [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 a literales de objetos Objective-C o Swift. [12] Al igual que Cocoa NSPropertyListSerialization en el que se basa, toma entradas de "estilo antiguo", pero no se convierte a este tipo. (El Cocoa NSSerializer anterior a Mac OS X 10.2 emite una salida de estilo antiguo).
La utilidad pl se introduce en Mac OS X v10.5. Toma cualquier entrada e intenta generar listas "al viejo estilo". [13] [a] Al igual que la versión GNUstep, parece utilizar la propiedad de descripción de los tipos Foundation que se encuentran en las listas plist, que Apple ha especificado para producir listas plist válidas de estilo antiguo. [b]
En términos internos, Apple proporciona un analizador de código abierto para formatos antiguos, XML y binarios en su código C Core Foundation como CFPropertyList. Sin embargo, todas las utilidades y la mayor parte del sistema utilizan el analizador NSPropertyList de código cerrado 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 listas formateadas en binario o XML , pero no en JSON . A partir de Mac OS X 10.4 , Apple proporciona una interfaz AppleScript para leer archivos de lista de propiedades a través de la aplicación Eventos del sistema. A partir de Mac OS X 10.5 , Apple también proporciona una interfaz AppleScript para editar, crear y escribir archivos de listas de propiedades. [14]
Para el formato XML, las etiquetas, las clases Foundation relacionadas y los tipos CoreFoundation y los formatos de almacenamiento de datos son los siguientes:
El formato del 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 plists binarias de Apple 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 se componen de 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 separada y un diccionario serializados en un archivo tienen el mismo elemento de datos almacenado en ellos. Esto no se puede capturar en un archivo XML. La conversión de dicho archivo binario dará como resultado que se coloque una copia del elemento de datos en el archivo XML. Además, el archivo binario tiene un tipo UID que se utiliza para identificar elementos de datos cuando se serializa. La lista completa de datos que se pueden almacenar tomados 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 sólo se encuentra en archivos con una versión de formato no inferior a "1?" número mágico. La forma precisa de analizarlos es más confusa 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.
Una tabla de compensaciones sigue a la tabla de objetos, a la que luego sigue un avance 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 serializar cualquier NSObject bajo el protocolo NSCoding . Cualquier clase que implemente este protocolo puede tener sus instancias serializadas mediante una subclase NSCoder en algún otro formato. [18] Existen dos codificadores principales con el fin 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 suponía que admitían las listas. Al igual que el formato binario que también tiene una tabla de objetos, es posible crear referencias circulares en NSKeyedArchiver . Como en XML no existe un tipo de datos UID, 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 Fundación Apple de código cerrado, restringe los formatos de salida a binario 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 lo hace XPath para XML, pero existen convenciones informales utilizadas por varios programas.
(id) -[NSObject(NSKeyValueCoding) valueForKeyPath:]Ninguno de los formatos puede expresar una clave con el carácter separador.
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 con Windows cuando se instala el software de Apple, como iTunes [ cita necesaria ] o Safari [22] . En Windows, los archivos suelen ser archivos binarios, [23] 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 en Windows normalmente almacenan 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 con cuidado un editor de texto como Notepad++ . Apple incluye plutil.exe dentro de su paquete "Apple Application Support" (que forma parte de iTunes ) y es idéntico a su contraparte de macOS.
Introducida en 2006 y lanzada por primera vez con NetBSD#4.0 (2007), es una biblioteca proplib, que se puede utilizar para serializar datos entre el kernel y el usuario. Implementa parte del lenguaje XML plist. [24]
Uno de los usuarios de muestra de proplib es la segunda revisión del marco sysmon envsys para el monitoreo del sistema .
La biblioteca proplib de NetBSD también se transfirió a DragonFly en 2010 y está disponible desde DragonFly BSD#2.8 . [25]
plistlibmódulo incorporado para leer y escribir archivos plist, en XML de Apple o en binario (desde Python 3.4). [27] ProperTree es un editor multiplataforma que hace uso de esta biblioteca. [28]plistpaquete que admite cuatro tipos de listas: texto OpenStep, texto GNUStep, Apple XML y Apple Binary. También maneja UID en formatos XML y binario. [2]descriptionFundación in Obj-C NSDatatiene errores porque devuelve una representación de diccionario. La Fundación 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 siempre que sean necesarios.
El tipo de datos CF$UID en el Listado 2 es un diccionario con una sola clave ("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 formato raw formato binario, 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 da la posición de la matriz.