服务器端Swift—构建自定义XML解码器

最新推荐文章于 2023-05-31 16:05:50 发布
最新推荐文章于 2023-05-31 16:05:50 发布
阅读量116 收藏
点赞数
文章标签： swift 面试 后端
原文链接：https://juejin.im/post/5d255cf05188255d6f33de31
版权

我们实现了一个自定义XML解码器，允许我们使用Decodable解码来自XML API的响应。

对于Swift Talk后端，我们使用订阅服务Recurly连接，该服务使用自定义XML格式。我们必须解析来自此服务的各种资源，例如订阅和帐户，并且所有这些资源都使用相同的格式。

点击此处进交流群 有技术的来闲聊 没技术的来学习

通常，每个使用XML的人都以自己的方式实现它，因此格式在构造某些值类型或它们如何表示的方式上看起来会略有不同nil。在今天的示例中，我们看到Recurly将URL表示为具有href属性的元素：

<?xml version="1.0" encoding="UTF-8"?>
<account href="https://domain.recurly.com/v2/accounts/06a5313b-7972-48a9-a0a9-3d7d741afe44">
  <adjustments href="https://domain.recurly.com/v2/accounts/06a5313b-7972-48a9-a0a9-3d7d741afe44/adjustments"/>
  <account_balance href="https://domain.recurly.com/v2/accounts/06a5313b-7972-48a9-a0a9-3d7d741afe44/balance"/>
  <billing_info href="https://domain.recurly.com/v2/accounts/06a5313b-7972-48a9-a0a9-3d7d741afe44/billing_info"/>
  <!-- ... -->
</account>
复制代码

如果我们进一步向下滚动，我们会看到一个用户名可以是nil，这由一个名为nilwith nil的值作为其值表示：

<username nil="nil"></username>
复制代码

通过将这种XML格式的细节包装在解码器中，我们可以使用单一实现来解码来自Recurly的资源 - 不仅在服务器端，而且在客户端 - 如果我们的应用程序需要与之交谈API。

如果我们只需要处理这个响应，也许手动解析它会更有效。但从长远来看，编写解码器将为我们节省大量时间，因为它将允许我们从Recurly的响应中解码任何结构。

创建XML解码器

我们从基于示例XML的结构开始。为了节省一些时间，我们只使用与XML匹配的蛇形属性名称：

struct Account: Codable {
    var state: String
    var email: String
    var company_name: String
}
复制代码

我们通过编写符合Decoder协议的类来创建解码器，然后让编译器添加协议属性和方法。就像我们上周做的那样，我们将忽略codingPath和userInfo属性，我们将它们设置为空值：

finalclass RecurlyXMLDecoder: Decoder {
    var codingPath: [CodingKey] = []
    var userInfo: [CodingUserInfoKey:Any] = [:]

    // ...
}
复制代码

我们必须实现的第一件事是提供密钥容器的方法。我们通过返回一个KeyedDecodingContainer包含符合的任何类型的值来完成此操作KeyedDecodingContainerProtocol。包装容器类型必须是CodingKey类型的通用。我们创建一个被称为KDC容器类型的结构：

final class RecurlyXMLDecoder: Decoder {
    // ...

    func container<Key>(keyedBy type: Key.Type) throws -> KeyedDecodingContainer<Key> where Key: CodingKey {
        return KeyedDecodingContainer(KDC())
    }

    struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
        // ...
    }

    // ...
}
复制代码

我们让编译器为keyed解码容器生成所需的协议存根KDC，然后我们再次忽略前两个属性：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    var codingPath: [CodingKey] = []
    var allKeys: [Key] = []

    // ...
}
复制代码

在这个带键的解码容器中，我们必须从XML开始阅读。我们将使用Foundation的一个内置类型XMLElement，它是XMLNode代表单个元素的子类。我们存储一个元素作为解码器的属性，我们还将它传递给键控解码容器，KDC：

final class RecurlyXMLDecoder: Decoder {
    // ...
    let element: XMLElement
    init(_ element: XMLElement) {
        self.element = element
    }

    func container<Key>(keyedBy type: Key.Type) throws -> KeyedDecodingContainer<Key> where Key : CodingKey {
        return KeyedDecodingContainer(KDC(element))
    }

    struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
        var codingPath: [CodingKey] = []
        var allKeys: [Key] = []

        let element: XMLElement
        init(_ element: XMLElement) {
            self.element = element
        }

        // ...
    }

    // ...
}
复制代码

我们在所有其他方法中抛出致命错误，KDC以便查看我们必须首先实现哪种方法。最后，我们可能需要实现大多数方法，但这样我们就不必一次完成所有操作。我们还在其余的方法中抛出致命的错误RecurlyXMLDecoder。

我们必须确保在生产代码中不会出现任何致命错误。这对于服务器端代码尤为重要，因为致命错误会使进程停止。所以最后，我们必须以其他方式处理错误，不会导致服务器崩溃。

为了开始我们的实现，我们尝试解码示例XML字符串并查看我们首先崩溃的位置。我们XMLDocument从XML字符串创建一个，然后将其根元素传递给我们的解码器。然后我们尝试解码一个Account结构：

struct Account: Codable {
    var state: String
    var email: String
    var company_name: String
}

let document = try XMLDocument(xmlString: xml, options: [])
let root = document.rootElement()!
let decoder = RecurlyXMLDecoder(root)
let account = try Account(from: decoder)
print(account)
复制代码

正如预期的那样，没有帐户值打印到控制台，因为我们遇到了第一个致命错误：键控解码容器的字符串解码方法中的错误。这是我们需要实现的第一件事：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func decode(_ type: String.Type, forKey key: Key) throws -> String {
        fatalError()
    }

    // ...
}
复制代码

解码字符串

为了解码字符串，我们首先尝试找到具有与给定键匹配的名称的元素的子节点。元素的子元素具有公共类型XMLNode，因此我们必须尝试将找到的子元素转换为子XMLElement类：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func decode(_ type: String.Type, forKey key: Key) throws -> String {
        let child = (element.children ?? []).first(where: { $0.name == key.stringValue }).flatMap { $0 as? XMLElement }
        // ...
    }

    // ...
}
复制代码

如果我们找不到具有正确名称和类型的孩子，我们必须抛出一个DecodingError.keyNotFound错误：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func decode(_ type: String.Type, forKey key: Key) throws -> String {
        guard let child = (element.children ?? []).first(where: { $0.name == key.stringValue }).flatMap({ $0 as? XMLElement }) else {
            throw DecodingError.keyNotFound(key, DecodingError.Context(codingPath: codingPath, debugDescription: "TODO"))
        }
        // ...
    }

    // ...
}
复制代码

除了密钥之外，错误还采用上下文参数来提供调试信息，例如编码密钥路径。但是，由于我们没有在此演示中填充此路径，因此我们无法为抛出的错误添加任何更多信息。

如果我们找到了child元素，我们返回它的字符串值。XMLNode的财产stringValue是可选的，但我们相信它永远是nil对XMLElement的子类XMLNode。所以我们强制解包它，如果我们的假设是错误的话会导致崩溃：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func decode(_ type: String.Type, forKey key: Key) throws -> String {
        guard let child = // ...
        return child.stringValue! // todo verify that it's never nil
    }

    // ...
}
复制代码

现在运行代码，我们已经成功解码Account，因为它的所有属性都是字符串：

let account = try Account(from: decoder)
print(account)

// Account(state: "active", email: "mail@floriankugler.com", company_name: "")
复制代码

解码无

作为下一步，我们要解码nil以便有可选字段Account。目前，我们将公司名称解码为空字符串，但XML将此值定义为nil：

<company_name nil="nil"></company_name>
复制代码

许将值解码为nil，我们将属性转换为可选属性：

struct Account: Codable {
    var state: String
    var email: String
    var company_name: String?
}
复制代码

现在，如果我们运行应用程序，我们会崩溃另一种我们尚未实现的方法。在我们修复此崩溃之前，我们可以通过编码密钥来提取逻辑以查找XML元素的子元素，因为我们的解码器在很多地方都需要它：

extension XMLElement {
    func child(for key: CodingKey) -> XMLElement? {
        return (children ?? []).first(where: { $0.name == key.stringValue }).flatMap({ $0 as? XMLElement })
    }
}
复制代码

这使得字符串解码方法更具可读性：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func decode(_ type: String.Type, forKey key: Key) throws -> String {
        guard let child = element.child(for: key) else {
            // ...
        }
        return child.stringValue! // todo verify that it's never nil
    }

    // ...
}
复制代码

我们使用相同的帮助器来实现下一个方法，如果可以找到给定键的子代contains，则该方法应该返回true：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func contains(_ key: Key) -> Bool {
        return element.child(for: key) != nil
    }

    // ...
}
复制代码

接下来，我们遇到致命错误decodeNil，true如果必须将给定键的子元素解释为，则应返回该错误nil。

如果我们根本找不到子元素，我们应该像以前一样抛出一个错误，并且因为这个逻辑与字符串解码方法中的逻辑相同，所以我们可以拉出另一个帮助我们的错误：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func child(for key: CodingKey) throws -> XMLElement {
        guard let child = element.child(for: key) else {
            throw DecodingError.keyNotFound(key, DecodingError.Context(codingPath: codingPath, debugDescription: "TODO"))
        }
        return child
    }

    // ...

    func decode(_ type: String.Type, forKey key: Key) throws -> String {
        let child = try self.child(for: key)
        return child.stringValue! // todo verify that it's never nil
    }

    // ...
}
复制代码

在decodeNil，我们现在只需要检查找到的子元素是否具有nil属性。如果是，我们返回true，这意味着我们正在解码一个nil值：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func decodeNil(forKey key: Key) throws -> Bool {
        let child = try self.child(for: key)
        return child.attribute(forName: "nil") != nil
    }

    // ...
}
复制代码

让这个逻辑正确起来可能会让人很困惑，所以我们真的喜欢这样一个事实：我们将它包装在一个解码器中，我们只需要一次就把它弄好。当我们实际使用解码器时，我们不再需要担心格式的细节。

现在当我们运行代码而不是空字符串时，我们正确地获取nil了公司名称属性：

let account = try Account(from: decoder)
print(account)

// Account(state: "active", email: "mail@floriankugler.com", company_name: nil)
复制代码

解码嵌套值

对于下一步，我们可以将帐户状态转换为枚举，这本身就是Codable：

struct Account: Codable {
    enum State: String, Codable {
        case active, canceled
    }
    var state: State
    var email: String
    var company_name: String?
}
复制代码

这会在另一个方法中崩溃我们的代码，即解码嵌套类型的方法：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func decode<T>(_ type: T.Type, forKey key: Key) throws -> T where T : Decodable {
        fatalError()
    }

    // ...
}
复制代码

调用此方法是因为我们必须解码一个State值，但我们在方法中知道的是我们必须解码一个通用的可解码类型T。这意味着我们可以调用初始化器T(from: decoder)，我们需要一个解码器。

许多Decoder实现在此时使用根解码器以获得最大效率，但我们将创建一个新的实现，因为它更容易，并且性能足以满足我们的用例。我们搜索名称与给定键匹配的子进程并将其传递给新的解码器：

struct KDC<Key: CodingKey>: KeyedDecodingContainerProtocol {
    // ...

    func decode<T>(_ type: T.Type, forKey key: Key) throws -> T where T : Decodable {
        let el = try child(for: key)
        let decoder = RecurlyXMLDecoder(el)
        return try T(from: decoder)
    }

    // ...
}
复制代码

这一次，我们遇到了解码器singleValueContainer方法中的致命错误。调用此方法是因为我们正在尝试解码a State，并且Decodable编译器为此枚举生成的实现要求解码器提供此类型的容器。

为了实现这个方法，我们需要返回一个SingleValueDecodingContainer我们为其创建结构的方法SVDC。就像我们使用键控解码容器一样，我们将解码器的XML元素传递给结构体，并通过在所有协议方法中抛出致命错误来满足编译器：

final class RecurlyXMLDecoder: Decoder {
    // ...

    func singleValueContainer() throws -> SingleValueDecodingContainer {
        return SVDC(element)
    }

    struct SVDC: SingleValueDecodingContainer {
        var codingPath: [CodingKey] = []
        let element: XMLElement

        init(_ element: XMLElement) {
            self.element = element
        }

        // ...
    }
}
复制代码

这构建并且我们在单值容器的字符串解码方法中崩溃。与键控容器不同，我们不必通过键查找子项，因为我们现在正在解码单个值。所以我们只返回我们给出的根元素的字符串值：

struct SVDC: SingleValueDecodingContainer {
    var codingPath: [CodingKey] = []
    let element: XMLElement

    init(_ element: XMLElement) {
        self.element = element
    }

    // ...

    func decode(_ type: String.Type) throws -> String {
        return element.stringValue! // todo check "never nil" assumption
    }

    // ...
}
复制代码

当我们运行代码时，我们得到一个成功解码的State值：

let account = try Account(from: decoder)
print(account)

// Account(state: XMLDecoder.Account.State.active, email: "mail@floriankugler.com", company_name: nil)
复制代码

接下来

今天我们将把它留在今天，但仍然存在一些挑战。首先，我们必须将XML中表示的日期解码为ISO 8601格式的字符串，而解码器Double默认尝试解码a 。

另一个挑战是数组的解码。XML实际上没有像JSON那样的数组类型 - 可以直接映射到我们的解码器。因此，我们必须找出从XML文档构造数组的另一种方法。

所以我们可以继续处理我们的解码器，直到我们不再遇到致命错误并且我们需要的每个方法都得到实现

小编这里有大量的书籍和面试资料哦（点击下载）

原文转载地址：talk.objc.io/episodes/S0…

转载于:https://juejin.im/post/5d255cf05188255d6f33de31

weixin_30662011
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
msbin:Microsoft 二进制 XML 格式的简单解码器（MC-NBFX、MC-NBFS）
06-13
Python 二进制 XML 解码器 用 Python 编写的 Microsoft 二进制 XML 格式 (MC-NBFX) 的简单解码器。 也适用于二进制 SOAP（MC-NBFS、soap+msbin1）。 基本上，这个解码器所做的就是将二进制 XML 字节转换为dictionary 。 可以用作独立脚本： ./msbin.py input_file 例子 像这样的原始输入： 0000000: 5602 0b01 7304 0b01 6106 5608 440a 1e00 V...s...a.V.D... 0000010: 8299 0a75 726e 3a4d 7954 6573 7401 560e ...urn:MyTest.V. 0000020: 4006 5265 7375 6c74 5f0a 536f 6d65 5374 @.Result_.SomeSt 00
XML最新解码器
09-19
MSXML6 解决了许多稳定性问题，尤其是在一些受资源限制的情况下。 安全性 – MSXML6 采用“默认关闭”的原则
Golang_22: Go语言 XML 编码 和 解码
谢TS的博客
05-27 696
Go 内置的 encoding/xml 包实现了一个简单的 XML 1.0 解析器，并且支持命名空间。
netty系列之:netty中常用的xml编码解码器
程序那些事
05-13 650
文章目录简介XmlFrameDecoderXmlDecoder总结 简介 在json之前，xml是最常用的数据传输格式，虽然xml的冗余数据有点多，但是xml的结构简单清晰，至今仍然运用在程序中的不同地方，对于netty来说自然也提供了对于xml数据的支持。 netty对xml的支持表现在两个方面，第一个方面是将编码过后的多个xml数据进行frame拆分，每个frame包含一个完整的xml。另一方面是将分割好的frame进行xml的语义解析。 进行frame拆分可以使用XmlFrameDecoder,进行x
XML字符串Base64解码并获取XML中的数据
qq_54571327的博客
05-31 1365
XML字符串Base64解码并获取XML中的数据
swift-WclImagePickerController自定义的图片选择器
08-15
在Swift编程环境中，开发者经常需要实现自定义的图片选择器来满足特定的用户界面和功能需求。本篇文章将深入探讨`WclImagePickerController`，这是一个专门为iOS应用设计的开源自定义图片选择器，用于替代系统默认的...
swift-自定义照片选择器基于PHAsset
08-15
本项目"swift-自定义照片选择器基于PHAsset"就是利用Apple的Photos框架（PHAsset）来创建一个自定义的照片选择器。下面将详细阐述相关知识点。 1. **PHAsset**: PHAsset是苹果Photos框架中的核心类，它代表了存储在...
如何建立主要用于存储数据的Swift的自定义服务器端api
04-04
我当前正在创建一个需要自定义Web API的应用程序，该应用程序存储以下内容：商家地址，评论，图片库，一些与Soundcloud，Spotify等的音频链接，图片以及与所述商家的独家交易。 编写完成后，我会将其部署到服务器，...
swift自定义tabbar
07-27
Swift作为Apple的官方编程语言，提供了丰富的API和工具来帮助开发者实现自定义的TabBar。本篇将深入探讨如何使用Swift来实现一个具有中间突出按钮的自定义TabBar。 首先，我们需要理解TabBar的基本结构。TabBar由一...
server服务器端Swift Web框架。-Swift开发
05-27
Vapor Vapor是Swift最常用的Web框架。 它为您的下一个网站，API或云项目提供了精美而易于使用的基础。 该存储库是框架的源代码。 竞争Vapor Vapor是Swift最常用的Web框架。 它为您的下一个网站，API或云项目提供了...
xml编码/解码类
12-12
xml生成类 编码解码类
XML解析器.exe
08-13
非常高效的XML解析器!能够精确解析到每个节点，好东西共享 大家好好用！
论文研究-基于TTCN-3的XML数据编解码器的研究 .pdf
08-15
基于TTCN-3的XML数据编解码器的研究，张云，黄小红，编码解码器是TTCN-3测试系统中不可缺少的部分，它的实现因TTCN-3数据表示意义的不同而不同。本文提出了使用TTCN-3语言表示XML数据的方法
基于 C 语言的轻量级高效 XML编解码器
06-20
将树形数据结构用于最小化DOM 模型XML 编解码器的开发。在解析XML 文本时，基于Expat 解释器将XML 字符串构造成树 状结构；编码时构造DOM 树结构，采用非递归深度优先法遍历树，将其串行化成XML 串。本编解码器解决了国际化语言关键问题，是 一个通用、高效的工业级XML 应用支撑模块
自定义 Swift Codable 编码器和解码器
weixin_34162228的博客
05-17 2640
自定义 Swift Codable 编码器和解码器 作者 Mattt 在 Swift 4 中声明了 Codable 协议的类型实现 Encoder 或 Decoder 之后， 都可以同其表示进行编解码操作。 这个功能发布之初， 只有 Foundation 框架中的 JSONEncoder / JSONDecoder / PropertyListEncoder /PropertyListDecode...
网络传输Xml字符串，用netty自定义解码器解决粘包情况
明天，争取的博客
04-19 1736
网络传输Xml字符串，用netty自定义解码器解决粘包情况 package com.example.demo.service; import io.netty.buffer.ByteBuf; import io.netty.buffer.ByteBufAllocator; import io.netty.channel.ChannelHandlerContext; import io....
idea 枚举快速_快速可枚举的枚举
weixin_26735419的博客
08-14 4133
idea 枚举快速I had a very basic knowledge of Codable which was limited to how to convert JSON data into primitive types such as String, Int, Bool, etc. or how to work with nested JSON objects and Arrays. ...
xml的dom解码方式
weixin_45164550的博客
10-11 311
DOM模式解析XML，是把整个XML文档当成一个对象来处理，会先把整个文档读入到内存里。是基于树的结构，通常需要加载整文档和构造DOM树，然后才能开始工作。 优点： a、由于整棵树在内存中，因此可以对xml文档随机访问 b、可以对xml文档进行修改操作 c、较sax，dom使用也更简单。 缺点： a、整个文档必须一次性解析完 b、由于整个文档都需要载入内存，对于大文档成本高 例子： public ...
SwiftUI自定义布局
最新发布
08-24
SwiftUI提供了多种方法来实现自定义布局。其中，可以使用HStack、VStack、ZStack等布局容器来组合和排列视图元素，实现各种复杂界面。 另外，SwiftUI还提供了对齐指南来帮助文本对齐，如.leading、.trailing、.top...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值