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)!)

輸出如下：

上面的輸出格式對閱讀起來並不是太友好。不過我們可以設置 JSONEncoder 的outputFormatting屬性來定義輸出格式。

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

encoder.outputFormatting = .prettyPrinted

效果如下：

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)

當然，我們也可以選用.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)

反之，編碼時可以使用：

.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 就可解碼。

Dealing with Object Wrapping Keys

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

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

如下：

[[String:Beer]]

或者更易於閱讀的形式：

Array

與上面的 Array 類似，如果 K 和 T 是可解碼 Dictionary 就能解碼。

let decoder = JSONDecoder() let beers = try decoder.decode([[String:Beer]].self, from: data) dump(beers)更複雜的嵌套

有時候 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。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！