iOS学习资料二之Swift 4 JSON 解析指南

基础

如果你的 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 类型实现。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,585评论 18 139
  • Apple 在 Swift 4 的 Foundation 的模块中添加了对 JSON 解析的原生支持。 基础 如果...
    Fosen波波阅读 1,153评论 0 5
  • title: "Swift 中枚举高级用法及实践"date: 2015-11-20tags: [APPVENTUR...
    guoshengboy阅读 2,553评论 0 2
  • 2014年的苹果全球开发者大会(WWDC),当Craig Federighi向全世界宣布“We have new ...
    yeshenlong520阅读 2,253评论 0 9
  • 2016年的最后一天,一如既往毫无悬念的加了个班。年年岁岁花相似,岁岁年年人不同。陪我一起吃守年饭的人跟去年的又...
    恒痴阅读 124评论 0 1