Pembuat UUID v7 (Terurut Waktu)

Buat identifier UUIDv7 terurut waktu (RFC 9562) atau v4 acak klasik langsung dengan Web Crypto. Semuanya berjalan di browser Anda.

Identifier dibuat secara lokal dengan Web Crypto. Tidak ada yang meninggalkan perangkat Anda.

Keluaran

Stempel waktu di bawah tiap v7 didekode dari enam byte pertama — Salin mengambil UUID-nya saja.

Cara kerja

UUIDv7 didefinisikan oleh RFC 9562 dan halaman ini merakitnya secara manual dari crypto.getRandomValues — tanpa pustaka. Yang memisahnya dari v4 adalah susunan byte-nya: stempel waktu jam sistem diletakkan di depan identifier, sehingga urutan alfabetis string menjadi urutan pembuatan. Pengalih versi juga memberi Anda v4 acak klasik sebagai pembanding, dan stempel waktu di samping tiap v7 didekode kembali dari enam byte pertama.

Tata letak byte v7
Byte 0–5 menyimpan waktu Unix dalam milidetik sebagai bilangan bulat big-endian 48 bit — tetap urut benar sampai tahun 10889. Byte 6 dibuka field versi 4 bit (0x7) lalu 12 bit acak bernama rand_a. Byte 7–15 membawa sisanya: byte 8 dimulai dengan dua bit varian (10) dan 62 bit sisanya (rand_b) acak. Total keacakan dalam satu milidetik: 74 bit. Ditulis dalam kelompok heksadesimal 8-4-4-4-12 yang biasa, v7 terlihat persis seperti UUID lain.
Urut leksikografis berarti urut waktu
Perbandingan string membaca dari kiri ke kanan, dan 48 bit paling kiri adalah jam, jadi mengurutkan v7 secara alfabetis mengurutkannya secara kronologis. Pada primary key B-tree, insert selalu jatuh ke daun paling kanan: halaman terisi berurutan alih-alih tiap tulisan menyentuh halaman acak, sehingga indeks tetap ringkas dan cache tetap hangat. Kunci v4 mengacak pola akses itu; kunci v7 mengalir melewatinya.
Di mana v4 tetap unggul
v4 membawa 122 bit acak dan tidak membocorkan kapan atau di mana ID dibuat. Untuk identifier publik, URL yang tak tertebak, dan token keamanan, awalan waktu milik v7 (sebuah kebocoran informasi, plus ekor acak yang lebih kecil) menganjurkan format lama. Pakai masing-masing sesuai desainnya: v7 untuk kunci terurut, v4 untuk referensi kabur.

Pertanyaan yang sering diajukan

Kapan sebaiknya memakai v7, bukan v4?

Pakai v7 ketika ID hidup di indeks terurut — primary key Postgres, tabel B-tree atau LSM-tree seperti InnoDB MySQL, RocksDB, atau sort key DynamoDB. Karena v7 terurut secara leksikografis sama dengan urutan pembuatannya, baris baru menempel di ujung indeks alih-alih menyebar tuliskan ke mana-mana. Pakai v4 ketika nilainya harus tak tertebak dan waktunya tidak boleh bocor: identifier publik untuk URL dan token keamanan tetap lebih cocok memakai ekor acak v4 yang lebih besar.

Mengapa UUID v7 terurut berdasarkan waktu?

48 bit pertama tiap v7 adalah waktu pembuatan — milidetik sejak epoch Unix — ditulis dengan byte terpenting lebih dulu. Perbandingan string membaca dari kiri, jadi stempel waktu mendominasi: baris '0198…' selalu mendahului '0199…', sehingga urutan leksikografis sama dengan urutan kronologis. Bit acak setelahnya hanya menentukan urutan UUID yang dibuat pada milidetik yang sama.

Apakah UUID v7 tetap aman dari tabrakan?

Ya, di dalam milidetik yang sama: setelah 48 bit waktu dan 6 bit versi serta varian, tersisa 74 bit acak — sekitar 1,9 × 10^22 kemungkinan per milidetik pembuatan — jauh di atas laju satu mesin. Jika Anda butuh jaminan monotoniatis ketat pada milidetik yang sama, gunakan pustaka server yang menerapkan skema penghitung monotonik opsional RFC 9562; alat browser ini mengandalkan bit acaknya.

Apakah ID yang dihasilkan punya stempel waktu berbeda?

Tiap UUID distempel dengan jam saat ia dibuat, sehingga satu batch hasil sekali klik sering berbagi milidetik yang sama — loop browser lebih cepat dari detak jam. Itu normal dan tidak berbahaya: stempel yang tampil di samping tiap ID nyata, dan ekor acaknya menjaga setiap ID tetap unik.

Apakah ada yang diunggah ke server?

Tidak. Identifier dirakit di browser Anda dari API Web Crypto dan jam sistem. Tidak ada yang dikirim, disimpan, atau dicatat, dan batch hilang saat tab ditutup.