Base64 Url Safe Serde 包装器

帮助内联反序列化 base64 数据类型的包装器。

lib.rs:

为 Vec<u8> 提供包装器，以便 Serde 能够将其序列化和反序列化为 URL 安全、非填充的 Base64（根据 RFC 4648 §5）。

序列化行为

• Base64UrlSafeData 总是序列化为 URL 安全、非填充的 Base64。

• HumanBinaryData 只有在使用 可读格式 时才序列化为 URL 安全、非填充的 Base64。

  否则，它将序列化为类似 "bytes" 的类型（如 serde_bytes）。

  此功能是 base64urlsafe v0.1.4 中引入的。

相比之下，Serde 的默认行为是将 Vec<u8> 序列化为一系列整数。这对许多格式来说是一个问题

• serde_cbor 将其编码为一个 array，而不是一个 bytes。对于大于 0x1F 的值，它使用 zig-zag 编码的整数，假设值的分布均匀，平均每个字节的长度约为 1.88 字节。

• serde_json 将其编码为一个 Array<Number>，没有空格时平均每个字节的长度为 3.55 字节。

使用 Base64 编码平均每个字节的长度为 1.33 字节，并且大多数格式几乎以原样传递字符串。

反序列化行为

两种类型都支持反序列化多种格式，前提是格式是自描述的（即：[实现 deserialize_any](https://serde.rs/impl-deserialize.html)）。

• 字节类型以原样传递（v0.1.4 新增）。

  HumanBinaryData 产生非人类可读格式。[HumanBinaryData](https://docs.rs/base64urlsafedata/latest/base64urlsafedata/?search=HumanBinaryData)。

• 整数序列以原样传递。

  Serde 的默认 Vec<u8> 序列化器为许多格式生成此内容。

• 字符串根据 [RFC 4648 §5 (URL-safe)](https://datatracker.ietf.org/doc/html/rfc4648#section-5) 或 [RFC 4648 §4 (标准)](https://datatracker.ietf.org/doc/html/rfc4648#section-4) 进行 Base64 解码，可选填充。

  Base64UrlSafeData 为所有格式生成此内容，而 [HumanBinaryData](https://docs.rs/serde/latest/serde/trait.Serializer.html#method.is_human_readable) 为人类可读格式生成此内容。这也应该与其他许多序列化器兼容。

从 Base64UrlSafeData 迁移到 HumanBinaryData

Base64UrlSafeData 总是使用 Base64 编码，这对于许多二进制格式来说并不理想。因此，如果您使用二进制格式，迁移到 HumanBinaryData 是一个好主意。

但是，在将任何内容切换到 HumanBinaryData 之前，您需要确保所有使用 Base64UrlSafeData 的读取器都在 base64urlsafedata v0.1.4 或更高版本上。否则，它们将无法读取新格式中的任何数据！

一旦所有迁移完成，您就可以开始以新格式进行写入。缓慢推出更改是一个好主意，以防您发现遗漏了某些内容。

替代方案

• serde_bytes，它仅针对非人类可读格式实现 Vec<u8> 的有效编码。[serde_bytes](https://docs.rs/serde_bytes)。