(The Cocoa NSSerializer from before Mac OS X 10.2 emits old-styled output.) Like the Cocoa NSPropertyListSerialization it is built on, it takes "old-style" inputs, but does not convert to this type. It also supports converting plists to Objective-C or Swift object literals. 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. The /usr/libexec/PlistBuddy command provides an interactive plist editor. The old defaults tool from NeXTSTEP remains available. Conversely, JSON permits null values while property lists do not support explicit nulls. For example, property lists have native date and data types, which the JSON format does not support. JSON and property lists are not fully compatible with each other, though. In Mac OS X 10.7, support for reading and writing files in JSON format was introduced. Starting with Mac OS X 10.4, this is the default format for preference files. 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.
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). 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. Apple also has a partially-compatible JSON format ( NSJSONSerialization). While macOS can also read the NeXTSTEP format, Apple sets it aside in favor of two new formats of its own, one XML-based and the other binary. GNUstep provides a set of plist command-line tools based on NSPropertyList, including a version of pl and defaults. For example, the two GNUstep-specific formats are only handled in the latter. Both support the binary and XML forms used by macOS to some degree, but the latter is a lot more complete. Two relative independent plist handlers are found in GNUstep: the CFPropertyList in libs-core-base (CoreFoundation), and the NSPropertyList in libs-base (Foundation Kit).
A form of string interning is supported via a GS-extension shouldBeCompact switch. This format is defined recursively like the textual formats, with a single-byte type marker preceding some data. GNUstep also has its own binary format, NSPropertyListGNUstepBinaryFormat, implemented in NSSerialization. All in all, NSPropertyListGNUstepFormat brings the expressiveness and compactness of the human-readable textual format on par with Apple's XML format. The 8-bit problem is implicitly solved as well, as most deployments use UTF-8. Binary data can also use the more efficient base64 format as. For example, an NSValue of boolean YES is represented as and NSDate objects are represented as. The new typed entries have the form, where T is a one-letter type code. GNUstep adopts the NeXTSTEP format, with additions for representing NSValue and NSDate data types. This utility superseded three older commands. The defaults utility, introduced in OPENSTEP (1996), can be used to manipulate plist files used for storage of preferences (known as defaults in NeXTSTEP, hence the name) on the command line via their preferences domain, and this utility can be used to edit arbitrary plist files. Another limitation is that there is no official 8-bit encoding defined. As a result, these values would have to be converted to string, and "fuzzily" recovered by the application. One limitation of the original NeXT property list format is that it could not represent an NSValue (number, boolean, etc.) object. Value statements terminate by a semicolon. As in C, whitespace are generally insignificant to syntax.Comments are allowed as: /* This is a comment */ and // This is a line comment.The left-hand side must be a string, but it can be unquoted. Spaces and comments between paired hex-codes are ignored. Strings are represented in C literal style: "This is a plist string\n" simpler, unquoted strings are allowed as long as they consist of alphanumericals and one of _$+/.
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. Namely, NeXTSTEP used one format to represent a property list, and the subsequent GNUstep and macOS frameworks introduced differing formats. Since the data represented by property lists is somewhat abstract, the underlying file format can be implemented many ways.
0 kommentar(er)
