文件列表:

Podfile.lock (1887, 2016-08-03)
Pods (0, 2016-08-03)
Pods\AFNetworking (0, 2016-08-03)
Pods\AFNetworking\AFNetworking (0, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFHTTPSessionManager.h (19805, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFHTTPSessionManager.m (15023, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFNetworkReachabilityManager.h (8068, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFNetworkReachabilityManager.m (9805, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFNetworking.h (1599, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFSecurityPolicy.h (5900, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFSecurityPolicy.m (12991, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFURLRequestSerialization.h (22823, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFURLRequestSerialization.m (51367, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFURLResponseSerialization.h (12238, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFURLResponseSerialization.m (27058, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFURLSessionManager.h (30165, 2016-08-03)
Pods\AFNetworking\AFNetworking\AFURLSessionManager.m (55294, 2016-08-03)
Pods\AFNetworking\LICENSE (1104, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking (0, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\AFAutoPurgingImageCache.h (5849, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\AFAutoPurgingImageCache.m (7625, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\AFImageDownloader.h (9078, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\AFImageDownloader.m (17594, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\AFNetworkActivityIndicatorManager.h (5496, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\AFNetworkActivityIndicatorManager.m (9853, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIActivityIndicatorView+AFNetworking.h (2002, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIActivityIndicatorView+AFNetworking.m (5051, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIButton+AFNetworking.h (10056, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIButton+AFNetworking.m (12936, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIImage+AFNetworking.h (1312, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIImageView+AFNetworking.h (5948, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIImageView+AFNetworking.m (6328, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIKit+AFNetworking.h (1762, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIProgressView+AFNetworking.h (2470, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIProgressView+AFNetworking.m (5160, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIRefreshControl+AFNetworking.h (2013, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIRefreshControl+AFNetworking.m (4802, 2016-08-03)
Pods\AFNetworking\UIKit+AFNetworking\UIWebView+AFNetworking.h (4533, 2016-08-03)
... ...

# JSONKit JSONKit is licensed under the terms of the BSD License. Copyright © 2011, John Engelhart. ### A Very High Performance Objective-C JSON Library

Parsing	Serializing
23% Faster than Binary .plist !	549% Faster than Binary .plist !

* Benchmarking was performed on a MacBook Pro with a 2.66GHz Core 2. * All JSON libraries were compiled with `gcc-4.2 -DNS_BLOCK_ASSERTIONS -O3 -arch x86_***`. * Timing results are the average of 1,000 iterations of the user + system time reported by [`getrusage`][getrusage]. * The JSON used was [`twitter_public_timeline.json`](https://github.com/samsoffes/json-benchmarks/blob/master/Resources/twitter_public_timeline.json) from [samsoffes / json-benchmarks](https://github.com/samsoffes/json-benchmarks). * Since the `.plist` format does not support serializing [`NSNull`][NSNull], the `null` values in the original JSON were changed to `"null"`. * The [experimental](https://github.com/johnezang/JSONKit/tree/experimental) branch contains the `gzip` compression changes. * JSONKit automagically links to `libz.dylib` on the fly at run time– no manual linking required. * Parsing / deserializing will automagically decompress a buffer if it detects a `gzip` signature header. * You can compress / `gzip` the serialized JSON by passing `JKSerializeOptionCompress` to `-JSONDataWithOptions:error:`. *** JavaScript Object Notation, or [JSON][], is a lightweight, text-based, serialization format for structured data that is used by many web-based services and API's. It is defined by [RFC 4627][]. JSON provides the following primitive types: * `null` * Boolean `true` and `false` * Number * String * Array * Object (a.k.a. Associative Arrays, Key / Value Hash Tables, Maps, Dictionaries, etc.) These primitive types are mapped to the following Objective-C Foundation classes:

JSON	Objective-C
null	NSNull
true and false	NSNumber
Number	NSNumber
String	NSString
Array	NSArray
Object	NSDictionary

JSONKit uses Core Foundation internally, and it is assumed that Core Foundation ≡ Foundation for every equivalent base type, i.e. [`CFString`][CFString] ≡ [`NSString`][NSString]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119][]. ### JSON To Objective-C Primitive Mapping Details * The [JSON specification][RFC 4627] is somewhat ambiguous about the details and requirements when it comes to Unicode, and it does not specify how Unicode issues and errors should be handled. Most of the ambiguity stems from the interpretation and scope [RFC 4627][] Section 3, Encoding: `JSON text SHALL be encoded in Unicode.` It is the authors opinion and interpretation that the language of [RFC 4627][] requires that a JSON implementation MUST follow the requirements specified in the [Unicode Standard][], and in particular the [Conformance][Unicode Standard - Conformance] chapter of the [Unicode Standard][], which specifies requirements related to handling, interpreting, and manipulating Unicode text. The default behavior for JSONKit is strict [RFC 4627][] conformance. It is the authors opinion and interpretation that [RFC 4627][] requires JSON to be encoded in Unicode, and therefore JSON that is not legal Unicode as defined by the [Unicode Standard][] is invalid JSON. Therefore, JSONKit will not accept JSON that contains ill-formed Unicode. The default, strict behavior implies that the `JKParseOptionLooseUnicode` option is not enabled. When the `JKParseOptionLooseUnicode` option is enabled, JSONKit follows the specifications and recommendations given in [The Unicode 6.0 standard, Chapter 3 - Conformance][Unicode Standard - Conformance], section 3.9 *Unicode Encoding Forms*. As a general rule of thumb, the Unicode code point `U+FFFD` is substituted for any ill-formed Unicode encountered. JSONKit attempts to follow the recommended *Best Practice for Using U+FFFD*: ***Replace each maximal subpart of an ill-formed subsequence by a single U+FFFD.*** The following Unicode code points are treated as ill-formed Unicode, and if `JKParseOptionLooseUnicode` is enabled, cause `U+FFFD` to be substituted in their place: `U+0000`.
`U+D800` thru `U+DFFF`, inclusive.
`U+FDD0` thru `U+FDEF`, inclusive.
U+nFFFE and U+nFFFF, where *n* is from `0x0` to `0x10` The code points `U+FDD0` thru `U+FDEF`, U+nFFFE, and U+nFFFF (where *n* is from `0x0` to `0x10`), are defined as ***Noncharacters*** by the Unicode standard and "should never be interchanged". An exception is made for the code point `U+0000`, which is legal Unicode. The reason for this is that this particular code point is used by C string handling code to specify the end of the string, and any such string handling code will incorrectly stop processing a string at the point where `U+0000` occurs. Although reasonable people may have different opinions on this point, it is the authors considered opinion that the risks of permitting JSON Strings that contain `U+0000` outweigh the benefits. One of the risks in allowing `U+0000` to appear unaltered in a string is that it has the potential to create security problems by subtly altering the semantics of the string which can then be exploited by a malicious attacker. This is similar to the issue of [arbitrarily deleting characters from Unicode text][Unicode_UTR36_Deleting]. [RFC 4627][] allows for these limitations under section 4, Parsers: `An implementation may set limits on the length and character contents of strings.` While the [Unicode Standard][] permits the mutation of the original JSON (i.e., substituting `U+FFFD` for ill-formed Unicode), [RFC 4627][] is silent on this issue. It is the authors opinion and interpretation that [RFC 4627][], section 3 – *Encoding*, `JSON text SHALL be encoded in Unicode.` implies that such mutations are not only permitted but MUST be expected by any strictly conforming [RFC 4627][] JSON implementation. The author feels obligated to note that this opinion and interpretation may not be shared by others and, in fact, may be a minority opinion and interpretation. You should be aware that any mutation of the original JSON may subtly alter its semantics and, as a result, may have security related implications for anything that consumes the final result. It is important to note that JSONKit will not delete characters from the JSON being parsed as this is a [requirement specified by the Unicode Standard][Unicode_UTR36_Deleting]. Additional information can be found in the [Unicode Security FAQ][Unicode_Security_FAQ] and [Unicode Technical Report #36 - Unicode Security Consideration][Unicode_UTR36], in particular the section on [non-visual security][Unicode_UTR36_NonVisualSecurity]. * The [JSON specification][RFC 4627] does not specify the details or requirements for JSON String values, other than such strings must consist of Unicode code points, nor does it specify how errors should be handled. While JSONKit makes an effort (subject to the reasonable caveats above regarding Unicode) to preserve the parsed JSON String exactly, it can not guarantee that [`NSString`][NSString] will preserve the exact Unicode semantics of the original JSON String. JSONKit does not perform any form of Unicode Normalization on the parsed JSON Strings, but can not make any guarantees that the [`NSString`][NSString] class will not perform Unicode Normalization on the parsed JSON String used to instantiate the [`NSString`][NSString] object. The [`NSString`][NSString] class may place additional restrictions or otherwise transform the JSON String in such a way so that the JSON String is not bijective with the instantiated [`NSString`][NSString] object. In other words, JSONKit can not guarantee that when you round trip a JSON String to a [`NSString`][NSString] and then back to a JSON String that the two JSON Strings will be exactly the same, even though in practice they are. For clarity, "exactly" in this case means bit for bit identical. JSONKit can not even guarantee that the two JSON Strings will be [Unicode equivalent][Unicode_equivalence], even though in practice they will be and would be the most likely cause for the two round tripped JSON Strings to no longer be bit for bit identical. * JSONKit maps `true` and `false` to the [`CFBoolean`][CFBoolean] values [`kCFBooleanTrue`][kCFBooleanTrue] and [`kCFBooleanFalse`][kCFBooleanFalse], respectively. Conceptually, [`CFBoolean`][CFBoolean] values can be thought of, and treated as, [`NSNumber`][NSNumber] class objects. The benefit to using [`CFBoolean`][CFBoolean] is that `true` and `false` JSON values can be round trip deserialized and serialized without conversion or promotion to a [`NSNumber`][NSNumber] with a value of `0` or `1`. * The [JSON specification][RFC 4627] does not specify the details or requirements for JSON Number values, nor does it specify how errors due to conversion should be handled. In general, JSONKit will not accept JSON that contains JSON Number values that it can not convert with out error or loss of precision. For non-floating-point numbers (i.e., JSON Number values that do not include a `.` or `e|E`), JSONKit uses a ***-bit C primitive type internally, regardless of whether the target architecture is 32-bit or ***-bit. For unsigned values (i.e., those that do not begin with a `-`), this allows for values up to 2***-1 and up to -263 for negative values. As a special case, the JSON Number `-0` is treated as a floating-point number since the underlying floating-point primitive type is capable of representing a negative zero, whereas the underlying twos-complement non-floating-point primitive type can not. JSON that contains Number values that exceed these limits will fail to parse and optionally return a [`NSError`][NSError] object. The functions [`strtoll()`][strtoll] and [`strtoull()`][strtoull] are used to perform the conversions. The C `double` primitive type, or [IEEE 754 Double ***-bit floating-point][Double Precision], is used to represent floating-point JSON Number values. JSON that contains floating-point Number values that can not be represented as a `double` (i.e., due to over or underflow) will fail to parse and optionally return a [`NSError`][NSError] object. The function [`strtod()`][strtod] is used to perform the conversion. Note that the JSON standard does not allow for infinities or `NaN` (Not a Number). The conversion and manipulation of [floating-point values is non-trivial](http://www.validlab.com/goldberg/paper.pdf). Unfortunately, [RFC 4627][] is silent on how such details should be handled. You should not depend on or expect that when a floating-point value is round tripped that it will have the same textual representation or even compare equal. This is true even when JSONKit is used as both the parser and creator of the JSON, let alone when transferring JSON between different systems and implementations. * For JSON Objects (or [`NSDictionary`][NSDictionary] in JSONKit nomenclature), [RFC 4627][] says `The names within an object SHOULD be unique` (note: `name` is a `key` in JSONKit nomenclature). At this time the JSONKit behavior is `undefined` for JSON that contains names within an object that are not unique. However, JSONKit currently tries to follow a "the last key / value pair parsed is the one chosen" policy. This behavior is not finalized and should not be depended on. The previously covered limitations regarding JSON Strings have important consequences for JSON Objects since JSON Strings are used as the `key`. The [JSON specification][RFC 4627] does not specify the details or requirements for JSON Strings used as `keys` in JSON Objects, specifically what it means for two `keys` to compare equal. Unfortunately, because [RFC 4627][] states `JSON text SHALL be encoded in Unicode.`, this means that one must use the [Unicode Standard][] to interpret the JSON, and the [Unicode Standard][] allows for strings that are encoded with different Unicode Code Points to "compare equal". JSONKit uses [`NSString`][NSString] exclusively to manage the parsed JSON Strings. Because [`NSString`][NSString] uses [Unicode][Unicode Standard] as its basis, there exists the possibility that [`NSString`][NSString] may subtly and silently convert the Unicode Code Points contained in the original JSON String in to a [Unicode equivalent][Unicode_equivalence] string. Due to this, the JSONKit behavior for JSON Strings used as `keys` in JSON Objects that may be [Unicode equivalent][Unicode_equivalence] but not binary equivalent is `undefined`. ### Objective-C To JSON Primitive Mapping Details * When serializing, the top level container, and all of its children, are required to be *strictly* [invariant][wiki_invariant] during enumeration. This property is used to make certain optimizations, such as if a particular object has already been serialized, the result of the previous serialized `UTF8` string can be reused (i.e., the `UTF8` string of the previous serialization can simply be copied instead of performing all the serialization work again). While this is probably only of interest to those who are doing extraordinarily unusual things with the run-time or custom classes inheriting from the classes that JSONKit will serialize (i.e, a custom object whose value mutates each time the it receives a message requesting its value for serialization), it also covers the case where any of the objects to be serialized are mutated during enumeration (i.e., mutated by another thread). The number of times JSONKit will request an objects value is non-deterministic, from a minimum of once up to the number of times it appears in the serialized JSON– therefore an object MUST NOT depend on receiving a message requesting its value each time it appears in the serialized output. The behavior is `undefined` if these requirements are violated. * The objects to be serialized MUST be acyclic. If the objects to be serialized contain circular references the behavior is `undefined`. For example,

[arrayOne addObject:arrayTwo];
    [arrayTwo addObject:arrayOne];
    id json = [arrayOne JSONString];

… will result in `undefined` behavior. * The contents of [`NSString`][NSString] objects are encoded as `UTF8` and added to the serialized JSON. JSONKit assumes that [`NSString`][NSString] produces well-formed `UTF8` Unicode and does no additional validation of the conversion. When `JKSerializeOptionEscapeUnicode` is enabled, JSONKit will encode Unicode code points that can be encoded as a single `UTF16` code unit as \uXXXX, and will encode Unicode code points that require `UTF16` surrogate pairs as \uhigh\ulow. While JSONKit makes every effort to serialize the contents of a [`NSString`][NSString] object exactly, modulo any [RFC 4627][] requirements, the [`NSString`][NSString] class uses the [Unicode Standard][] as its basis for representing strings. You should be aware that the [Unicode Standard][] defines [string equivalence][Unicode_equivalence] in a such a way that two strings that compare equal are not required to be bit for bit identical. Therefore there exists the possibility that [`NSString`][NSString] may mutate a string in such a way that it is [Unicode equivalent][Unicode_equivalence], but not bit for bit identical with the original string. * The [`NSDictionary`][NSDictionary] class allows for any object, which can be of any class, to be used as a `key`. JSON, however, only permits Strings to be used as `keys`. Therefore JSONKit will fail with an error if it encounters a [`NSDictionary`][NSDictionary] that contains keys that are not [`NSString`][NSString] objects during serialization. More specifically, the keys must return `YES` when sent [`-isKindOfClass:[NSString class]`][-isKindOfClass:]. * JSONKit will fail with an error if it encounters an object that is not a [`NSNull`][NSNull], [`NSNumber`][NSNumber], [`NSString`][NSString], [`NSArray`][NSArray], or [`NSDictionary`][NSDictionary] class object during serialization. More specifically, JSONKit will fail with an error if it encounters an object where [`-isKindOfClass:`][-isKindOfClass:] returns `NO` for all of the previously mentioned classes. * JSON does not allow for Numbers that are ±Infinity or ±NaN. Therefore JSONKit will fail with an error if it encounters a [`NSNumber`][NSNumber] that contains such a value during serialization. * Objects created with [`[NSNumber numberWithBool:YES]`][NSNumber_numberWithBool] and [`[NSNumber numberWithBool:NO]`][NSNumber_numberWithBool] will be mapped to the JSON values of `true ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：