Apple 終於在 Swift 4 的 Foundation 的模塊中添加了對 JSON 解析的原生支持。 雖然已經有很多第三方類庫實現了 JSON 解析，但是能夠看到這樣一個功能強大、易於使用的官方實現還是不免有些興奮。 值得註意的是，官方的實現方式適用於任何 Encoder/Decoder ，例 ...
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 就可解碼。
Dealing with Object Wrapping Keys
另一個常見的場景是，返回的數組對象里的每一個元素都被包裝為字典類型對象。
[
{
"beer" : {
"id": "uuid12459078214",
"name": "Endeavor",
"abv": 8.9,
"brewery": "Saint Arnold",
"style": "ipa"
}
}
]
|
你可以使用上面的方法來捕獲此 Key 值，但最簡單的方式就是認識到該結構的可編碼的實現形式。
如下：
[[String:Beer]]
|
或者更易於閱讀的形式：
Array
|
與上面的 Array 類似，如果 K 和 T 是可解碼 Dictionary就能解碼。
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 。
