Property list
Filename extension |
.plist |
---|---|
Uniform Type Identifier (UTI) | com.apple.property-list |
Developed by |
Apple Computer and GNUstep, formerly NeXT |
Type of format | Serialization of dictionary objects. |
In the macOS, iOS, NeXTSTEP, and GNUstep programming frameworks, property list files are files that store serialized objects. Property list files use the filename extension .plist, and thus are often referred to as p-list files.
Property list files are often used to store a user's settings. They are also used to store information about bundles and applications, a task served by the resource fork in the old Mac OS.
Representations
Since the data represented by property lists is somewhat abstract, the underlying file format can be implemented many ways. Namely, NeXTSTEP used one format to represent a property list, and the subsequent GNUstep and macOS frameworks introduced differing formats.
NeXTSTEP
Under NeXTSTEP, property lists were designed to be human-readable and edited by hand, serialized to ASCII in a syntax somewhat like a programming language.
Strings were represented as:
"This is a plist string"
Binary data was represented as:
< [hexadecimal codes in ASCII] >
Arrays were represented as:
( "1", "2", "3" )
And dictionaries were represented as:
{ "key" = "value"; ... }
One limitation of the original NeXT property list format is that it could not represent an NSValue (number, boolean, etc.) object.
GNUstep
GNUstep adopts the NeXTSTEP format, with a few additions. First, it now supports NSValue objects (which are represented as plain ASCII), and second, it supports NSDate objects (which are serialized as <*DYYYY-MM-DD HH:MM:SS timezone>)
GNUstep can also read and write property lists in the formats used by macOS.
macOS
While macOS can also read the NeXTSTEP format, Apple sets it aside in favor of two new formats of its own.
In Mac OS X 10.0, the NeXTSTEP format was deprecated, and a new XML format was introduced, with a public DTD defined by Apple. The XML format supports non-ASCII characters and storing NSValue objects (which, unlike GNUstep's ASCII property list format, Apple's ASCII property list format does not support).[1]
Since XML files, however, are not the most space-efficient means of storage, Mac OS X 10.2 introduced a new format where property list files are stored as binary files. Starting with Mac OS X 10.4, this is the default format for preference files. In Mac OS X 10.7, support for reading and writing files in JSON format was introduced. JSON and property lists are not fully compatible with each other, though. For example, property lists have native date and data types, which the JSON format does not support. Conversely, JSON permits null values while property lists do not support explicit nulls.
The plutil utility (introduced in Mac OS X 10.2) can be used to check the syntax of property lists, or convert a property list file from one format to another. Also, the defaults utility (introduced in NeXTSTEP) can be used to manipulate plist files used for storage of preferences (also known before OS X as defaults, hence the name) on the command line via their preferences domain, and this utility can be used to edit arbitrary plist files. Another tool is the PlistBuddy command line utility which resides at /usr/libexec/PlistBuddy and is useful for merging plist files and altering entries related to software development.
XML and JSON property lists are hand-editable in any text editor. Additionally, Apple provides support in Xcode for editing property lists in a hierarchical viewer/editor that can handle plists formatted in binary or XML, but not JSON. As of Mac OS X 10.4, Apple provides an AppleScript interface for reading property list files through the System Events application. As of Mac OS X 10.5, Apple provides an AppleScript interface for editing, creating and writing property list files as well.[2]
For the XML format, the tags, related Foundation classes and CoreFoundation types, and data storage formats are as follows:
Foundation class | CoreFoundation type | XML Tag | Storage format |
---|---|---|---|
NSString |
CFString |
<string> |
UTF-8 encoded string |
NSNumber |
CFNumber |
<real> , <integer> |
Decimal string |
NSNumber |
CFBoolean |
<true/> or <false/> |
No data (tag only) |
NSDate |
CFDate |
<date> |
ISO 8601 formatted string |
NSData |
CFData |
<data> |
Base64 encoded data |
NSArray |
CFArray |
<array> |
Can contain any number of child elements An empty array may be represented as <array/> |
NSDictionary |
CFDictionary |
<dict> |
Alternating <key> tags and plist element tags |
The Binary file format is documented in a comment block in the C code source file for Apple's open sourced implementation of binary plists in its Foundation library. Apple describes the implementation as opaque in its plist manual page documentation; which means that reliance on the format is discouraged. In the binary file format the magic number (the first few bytes of the file which indicate that its a valid plist file) is the text bplist.
The binary file can store information that cannot be captured in the XML or JSON file formats. The array, set and dictionary binary types are made up of pointers - the objref and keyref entries - that index into an object table in the file. This means that binary plists can capture the fact that - for example - a separate array and dictionary serialized into a file both have the same data element stored in them. This cannot be captured in an XML file. Converting such a binary file will result in a copy of the data element being placed into the XML file. Additionally the binary file has a UID type that is used to identify data items when serialized. In practice this UID type is simply expanded into a 64 bit integer. The complete list of data that can be stored taken from the C code source file is as follows:
Foundation class | CoreFoundation type | Object type | Marker byte | Encoded data |
---|---|---|---|---|
null | 0000 0000 | n/a | ||
NSNumber | CFBoolean | bool | 0000 1000 (false) or 0000 1001 (true) | n/a |
fill | 0000 1111 (fill byte) | n/a | ||
NSNumber | CFNumber | int | 0001 nnnn | # of bytes is 2^nnnn, big-endian bytes |
NSNumber | CFNumber | real | 0010 nnnn | # of bytes is 2^nnnn, big-endian bytes |
NSDate | CFDate | date | 0011 0011 | 8 byte float follows, big-endian bytes |
NSData | CFData | data | 0100 nnnn [int] | nnnn is number of bytes unless 1111 then int count follows, followed by bytes |
NSString | CFString | string | 0101 nnnn [int] | ASCII string, nnnn is # of chars, else 1111 then int count, then bytes |
NSString | CFString | string | 0110 nnnn [int] | Unicode string, nnnn is # of chars, else 1111 then int count, then big-endian 2-byte uint16_t |
NSNumber | CFNumber | UID | 1000 nnnn | nnnn+1 is # of bytes. In practice a big-endian 64bit int, packed into 1, 2, 4 or 8 bytes |
NSArray | CFArray | array | 1010 nnnn [int] | objref* nnnn is count, unless '1111', then int count follows |
NSSet | CFSet | set | 1100 nnnn [int] | objref* nnnn is count, unless '1111', then int count follows |
NSDictionary | CFDictionary | dict | 1101 nnnn [int] | keyref* objref* nnnn is count, unless '1111', then int count follows |
Windows
Although best known on Apple or Darwin systems, including iOS and Mac OSX, plist files are also present on Windows computers when Apple Software, such as iTunes[3] or Safari[4] are installed. On Windows the files are typically binary files, although some applications may generate PLIST files in the other formats.
On Windows the plist files are stored in the users home directory under the following path:
%HOMEPATH%\AppData\Roaming\Apple Computer
These plist files on Windows typically store preferences and other information, rather than using the Windows registry. Options for editing PLIST files on Windows are not as extensive as on macOS. If the file is in the XML or JSON format with care a text editor such as NotePad++ can be used. Its also possible to use plutil.exe which ships with Safari for Windows to convert binary plist files into XML, then edit with a text or XML editor, such as PlistEditorPro and then afterwards convert back to binary, again using plutil.exe. Note that although Apple stopped shipping Safari for Windows in 2012[5] it is still available for download on some sites. This provides a zero cost solution for Plist editing on Windows. The commercial tool Plistinator is a plist editor that handles both XML and binary plist files on Windows.
See also
References
- ↑ appleexaminer.com: "PLIST files"
- ↑ http://web.archive.org/web/20090424003555/http://www.apple.com/applescript/features/propertylists.html
- ↑ https://www.theiphonewiki.com/wiki/ITunes_Backup
- ↑ http://superuser.com/questions/452360/how-does-the-apple-safari-web-browser-store-its-settings-on-windows
- ↑ http://9to5mac.com/2012/07/25/apple-appears-to-currently-be-passing-on-safari-6-0-features-for-windows-pcs/
External links
- The plist(5) manual page at developer.apple.com
- Excel add-in for creating plist file from Excel table
- Java API for reading/writing various plist formats - compatible with Android