Swift 4 JSON 原生解析

Swift 4 的 更新中其中有一項就是在Foundation模塊中添加了對 JSON 解析的原生支持.

下面我們來看一看是如何使用的~

雖然已經有很多第三方類庫實現了 JSON 解析,但是還是官方的用起來心里舒服~。

基礎

如果你的 JSON 數據結構和你使用的 Model 對象結構一致的話,那么解析過程將會非常簡單。

下面是一個 JSON 格式的PersonInfo(什么例子都用Person 哈哈):

{
    "name": "TwinkleStar",
    "age": 24,
    "area": "BeiJing",
    "job": "engineer"
}

對應的 Swift 數據結構如下:

enum Job : String {
    case engineer
    case student
    case teacher
    // ...
}

struct PersonInfo {
    let name: String
    let age: String
    let job: Job
}

為了將 JSON 字符串轉化為 PersonInfo類型的實例,我們需要將 PersonInfo 類型標記為 Codable。

Codable 實際上是 Encodable & Decodable 兩個協議的組合類型,所以如果你只需要單向轉換的話,你可以只選用其中一個。該功能也是 Swift 4 中引入的最重要新特性之一。

Codable 帶有默認實現,所以在大多數情形下,你可以直接使用該默認實現進行數據轉換。

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

struct PersonInfo : Codable {
   // ...
}

下面只需要創建一個解碼器:

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

這樣我們就將 JSON 數據成功解析為了 PersonInfo 實例對象。因為 JSON 數據的 Key 與 PersonInfo 中的屬性名一致,所以這里不需要進行自定義操作。

需要注意的是,這里直接使用了 try! 操作。因為這里只是簡單示例,所以在真實程序中你應該對錯誤進行捕獲并作出對應的處理。

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

自定義鍵值名

通常情形下,API 接口設計時會采用 snake-case 的命名風格,但是這與 Swift 中的編程風格有著明顯的差異。

為了實現自定義解析,我們需要先去看下 Codable 的默認實現機制。

默認情形下 Keys 是由編譯器自動生成的枚舉類型。該枚舉遵守 CodingKey 協議并建立了屬性和編碼后格式之間的關系。

為了解決上面的風格差異需要對其進行自定義,實現代碼:

struct PersonInfo : Codable {
      // ...
      enum CodingKeys : String, CodingKey {
          case name
          case age
          case job
    }
}

現在我們將 PersonInfo 實例轉化為 JSON ,看看自定義之后的 JSON 數據格式:

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

輸出如下:

{"job":"engineer","name":"TwinkleStar","age":24}

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

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

encoder.outputFormatting = .prettyPrinted

效果如下:

{
  "job" : "engineer",
  "name" : "TwinkleStar",
  "age" : 24,
}

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 實體 始終是一個對象。

例如:

{
  "persons": [ {...} ]
}

在 Swift 中我們可以進行對應處理:

struct PersonInfoList : Codable {
    let persons: [PersonInfo]
}

因為鍵值與屬性名一致,所有上面代碼已經足夠了。

Root Level Arrays

如果 API 作為根元素返回數組,對應解析如下所示:

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

需要注意的是,我們在這里使用 Array 作為類型。只要 T 可解碼,Array <t style="box-sizing: border-box; outline: 0px;">就可解碼。</t>

Dealing with Object Wrapping Keys

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

[
  {
    "personInfo" : {
      "id": "uuid12459078214",
      "name": "TwinkleStar",
      "age": 24,
      "job": "enginner"
    }
  }
]

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

如下:

[[String:PersonInfo]]

或者更易于閱讀的形式:

Array<Dictionary<String, PersonInfo>>

與上面的 Array 類似,如果 K 和 T 是可解碼 Dictionary<K,T> 就能解碼。</t>

let decoder = JSONDecoder()
let persons = try decoder.decode([[String:PersonInfo]].self, from: data)
dump(persons)
 1 element
  ? 1 key/value pair
    ? (2 elements)
      - key: "personInfo"
      ? value: __lldb_expr_37.PersonInfo
        - name: "TwinkleStar"
        - age:24
        - job: __lldb_expr_37.Job.engineer

更復雜的嵌套

有時候 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” 列表響應中只需要 idname 屬性,但是如果查看詳細內容的話則需要更多屬性內容)。因為該情形下 Brewery 類型是嵌套的,我們依舊可以在其他地方進行不同的 Brewery 類型實現。

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,333評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,491評論 3 416
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,263評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,946評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,708評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,186評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,255評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,409評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,939評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,774評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,976評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,518評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,209評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,641評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,872評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,650評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,958評論 2 373

推薦閱讀更多精彩內容

  • 發現 關注 消息 iOS 第三方庫、插件、知名博客總結 作者大灰狼的小綿羊哥哥關注 2017.06.26 09:4...
    肇東周閱讀 12,151評論 4 61
  • 本篇文章接著上篇文章,還剩下一個知識點是,可滾動的結果接集和可更新的結果集。一般默認情況之下,多結果集是不可以顯式...
    Single_YAM閱讀 391評論 0 4
  • 空蕩蕩的木地板上灑滿陽光,貓咪在玩耍,心情很放松。 我的家里空無一物。一共六集,每集三十分鐘。很短小的日劇,看過讓...
    chilly171閱讀 766評論 0 2
  • 連續兩天,吃過晚飯就開始睡,到這會就醒了。 艱難的日子總會過去,今天又是新的一天。 ...
    與姝會友閱讀 207評論 0 0
  • 姓名:徐祖德 公司:廣東思沃精密機械有限公司 230期_利他1組 272期_樂觀2組志工 【日精進打卡第154天】...
    徐祖德閱讀 104評論 0 0