spec README

The project's README from github.com/ulid/spec. As one markdown file: README.md.



ulid


Universally Unique Lexicographically Sortable Identifier

UUID can be suboptimal for many use-cases because:

Instead, herein is proposed ULID:

ulid() // 01ARZ3NDEKTSV4RRFFQ69G5FAV

Implementations in other languages

From ourselves and the community!

Language Author Binary Implementation
C++ suyash ✓
C# mcb2001
Clojure theikkila
Objective-C ricardopereira
Crystal SuperPaintman
Dart isoos ✓
Dart GuepardoApps
Delphi matinusso
D enckse
D (dub) extrawurst
Erlang savonarola
Elixir Homepolish ✓
Elixir merongivian
Elixir omisego ✓
Elixir (Ecto) dcuddeback ✓
F# lucasschejtman
Factor Alexander Ilin ✓
Go oklog ✓
Haskell steven777400 ✓
Java huxi ✓
Java azam
Java Lewiscowles1986
JavaScript ulid
JavaScript aarondcohen ✓
Julia ararslan
Kotlin GuepardoApps
Lua Tieske
.NET RobThree ✓
.NET fvilers
Nim adelq
OCaml stripedpajamas
Perl 5 bk ✓
PHP Lewiscowles1986
PHP robinvdvleuten
PowerShell PetterBomban
Python mdipierro
Python ahawker ✓
Python mdomke ✓
R hrbrmstr
Ruby rafaelsales
Rust mmacedoeu ✓
Rust dylanhart ✓
Scala petitviolet
SQL-Microsoft rmalayter ✓
Swift simonwhitehouse
Swift yaslab ✓
Tcl dbohdan

Specification

Below is the current specification of ULID as implemented in ulid/javascript.

Note: the binary format has not been implemented in JavaScript as of yet.

 01AN4Z07BY      79KA1307SR9X4MV3

|----------|    |----------------|
 Timestamp          Randomness
   48bits             80bits

Components

Timestamp

Randomness

Sorting

The left-most character must be sorted first, and the right-most character sorted last (lexical order). The default ASCII character set must be used. Within the same millisecond, sort order is not guaranteed

Canonical String Representation

ttttttttttrrrrrrrrrrrrrrrr

where
t is Timestamp (10 characters)
r is Randomness (16 characters)

Encoding

Crockford's Base32 is used as shown. This alphabet excludes the letters I, L, O, and U to avoid confusion and abuse.

0123456789ABCDEFGHJKMNPQRSTVWXYZ

Monotonicity

When generating a ULID within the same millisecond, we can provide some guarantees regarding sort order. Namely, if the same millisecond is detected, the random component is incremented by 1 bit in the least significant bit position (with carrying). For example:

import { monotonicFactory } from 'ulid'

const ulid = monotonicFactory()

// Assume that these calls occur within the same millisecond
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVRZ
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVS0

If, in the extremely unlikely event that, you manage to generate more than 280 ULIDs within the same millisecond, or cause the random component to overflow with less, the generation will fail.

import { monotonicFactory } from 'ulid'

const ulid = monotonicFactory()

// Assume that these calls occur within the same millisecond
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVRY
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVRZ
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVS0
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVS1
...
ulid() // 01BX5ZZKBKZZZZZZZZZZZZZZZX
ulid() // 01BX5ZZKBKZZZZZZZZZZZZZZZY
ulid() // 01BX5ZZKBKZZZZZZZZZZZZZZZZ
ulid() // throw new Error()!

Overflow Errors when Parsing Base32 Strings

Technically, a 26-character Base32 encoded string can contain 130 bits of information, whereas a ULID must only contain 128 bits. Therefore, the largest valid ULID encoded in Base32 is 7ZZZZZZZZZZZZZZZZZZZZZZZZZ, which corresponds to an epoch time of 281474976710655 or 2 ^ 48 - 1.

Any attempt to decode or encode a ULID larger than this should be rejected by all implementations, to prevent overflow bugs.

Binary Layout and Byte Order

The components are encoded as 16 octets. Each component is encoded with the Most Significant Byte first (network byte order).

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      32_bit_uint_time_high                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     16_bit_uint_time_low      |       16_bit_uint_random      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       32_bit_uint_random                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       32_bit_uint_random                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Prior Art

Partly inspired by:

spec (ulid/spec)

Searching Database…

10.8K ·GitHub
这是什么?这是 ULID(Universally Unique Lexicographically Sortable Identifier,通用唯一且按字典序可排序的标识符)的权威规范。ULID 是一种 128 位标识符格式,被设计为可排序、URL 安全的 UUID 替代方案。
这是代码库还是只是一份规范?它只是一份规范文档,本身不是可运行的库。这个仓库定义了格式,并列出数十种语言的社区实现,由它们真正生成和解析 ULID。
我到底怎么在项目里生成 ULID?从 README 的表格里为你的语言挑一个现成的实现(Go、JavaScript、Python、Java、Rust 等)并安装那个包;这个仓库本身没有任何可运行的代码。
如果同一毫秒内生成了太多 ULID 会怎样?如果同一毫秒内生成了超过 2^80 个 ULID,随机部分就会溢出,按规范此时生成必须失败。
为什么我要用 ULID 而不是 UUID?它适合想要可排序、按时间排列的唯一 ID,又不想接受 UUID 缺点(比如要依赖稳定的 MAC 地址,或纯随机性导致索引碎片化)的开发者。
为什么做数据库主键时 ULID 比 UUID 更好?ULID 先编码时间戳,因此 ID 按字典序排序就等于按时间先后排序,避免了 UUID v4 因随机插入造成的索引碎片化。
ULID 的结构是怎样的?它把 48 位毫秒级时间戳和 80 位随机数打包进总共 128 位,标准形式表示为 26 个字符的字符串。
两个 ULID 在同一毫秒内生成会怎样?实现必须在检测到同一毫秒重复时把随机部分加 1(含进位),以保证单调递增的顺序。
ULID 用什么字符集编码?Crockford Base32,它去掉了 I、L、O、U 四个字母以避免混淆,且不区分大小写、URL 安全。
What are similar projects?rfcs, toml, proposals, fantasy-land, agents.md, design, spec, JavaScript
Creator
ulid
Size
0.1 MB
Stars
10.8K
Updated
CommitMay 23
Age
8y
Commits · 90 Days