Swift 4 JSON 解析指南

Apple 終於在 Swift 4 的 Foundation 的模塊中添加了對 JSON 解析的原生支持。

雖然已經有不少第三方類庫實現了 JSON 解析，可是可以看到這樣一個功能強大、易於使用的官方實現仍是難免有些興奮。

值得注意的是，官方的實現方式適用於任何 Encoder/Decoder ，例如 PropertyListEncoder 。固然若是你須要 XML 格式的內容，能夠進行自定義實現。在接下來的內容中，咱們將專一於 JSON 格式的解析，由於這是 iOS 開發中最多見的數據格式。

基礎

若是你的 JSON 數據結構和你使用的 Model 對象結構一致的話，那麼解析過程將會很是簡單。

下面是一個JSON 格式的啤酒說明：

{
    "name": "Endeavor",
    "abv": 8.9,
    "brewery": "Saint Arnold",
    "style": "ipa"
}

對應的 Swift 數據結構以下：

enum BeerStyle : String {
    case ipa
    case stout
    case kolsch
    // ...
}

struct Beer {
    let name: String
    let brewery: String
    let style: BeerStyle
}

爲了將 JSON 字符串轉化爲 Beer 類型的實例，咱們須要將 Beer 類型標記爲 Codable。

Codable 其實是 Encodable & Decodable 兩個協議的組合類型，因此若是你只須要單向轉換的話，你能夠只選用其中一個。該功能也是 Swift 4 中引入的最重要新特性之一。

Codable 帶有默認實現，因此在大多數情形下，你能夠直接使用該默認實現進行數據轉換。

enum BeerStyle : String, Codable {
   // ...
}

struct Beer : Codable {
   // ...
}

下面只須要建立一個解碼器：

let jsonData = jsonString.data(encoding: .utf8)!
let decoder = JSONDecoder()
let beer = try! decoder.decode(Beer.self, for: jsonData)

這樣咱們就將 JSON 數據成功解析爲了 Beer 實例對象。由於 JSON 數據的 Key 與 Beer 中的屬性名一致，因此這裏不須要進行自定義操做。

須要注意的是，這裏直接使用了 try! 操做。由於這裏只是簡單示例，因此在真實程序中你應該對錯誤進行捕獲並做出對應的處理。

可是，現實中不可能一直都是完美情形，很大概率存在 Key 值與屬性名不匹配的情形。

自定義鍵值名

一般情形下，API 接口設計時會採用 snake-case 的命名風格，可是這與 Swift 中的編程風格有着明顯的差別。

爲了實現自定義解析，咱們須要先去看下 Codable 的默認實現機制。

默認情形下 Keys 是由編譯器自動生成的枚舉類型。該枚舉遵照 CodingKey 協議並創建了屬性和編碼後格式之間的關係。

爲了解決上面的風格差別須要對其進行自定義，實現代碼：

struct Beer : Codable {
      // ...
      enum CodingKeys : String, CodingKey {
          case name
          case abv = "alcohol_by_volume"
          case brewery = "brewery_name"
          case style
    }
}

如今咱們將 Beer 實例轉化爲 JSON ，看看自定義以後的 JSON 數據格式：

let encoder = JSONEncoder()
let data = try! encoder.encode(beer)
print(String(data: data, encoding: .utf8)!)

輸出以下：

{"style":"ipa","name":"Endeavor","alcohol_by_volume":8.8999996185302734,"brewery_name":"Saint Arnold"}

上面的輸出格式對閱讀起來並非太友好。不過咱們能夠設置 JSONEncoder 的 outputFormatting 屬性來定義輸出格式。

默認 outputFormatting 屬性值爲 .compact，輸出效果如上。若是將其改成 .prettyPrinted 後就能得到更好的閱讀體檢。

encoder.outputFormatting = .prettyPrinted

效果以下：

{
  "style" : "ipa",
  "name" : "Endeavor",
  "alcohol_by_volume" : 8.8999996185302734,
  "brewery_name" : "Saint Arnold"
}

JSONEncoder 和 JSONDecoder 其實還有不少選項能夠自定義設置。其中有一個經常使用的需求就是自定義時間格式的解析。

時間格式處理

JSON 沒有數據類型表示日期格式，所以須要客戶端和服務端對序列化進行約定。一般情形下都會使用 ISO 8601 日期格式並序列化爲字符串。

提示：nsdateformatter.com 是一個很是有用的網站，你能夠查看各類日期格式的字符串表示，包括 ISO 8601。

其餘格式多是參考日期起的總秒（或毫秒）數，並將其序列化爲 JSON 格式中的數字類型。

以前，咱們必須本身處理這個問題。在數據結構中使用屬性接收該字符串格式日期，而後使用 DateFormatter 將該屬性轉化爲日期，反之亦然。

不過 JSONEncoder 和 JSONDecoder 自帶了該功能。默認狀況下，它們使用 .deferToDate 處理日期，以下：

struct Foo : Encodable {
    let date: Date
}

let foo = Foo(date: Date())
try! encoder.encode(foo)

{
  "date" : 519751611.12542897
}

固然，咱們也能夠選用 .iso8601 格式：

encoder.dateEncodingStrategy = .iso8601

{
  "date" : "2017-06-21T15:29:32Z"
}

其餘日期編碼格式選擇以下：

• .formatted(DateFormatter) - 當你的日期字符串是非標準格式時使用。須要提供你本身的日期格式化器實例。
• .custom( (Date, Encoder) throws -> Void ) - 當你須要真正意義上的自定義時，使用一個閉包進行實現。
• .millisecondsSince1970、 .secondsSince1970 - 這在 API 設計中不是很常見。 因爲時區信息徹底不在編碼表示中，因此不建議使用這樣的格式，這使得人們更容易作出錯誤的假設。

對日期進行 Decoding 時基本上是相同的選項，可是 .custom 形式是 .custom( (Decoder) throws -> Date )，因此咱們給了一個解碼器並將任意類型轉換爲日期格式。

浮點類型處理

浮點是 JSON 與 Swift 另外一個存在不匹配情形的類型。若是服務器返回的事無效的 "NaN" 字符串會發生什麼？無窮大或者無窮大？這些不會映射到 Swift 中的任何特定值。

默認的實現是 .throw，這意味着若是上述數值出現的話就會引起錯誤，不過對此咱們能夠自定義映射。

{
   "a": "NaN",
   "b": "+Infinity",
   "c": "-Infinity"
}

struct Numbers {
  let a: Float
  let b: Float
  let c: Float
}
decoder.nonConformingFloatDecodingStrategy =
  .convertFromString(
      positiveInfinity: "+Infinity",
      negativeInfinity: "-Infinity",
      nan: "NaN")

let numbers = try! decoder.decode(Numbers.elf, from: jsonData)
dump(numbers)

上述處理後：

__lldb_expr_71.Numbers
  - a: inf
  - b: -inf
  - c: nan

固然，咱們也可使用 JSONEncoder 的 nonConformingFloatEncodingStrategy 進行反向操做。

雖然大多數情形下上述處理不太可能出現，可是以防萬一也不給過。

Data 處理

有時候服務端 API 返回的數據是 base64 編碼過的字符串。

對此，咱們能夠在 JSONEncoder 使用如下策略：

• .base64
• .custom( (Data, Encoder) throws -> Void)

反之，編碼時可使用：

• .base64
• .custom( (Decoder) throws -> Data)

顯然，.base64 時最多見的選項，但若是須要自定義的話能夠採用 block 方式。

Wrapper Keys

一般 API 會對數據進行封裝，這樣頂級的 JSON 實體 始終是一個對象。

例如：

{
  "beers": [ {...} ]
}

在 Swift 中咱們能夠進行對應處理：

struct BeerList : Codable {
    let beers: [Beer]
}

由於鍵值與屬性名一致，全部上面代碼已經足夠了。

Root Level Arrays

若是 API 做爲根元素返回數組，對應解析以下所示：

let decoder = JSONDecoder()
let beers = try decoder.decode([Beer].self, from: data)

須要注意的是，咱們在這裏使用Array做爲類型。只要 T 可解碼，Array <T> 就可解碼。

Dealing with Object Wrapping Keys

另外一個常見的場景是，返回的數組對象裏的每個元素都被包裝爲字典類型對象。

[
  {
    "beer" : {
      "id": "uuid12459078214",
      "name": "Endeavor",
      "abv": 8.9,
      "brewery": "Saint Arnold",
      "style": "ipa"
    }
  }
]

你可使用上面的方法來捕獲此 Key 值，但最簡單的方式就是認識到該結構的可編碼的實現形式。

以下：

[[String:Beer]]

或者更易於閱讀的形式：

Array<Dictionary<String, Beer>>

與上面的 Array<T> 相似，若是 K 和 T 是可解碼 Dictionary<K,T> 就能解碼。

let decoder = JSONDecoder()
let beers = try decoder.decode([[String:Beer]].self, from: data)
dump(beers)

1 element
  ▿ 1 key/value pair
    ▿ (2 elements)
      - key: "beer"
      ▿ value: __lldb_expr_37.Beer
        - name: "Endeavor"
        - brewery: "Saint Arnold"
        - abv: 8.89999962
        - style: __lldb_expr_37.BeerStyle.ipa

更復雜的嵌套

有時候 API 的響應數據並非那麼簡單。頂層元素不必定只是一個對象，並且一般狀況下是多個字典結構。

例如：

{
    "meta": {
        "page": 1,
        "total_pages": 4,
        "per_page": 10,
        "total_records": 38
    },
    "breweries": [
        {
            "id": 1234,
            "name": "Saint Arnold"
        },
        {
            "id": 52892,
            "name": "Buffalo Bayou"
        }
    ]
}

在 Swift 中咱們能夠進行對應的嵌套定義處理：

struct PagedBreweries : Codable {
    struct Meta : Codable {
        let page: Int
        let totalPages: Int
        let perPage: Int
        let totalRecords: Int
        enum CodingKeys : String, CodingKey {
            case page
            case totalPages = "total_pages"
            case perPage = "per_page"
            case totalRecords = "total_records"
        }
    }

    struct Brewery : Codable {
        let id: Int
        let name: String
    }

    let meta: Meta
    let breweries: [Brewery]
}

該方法的最大優勢就是對同一類型的對象作出不一樣的響應（可能在這種狀況下，「brewery」 列表響應中只須要 id 和 name 屬性，可是若是查看詳細內容的話則須要更多屬性內容）。由於該情形下 Brewery 類型是嵌套的，咱們依舊能夠在其餘地方進行不一樣的 Brewery 類型實現。

結論

Swift 4 中基礎 Codable API 的內容已經介紹差很少了。更多的內容能夠查看Codable.swift、Using JSON with Custom Types 。

更多內容，能夠去我個站