"使用 Codable 将空字符串解码为 nil"

Question

normal case:

{
    "maintenance": true
}

{
    "maintenance": false
}

Answer 1

You can try

struct Root: Codable {
    var maintenance: Bool? 
    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self) 
        do {
            self.maintenance = try container.decode(Bool.self, forKey: .maintenance) 
        }
        catch { 
        } 
    }
}

Answer 2

In most cases, I'd probably use SeaSpell or Sh_Khan's solutions. Bool?<\/code> is usually not the right type, but in this case it seems precisely what you mean (you seem to want to keep track of whether the value was set or not, rather than defaulting to something). But those approaches do require a custom decoder for the whole type which might be inconvenient. Another approach would be to define a new type just for this 3-way value:

enum Maintenance {
    case `true`, `false`, unset
}

Answer 3

What you need is to try to decode your Bool, catch the error, try to decode a string and check if it is an empty string otherwise throw the error. This will make sure you don't discard any decoding error even if it is a string but not empty:

---

struct Demo: Codable {
    var maintenance: Bool?
}

---

struct Root: Codable {
    var maintenance: Bool?
    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        do {
            maintenance = try container.decode(Bool.self, forKey: .maintenance)
        } catch {
            guard try container.decode(String.self, forKey: .maintenance) == "" else {
                throw error
            }
            maintenance = nil
        }
    }
}

---

Playground testing:

let json1 = """
{
    "maintenance": true
}
"""
let json2 = """
{
    "maintenance": false
}
"""
let json3 = """
{
    "maintenance": ""
}
"""
let json4 = """
{
    "maintenance": "false"
}
"""

---

do {
    let root1 = try JSONDecoder().decode(Root.self, from: Data(json1.utf8))
    print("root1", root1)
} catch {
    print(error)
}

do {
    let root2 = try JSONDecoder().decode(Root.self, from: Data(json2.utf8))
    print("root2", root2)
} catch {
    print(error)
}

do {
    let root3 = try JSONDecoder().decode(Root.self, from: Data(json3.utf8))
    print("root3", root3)
} catch {
    print(error)
}

do {
    let root4 = try JSONDecoder().decode(Root.self, from: Data(json4.utf8))
    print("root4", root4)
} catch {
    print(error)
}

---

This will print

root1 Root(maintenance: Optional(true))
root2 Root(maintenance: Optional(false))
root3 Root(maintenance: nil)
typeMismatch(Swift.Bool, Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "maintenance", intValue: nil)], debugDescription: "Expected to decode Bool but found a string/data instead.", underlyingError: nil))

Answer 4

You really only have a couple of decent options that I know of.

1. do codable init yourself and loose the free one.

    struct Root: Codable { var maintenance: Bool? init(from decoder: Decoder) throws { let container = try decoder.container(keyedBy: CodingKeys.self) let value = (try? container.decode(Bool.self, forKey: .maintenance) ?? "") self.maintenance = (value.isEmpty() || value == "false" ) ? nil : true } }

For obvious reasons this may not be ideal, especially if you have a lot of other variables to decode. The other option is to use a getter and add a variable to store the string optional.

2. Calculated var

    private var _maintenance: String? var maintenance: Bool { get { ((_maintenance ?? "").isEmpty || _maintenance == "false") ? false : true } }

This solution is more ideal because you only need to change coding keys and add a var.

Answer 5

Bool? is a very bad idea unless you know exactly what you are doing, because you have three possible values: true, false and nil.

You can't use it directly in an if statement. You can compare b == true, b == false or b == nil and I expect that b == false will not produce the result you expect.

You want to use a three-value type for two possible values, which is asking for trouble.

Answer 6

I'd get the API changed because that's just bad design to have a field with two different types. It'd be much more sensible to have it as something like