一、前言

• 大多数现代应用程序的共同点是，它们需要对各种形式的数据进行编码或解码。无论是通过网络下载的 Json 数据，还是存储在本地的模型的某种形式的序列化表示形式，对于几乎无任何 Swift 代码库而言，能够可靠地编码和解码不同的数据都是必不可少的。
• 这就是为什么 Swift 的 Codable API 能成为 Swift 4.0 的新功能一部分时，具有如此重要的重要原因。从那时起，它已发展成为一种标准的、健壮的机制，可以在 Apple 的各种平台中使用编码和解码包括服务器端 Swift。
• Codable 之所以如此出色，是因为它与 Swift 工具链紧密集成，从而使编译器可以自动合成大量编码和解码各种值所需的代码。但是，有时需要自定义序列化时值的表示方式，那么该如何调整 Codable 实现来做到这一点呢？

二、Codable 自定义解析 Json

① 修改 Key

• 可以通过修改用作序列化表示形式一部分的键来自定义类型的编码和解码方式。假设我们正在开发的一个核心数据模型如下所示：

struct Article: Codable {
    var url: URL
    var title: String
    var body: String
}

• 我们的模型当前使用完全自动合成的 Codable 实现，这意味着其所有序列化键都将匹配其属性的名称。但是，将从中解码 Article 值的数据（例如，从服务器下载的 Json）可能会使用略有不同的命名约定，从而导致默认解码失败。幸运的是，这一问题很容易解决，要自定义 Codable 在解码（或编码）的 Article 类型的实例时将使用哪些键，要做的就是在其中定义一个 CodingKeys 枚举，并为与希望自定义的键匹配的大小写分配自定义原始值。如下所示：

extension Article {
    enum CodingKeys: String, CodingKey {
        case url = "source_link"
        case title = "content_name"
        case body
    }
}

• 通过上述操作，可以继续利用编译器生成的默认实现进行实际的编码工作，同时仍能更改将用于序列化的键的名称。虽然上面的技术非常适合当我们想要使用完全自定义的键名时，但是如果只希望 Codable 使用属性名的 snake_case 版本（例如，将 backgroundColor 转换为 background_color），那么可以简单地更改 Json 解码器的 keyDecodingStrategy：

var decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase

• 以上两个 API 的优点在于，它们能够解决 Swift 模型与用于表示它们的数据之间的不匹配问题，而无需修改属性名称。

② 忽略 Key

• 能够自定义编码键的名称确实很有用，但有时我们可能希望完全忽略某些键。例如，现在正在开发一个记笔记应用程序，并且使用户能够将各种笔记分组在一起以形成一个可以包括本地草稿的 NoteCollection：

struct NoteCollection: Codable {
    var name: String
    var notes: [Note]
    var localDrafts = [Note]()
}

• 但是，虽然将 localDrafts 纳入 NoteCollection 模型确实很方便，但可以说，我们不希望在序列化或反序列化此类集合时包含这些草稿。这样做的原因可能是每次启动应用程序时为用户提供整洁的状态，或者是因为服务器不支持草稿。幸运的是，这也可以轻松完成，而不必更改 NoteCollection 的实际 Codable 实现，如果像以前一样定义一个 CodingKeys 枚举，而只是省略 localDrafts，那么在对 NoteCollection 值进行编码或解码时，将不会考虑该属性：

extension NoteCollection {
    enum CodingKeys: CodingKey {
        case name
        case notes
    }
}

• 为了使以上功能正常运行，要省略的属性必须具有默认值，在这种情况下，localDrafts 已具有默认值。

③ 创建匹配的结构

• 到目前为止，只是在调整类型的编码键，尽管这样做通常可以受益匪浅，但有时需要对 Codable 自定义进行进一步的调整。假设正在构建一个包含货币换算功能的应用，并且正在将给定货币的当前汇率下载为 Json 数据，如下所示：

{
    "currency": "PLN",
    "rates": {
        "USD": 3.76,
        "EUR": 4.24,
        "SEK": 0.41
    }
}

• 然后，在 Swift 代码中，想要将此类 Json 响应转换为 CurrencyConversion 实例，每个实例都包含一个 ExchangeRate 条目数组，每个币种对应一个：

struct CurrencyConversion {
    var currency: Currency
    var exchangeRates: [ExchangeRate]
}

struct ExchangeRate {
    let currency: Currency
    let rate: Double
}

• 但是，如果仅仅只是使以上两个模型都符合 Codable，将再次导致 Swift 代码与要解码的 Json 数据不匹配。但是这次，不只是关键字名称的问题，结构上有根本的不同。当然，可以修改 Swift 模型的结构，使其与 Json 数据的结构完全匹配，但这并不总是可行的。尽管拥有正确的序列化代码很重要，但是拥有适合实际代码库的模型结构也同样重要。
• 相反，创建一个新的专用类型，它将在 Json 数据中使用的格式与 Swift 代码的结构体之间架起一座桥梁。在这种类型中，我们将能够封装将 Json 汇率字典转换为一系列 ExchangeRate 模型所需的所有逻辑，如下所示：

private extension ExchangeRate {
    struct List: Decodable {
        let values: [ExchangeRate]

        init(from decoder: Decoder) throws {
            let container = try decoder.singleValueContainer()
            let dictionary = try container.decode([String : Double].self)

            values = dictionary.map { key, value in
                ExchangeRate(currency: Currency(key), rate: value)
            }
        }
    }
}

• 使用上述类型，现在可以定义一个私有属性，该名称与用于其数据的 Json 密钥相匹配，并使 exchangeRates 属性仅充当该私有属性的面向公众的代理：

struct CurrencyConversion: Decodable {
    var currency: Currency
    var exchangeRates: [ExchangeRate] {
        return rates.values
    }
    
    private var rates: ExchangeRate.List
}

• 上面的方法起作用的原因是，在对值进行编码或解码时，永远不会考虑计算属性。当想使我们的 Swift 代码与使用非常不同的结构的 Json API 兼容时，上述技术可能是一个很好的工具，且无需完全从头实现 Codable。

④ 转换值

• 在解码时，尤其是在使用无法控制的外部 Json API 进行解码时，一个非常常见的问题是，以与 Swift 的严格类型系统不兼容的方式对类型进行编码。例如，要解码的 Json 数据可能使用字符串来表示整数或其他类型的数字。
• 来看看一种可以处理这些值的方法，再次以一种自包含的方式，它不需要我们编写完全自定义的 Codable 实现。本质上想要做的是将字符串值转换为另一种类型，以 Int 为例，将从定义一个协议开始，该协议可以将任何类型都标记为 StringRepresentable，这意味着可以将其转换为字符串表示形式，也可以将其从字符串表示形式转换为需要的类型：

protocol StringRepresentable: CustomStringConvertible {
    init?(_ string: String)
}

extension Int: StringRepresentable {}

• 接下来，创建另一个专用类型，这是为任何可以由字符串支持的值，并让它包含解码和编码一个值到字符串和从字符串编码所需的所有代码：

struct StringBacked<Value: StringRepresentable>: Codable {
    var value: Value
    
    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let string = try container.decode(String.self)
        
        guard let value = Value(string) else {
            throw DecodingError.dataCorruptedError(
                in: container,
                debugDescription: "Failed to convert an instance of \(Value.self) from '\(string)'"
            )
        }
        
        self.value = value
    }
    
    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        try container.encode(value.description)
    }
}

• 就像以前为兼容 Json 的基础存储创建私有属性的方式一样，现在可以对编码后由字符串后端的任何属性执行相同的操作，同时仍将数据适当地公开给其它 Swift 代码类型，这是一个针对视频类型的 numberOfLikes 属性执行此操作的示例：

struct Video: Codable {
    var title: String
    var description: String
    var url: URL
    var thumbnailImageURL: URL
    
    var numberOfLikes: Int {
        get { return likes.value }
        set { likes.value = newValue }
    }
    
    private var likes: StringBacked<Int>
}

• 在必须手动为属性定义 setter 和 getter 的复杂性与必须回退到完全自定义的 Codable 实现的复杂性之间，这里肯定有一个折中，但是对于上述 Video 结构体这样的类型，它在其中仅具有一个属性需要自定义，使用私有支持属性可能是一个不错的选择。

三、Codable 将任意类型解析为想要的类型

① 常规解析

• 默认情况下，使用 Swift 内置的 Codable API 解析 Json 时，属性类型需要和 Json 中的类型保持一致，否则就会解析失败。
• 例如，现有如下 Json：

{
    "name":"ydw",
    "age":18
}

• 开发中常用的模型如下：

struct User: Codable {
    var name: String
    var age: Int
}

• 这个时候，正常解析则没有任何问题，但是：
• • 当出现服务器将 age 中的 18 采用 String 方式 “18” 返回时，则无法解析，这是非常难遇见的情况；
• • 另一种常见的是返回 “18.1”, 这是一个 Double 类型，这时候一样无法成功解析。
• 在使用 OC 的时候，常用的方法将其解析为 NSString 类型，使用的时候再进行转换，可是当使用 Swift 的 Codabel 时，就不能直接做到这样。

② 如果服务器只会以 String 方式返回 Age，同时能确认里面是 Int 还是 Double

• 可以使用上文中的“值转换”来完成：

protocol StringRepresentable: CustomStringConvertible {
    init?(_ string: String)
}

extension Int: StringRepresentable {}

struct StringBacked<Value: StringRepresentable>: Codable {
    var value: Value
    
    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let string = try container.decode(String.self)
        
        guard let value = Value(string) else {
            throw DecodingError.dataCorruptedError(
                in: container,
                debugDescription: "Failed to convert an instance of \(Value.self) from '\(string)'"
            )
        }
        
        self.value = value
    }
    
    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        try container.encode(value.description)
    }
}

• 这个时候，模型如下：

{
    "name":"zhy",
    "age":"18"
}

struct User: Codable {
    var name: String
    var ageInt: Int {
        get { return age.value }
        set { age.value = newValue}
    }
    private var age: StringBacked<Int>
}

③ 不能确认是什么类型

• 第一种处理方法会改变原有数据结构，虽然对于直接重写 User 的解析过程来说，拥有更多的通用性，但是遇到其它情况则束手无策。第二种方法同时也不会采用重写模型自身的解析过程来实现，那样子不具备通用性，太麻烦，每次遇到都需要来一遍。
• 参照第一种方法，先写一个将任意类型转换成 String? 的方法：

//  不确定服务器返回什么类型，都转换为 String 然后保证正常解析
//  当前支持 Double Int String
//  其他类型会解析成 nil
//
/// 将 String Int Double 解析为 String? 的包装器
@propertyWrapper public struct YDWString: Codable {
    public var wrappedValue: String?
    public init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        var string: String?
        do {
            string = try container.decode(String.self)
        } catch {
            do {
                try string = String(try container.decode(Int.self))
            } catch {
                do {
                    try string = String(try container.decode(Double.self))
                } catch {
                    // 如果不想要 String? 可以在此处给 string 赋值  = “”
                    string = nil
                }
            }
        }
        wrappedValue = string
    }
}

• 此时 User 写成：

struct User: Codable {
    var name: String
    @YDWString public var age: String?
}

• 同理，可以写一个 YDWInt，来将任意类型转换为 Int，如果确实无法转换，可以控制其为 nil 或者直接等于 0，这样就可以保证不管怎么样，解析不会失败。此时 User 写成：

struct User: Codable {
    var name: String
    @YDWInt public var age: Int
}

• 看起来这个地方影响很小，只有 User 解析失败没什么，当遇到整个页面都是用一个 Json 返回时，不管是哪个局部出现问题，都会导致真个页面解析失败，所以还是要做好兼容操作最好。