uuid-b64

具有Base64显示和序列化的UUID包装器

是什么？

一个围绕UUID的新类型，

• 以Base64形式显示和序列化
  • 具体来说，它是无填充的url安全的Base64变体

let known_id = Uuid::parse_str("b0c1ee86-6f46-4f1b-8d8b-7849e75dbcee").unwrap();
let as_b64 = UuidB64::from(known_id);
assert_eq!(as_b64.to_string(), "sMHuhm9GTxuNi3hJ51287g");

let parsed_b64: UuidB64 = "sMHuhm9GTxuNi3hJ51287g".parse().unwrap();
assert_eq!(parsed_b64, as_b64);

let raw_id = Uuid::new_v4();
assert_eq!(raw_id.to_string().len(), 36);
let uuidb64 = UuidB64::from(raw_id);
assert_eq!(uuidb64.to_string().len(), 22);

UuidB64::new创建v4 UUID，因为...这是我用的。我愿意听听关于为什么这是一个荒谬的决定以及我应该将new改为new_v4的论点。

为什么？

UUID很棒

• 它们有已知的大小和表示形式，这意味着它们在各种系统中都得到了很好的支持，以高效的方式表示。例如编程语言和数据库。
• V4（几乎完全随机）UUID有很好的分片属性，你可以随意分配UUID，无需协调，仍然可以保证系统之间两个项目的ID不会发生冲突。

话虽如此，UUID的标准表示形式有点烦人

• 它很长：用36个字符来表示16个字节的数据！
• 很难阅读：它只包含十六进制字符。人眼需要非常注意才能确定两个UUID是否相同。

我想就是这样。Base64是UUID更人性化的表示形式

• 它稍微短一些：原始数据大小的1.375倍（22个字符），而字符大小的2.25倍。
• 由于它是大小写敏感的，ID的形状有助于区分不同的ID。每个字符的熵也更高，因此扫描以查找差异更快。

话虽如此，这种做法也有缺点

• 如果你将其作为数据库中的UUID列存储，ID将不会像在应用程序代码中那样显示，这意味着你（A）可能需要定义一个新的数据库类型，或者B只期望通过应用程序与数据库交互。

  转换函数相当简单，这在PostgreSQL中有效（效率不高，但仅用于交互式查询，所以没关系）

  CREATE FUNCTION b64uuid(encoded TEXT) RETURNS UUID
  AS $$
      BEGIN
          RETURN ENCODE(DECODE(REPLACE(REPLACE(
              encoded, '-', '+'), '_', '/') || '==', 'base64'), 'hex')::UUID;
      END
  $$ LANGUAGE plpgsql;
  

用法

只需在任何使用Uuid的地方使用UuidB64，并使用UuidB64::from从现有的UUID创建一个。

功能

• serde通过Serde启用序列化和反序列化。
• diesel-uuid使与Diesel的UUID支持集成成为可能，这仅在PostgreSQL上进行了测试，欢迎为其他数据库提交PR。

贡献

测试

大多数测试都是标准的：使用 cargo test 或 cargo test --features serde，但如果要测试diesel集成（即 diesel-uuid 功能），则需要一个运行的postgres实例。假设您本地正在运行docker并且处于bash环境，可以使用 ./run-tests.sh 命令来执行所有测试。

许可证

根据以下之一进行许可：

• Apache License，版本 2.0，（LICENSE-APACHE 或 http://www.apache.org/licenses/LICENSE-2.0）
• MIT 许可证（LICENSE-MIT 或 http://opensource.org/licenses/MIT）

任选其一。

贡献

除非您明确说明，否则根据Apache-2.0许可证定义，您提交的任何有意包含在作品中的贡献，都应如上所述双重许可，不附加任何额外条款或条件。