README

一个基于UUID v4（随机）的库，具有新的自定义紧凑格式，对网络和数据库都更加友好。

安装

composer require dragonrun1/uuid64php

使用方法

待办事项

为什么要做这个项目？

PHP已经存在多个优秀的UUID v4（随机）库，如果只是这样，再做一个意义不大。除了UUID之外，这个库还试图解决在网页和数据库中使用它们时的某些限制。我将详细说明这个库试图克服的数据库限制。

数据库引擎限制

数据库引擎，无论是MySQL、PostgreSQL、SQLite还是任何其他数据库，都有生成ID列序列的方法。它们如何做几乎与它们自身一样多样，因为ID生成超出了现有的SQL标准，但结果通常是一样的，即你得到一个简单的自增整数序列。那么限制在哪里，它为什么会变得糟糕？两个词：自增和序列。再加上两个词：坏人。将这四个词结合起来，你们中的一些人可能已经看到了可能出现的问题。接下来，我会展示为什么将坏人与前面两个词结合起来可能会成为一个问题。

自增序列的问题

首先一个问题问你们。你们有多少次直接在互联网上的网页表单中暴露数据库表的ID？如果你们像我一样的大多数开发者，我想我们都至少做过一次，没有多想。我们可能将其设置为隐藏字段，但对于直接查看页面代码的人来说，它是显而易见的。现在让我们来思考一下自增序列，以及它可以告诉我们有关底层数据库表的哪些信息。序列的通用默认值是它们从1开始，并为表中添加的每一行增加1。通过让网站向表中添加一行并查看新行，我们可以对表中行数有一个很好的猜测，通过添加第二行，我们可以对增长速度有一个很好的猜测。这些信息有什么用？如果这个表包含用户账户，并且账户ID是他们的ID？现在他们有了一些关于在数据泄露中可以获取多少实际用户账户，或者可以攻击哪些账户的线索。假设他们只得到一个用户名列表，ID，他们应该先攻击哪些账户？我会攻击最早创建的账户，因为它们可能是管理员或测试账户，具有更大的访问权限。我确信你们可以想出很多其他简单递增序列可能会被攻击的方法，而这些方法你们可能在我指出风险之前从未想过。

自定义对UUID v4（随机）进行base 64编码。

预期的用途是在Doctrine实体中而不是使用自增ID。

UUID（通用唯一识别码）在二进制中长度为128位，大多数编程语言只能以某种字符串或整数数组格式支持它。通常，为了紧凑性，会使用二进制字符串，其中可以包含空字符。这种格式通常只有在创建UUID的函数中才会出现，因为它对程序员来说很难直观地理解。通常使用的格式是36个字符的常规格式字符串或32个字符的十六进制字符串。这两种格式都牺牲了两次或更多的内存使用，以使它们更容易处理。通过使用基64编码，相对于二进制字符串（16个字符），它增加了不到40%的内存使用（22个字符）。

总结来说，使用这种自定义基64编码格式的优点如下：

数据库兼容性 - 可以直接存储在以下字段类型中：VARCHAR、CHAR、BINARY等。
URL兼容性 - 不包含URL中需要特殊转义的任何字符。
HTML兼容性 - 在用于HTML表单或属性值时，不包含需要转义的特殊字符。HTML 5已经放宽了所有ID属性值必须以字母开头的规定。
更易于阅读 - 由于基64编码比其他格式短，大多数人发现它更容易阅读。
最佳的内存与速度权衡 - 二进制字符串占用的内存最少，但需要在URL等中使用时转换为其他格式，这可能导致不必要的服务器负载问题。常规和十六进制形式都更长，这增加了内存和服务器负载问题。自定义格式找到了最佳平衡点，即无需转换，也不会占用太多额外空间。

许可证

所有代码均采用以下任一许可证：

APACHE - Apache License，版本2.0
MIT - MIT License

任由您选择。

您可以在 LICENSE-APACHE 和 LICENSE-MIT 文件中找到许可证的副本。所有类似此README的文档均采用Creative Commons Attribution-ShareAlike 4.0 International License（CC-BY-SA）许可证。您可以在 CC-BY-SA 许可证的 LICENSE-CC-BY-SA 文件中找到副本。

dragonrun1 / uuid64php

维护者

详细信息