前言
Apple 在 Swift 4.0 中作了很多的改進，其中我個人最喜歡的就是 Codable 協議的出現。它讓 Swift 自帶了 JSON 、 XML 結構化數據和 Model 的映射和轉換能力。
Codable 最常見的使用場景就是：APP 發起網絡請求，然后我們將服務端響應的 JSON 數據轉換為對應的 Model 實體。由于服務端的編程規范可能與客戶端存在差異， Codable 默認數據轉換實現可能不再適用。例如，服務端可能使用的蛇形命名方式而客戶端使用的是駝峰。此時我們就需要在客戶端自己動手實現映射關系。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
struct Mac: Codable { var name: String var screenSize: Int var cpuCount: Int}let jsonString = """[ { "name": "MacBook Pro", "screen_size": 15, "cpu_count": 4 }, { "name": "iMac Pro", "screen_size": 27, "cpu_count": 18 }]"""let jsonData = Data(jsonString.utf8)let decoder = JSONDecoder()do { let macs = try decoder.decode([Mac].self, from: jsonData) print(macs)} catch { print(error.localizedDescription)} |
上訴代碼并不能完成理想的解碼操作，因為 Codable 的默認實現無法將蛇形變量名映射到對應的駝峰屬性上。所以在 Swift 4.0 中我們需要對 Mac 進行部分改造：
|
1
2
3
4
5
6
7
8
9
10
11
|
struct Mac: Codable { var name: String var screenSize: Int var cpuCount: Int enum CodingKeys : String, CodingKey { case name case screenSize = "screen_size" case cpuCount = "cpu_count" }} |
好在 Swift 4.1 對此作出了改進。現在我們可以通過設置 JSONDecoder 的 keyDecodingStrategy 就能實現不同編程規范之間解碼操作了。與之對應，JSONEncoder 也有一個 keyEncodingStrategy 屬性用于不同編程規范之間的編碼操作。所以上訴代碼可以簡化為：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
struct Mac: Codable { var name: String var screenSize: Int var cpuCount: Int}let jsonString = """[ { "name": "MacBook Pro", "screen_size": 15, "cpu_count": 4 }, { "name": "iMac Pro", "screen_size": 27, "cpu_count": 18 }]"""let jsonData = Data(jsonString.utf8)let decoder = JSONDecoder()decoder.keyDecodingStrategy = .convertFromSnakeCasedo { let macs = try decoder.decode([Mac].self, from: jsonData) print(macs)} catch { print(error.localizedDescription)} |
如果你想進行反向轉換操作的話，代碼也非常簡單：
|
1
2
3
|
let encoder = JSONEncoder()encoder.keyEncodingStrategy = .convertToSnakeCaselet encoded = try encoder.encode(macs) |
當然，我們還可以對轉換策略進行自定義實現以其實現一些特定需求。具體的使用方式可以參照代碼
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。
原文鏈接：https://bignerdcoding.com/archives/61.html
