Generator UUID

Buat UUID v4 acak atau UUID v7 berurutan waktu secara instan, atau hingga 10.000 sekaligus. Ini juga generator GUID online: GUID baru adalah jenis nilai 128 bit yang sama. Tempel UUID apa pun untuk mendekode versi, waktu pembuatan, dan setiap field-nya.

RFC 9562 · crypto.getRandomValues · dibuat dan dibaca di browser Anda, tidak ada yang dikirim

Digit berwarna adalah versinya: digit pertama grup ketiga di setiap UUID.

v4 · Acak36 karakter · 122 bit acak
xxxxxxxx-xxxx-4xxx-Nxxx-xxxxxxxxxxxx
Anatomi · RFC 9562 §5.4128 bit · 32 digit hex · 36 karakter
Arahkan kursor atau ketuk sebuah field untuk membacanya

Dibuat dan dibaca di browser Anda dengan crypto.getRandomValues; tidak ada yang dikirim.

Format

Apa itu UUID, dan apa kepanjangannya?

UUID adalah singkatan dari Universally Unique Identifier: label 128 bit yang bisa dibuat komputer mana pun secara mandiri, dengan harapan tidak ada komputer lain yang membuat label yang sama. UUID ditulis sebagai 32 digit heksadesimal dalam lima grup, seperti 919108f7-52d1-4320-9bac-f847db4148a8.

Formatnya didefinisikan oleh RFC 9562 (Mei 2024), yang menggantikan RFC 4122 dan menambahkan versi 6, 7, dan 8. Tidak ada registri pusat yang membagikan UUID: keunikannya berasal dari keacakan, dari timestamp, atau dari hash sebuah nama, tergantung versinya.

Database memakainya sebagai primary key, API sebagai ID request dan objek, sistem operasi untuk disk, partisi, dan komponen software. GUID (Globally Unique Identifier) adalah sebutan Microsoft untuk hal yang sama.

Satu nilai, empat ukuranRFC 9562 §4

UniversallyUniqueIDentifier

  1. 128 bit
  2. 16 byte
  3. 32 digit hex
  4. 36 karakter beserta tanda hubung919108f7-52d1-4320-9bac-f847db4148a8

GUIDSebutan Microsoft untuk nilai yang sama

Contoh versi 4 dari RFC 9562 dihitung dengan empat cara. Bentuk teksnya menambahkan empat tanda hubung ke 32 digit hex: 36 karakter.
Generator UUID: UUID v7 dengan timestamp, versi, dan bit acak yang ditandai per field, plus batch UUID v7Generator UUID: UUID v7 dengan timestamp, versi, dan bit acak yang ditandai per field, plus batch UUID v7Pilih versiv4 acak, v7 berurutan waktu, v5 berbasis nama, dan lainnya, masing-masing dengan warnanya sendiri.Satu klikSalin, atau buat yang baru; batch hingga 10.000 bisa diambil sebagai teks, CSV, JSON, atau SQL.Setiap fieldBit-bit yang didefinisikan RFC 9562 untuk versi ini, lengkap dengan waktu yang dibawa v7.Format apa punKurung kurawal, tanpa tanda hubung, huruf besar, Base64url, bilangan bulat, atau urutan byte .NET.
UUID v7 yang diurai: timestamp 48 bit, digit versi, bit varian, dan bagian acaknya. Pilih sebuah nomor untuk melihat apa yang ditunjukkan setiap bagian.

Format dan panjang UUID: 36 karakter

UUID berukuran 128 bit, ditulis sebagai 32 digit hex dan 4 tanda hubung dalam grup 8, 4, 4, 4, dan 12: 36 karakter. Digit pertama grup ketiga adalah versinya, dan digit pertama grup keempat menunjukkan variannya: 8, 9, a, atau b untuk UUID RFC 9562.

Jadi 017f22e2-79b0-7cc3-98c4-dc0c0c07398f adalah versi 7, varian RFC. Huruf besar, huruf kecil, dan campuran keduanya sama-sama valid; sebagian besar alat mencetak huruf kecil, sedangkan uuidgen di macOS mencetak huruf besar. Tanpa tanda hubung panjangnya 32 karakter, dalam kurung kurawal 38 (format B di .NET), sebagai urn:uuid: 45, dan dalam Base64url 22.

Regular expression untuk memeriksa bentuk RFC: ^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ dengan flag case-insensitive. Regex ini menolak UUID Nil dan Max, yang valid tetapi khusus; dekoder di atas menyebutkan namanya.

Bentuk teksRFC 9562 §4
017f22e28-79b04-7cc34-98c44-dc0c0c07398f12

32 digit hex + 4 tanda hubung = 36 karakter

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxxM versi: 1–8N varian: 8, 9, a, atau b
Regex · tidak case-sensitive^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$
128 bit yang sama, ditulis dengan cara lain
  • Standar017f22e2-79b0-7cc3-98c4-dc0c0c07398f36
  • Tanpa tanda hubung017f22e279b07cc398c4dc0c0c07398f32
  • Kurawal {…}{017f22e2-79b0-7cc3-98c4-dc0c0c07398f}38
  • urn:uuid:urn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f45
  • Base64urlAX8i4nmwfMOYxNwMDAc5jw22
  • Base64AX8i4nmwfMOYxNwMDAc5jw==24
  • Base58BihbxwwQ4NZZpKRH9JDCz21
  • Base3201FWHE4YDGFK1SHH6W1G60EECF26
  • Bilangan bulat1989357241971137676463954034883508623hingga 39
  • Biner01 7f 22 e2 79 b0 7c c3 98 c4 dc 0c 0c 07 39 8f16 byte
Contoh v7 dari RFC 9562 sendiri dalam setiap bentuk tulisan. Regex sengaja menolak UUID Nil dan Max: keduanya tidak punya versi.

Versi UUID dijelaskan: v1 sampai v8

Versi menunjukkan cara UUID dibuat: v4 dari bit acak, v7 dari waktu ditambah bit acak, v1 dan v6 dari timestamp dan ID node, v3 dan v5 dengan meng-hash sebuah nama, dan v8 dengan tata letak rancangan pembuatnya sendiri.

Versi 2 dan 0 tidak dibuat di sini: v2 (DCE Security) dicadangkan dan RFC 9562 tidak mendefinisikan tata letaknya, sedangkan 0 bukan versi. Dua nilai khusus tidak punya versi: semua bit UUID Nil bernilai nol dan semua bit UUID Max bernilai satu (ffffffff-ffff-ffff-ffff-ffffffffffff, baru di RFC 9562).

Untuk sistem baru, RFC 9562 merekomendasikan v7 daripada v1 dan v6, serta v5 daripada v3. v4 tetap pilihan yang sederhana jika nilainya tidak boleh mengungkap apa pun tentang kapan ia dibuat.

Versi128 bit-nyaDibuat dariTerurut menurut waktu
v1Waktu + node · §5.1Waktu (100 ns) + urutan jam + nodeTidak
v2DCE Security: dicadangkan, tanpa tata letak di RFC 9562Tidak dibuat: tata letak tidak didefinisikan–
v3Nama · MD5 · §5.3MD5 dari namespace + namaTidak
v4Acak · §5.4Bit acakTidak
v5Nama · SHA-1 · §5.5SHA-1 dari namespace + namaTidak
v6v1 terurut · §5.6Field v1, bit tinggi waktu lebih duluYa
v7Urut waktu · §5.7Waktu Unix (ms) + bit acakYa
v8Kustom · §5.8Tata letak rancangan pembuatnyaTidak
Nil§5.9Semua nol: “tanpa nilai”–
Max§5.10Semua satu: sentinel–
  • waktu
  • acak
  • hash
  • urutan jam
  • ID node
  • versi
  • varian
Setiap batang adalah 128 bit satu versi sesuai tata letak RFC 9562, diambil dari test vector-nya sendiri. Hanya v6 dan v7 yang menaruh waktu di depan, jadi hanya keduanya yang terurut menurut waktu sebagai teks.

UUID v4 vs v7: mana yang sebaiknya dipakai?

Pakai v7 untuk key database dan apa pun yang Anda urutkan atau indeks: v7 diawali waktu pembuatan, jadi baris baru masuk di ujung indeks. Pakai v4 jika ID tidak boleh mengungkap kapan ia dibuat: seluruh 122 bit bebasnya acak.

Key v4 yang acak menyebarkan setiap insert ke seluruh indeks B-tree, sehingga halaman indeks terpecah (page split) dan lebih banyak bagian indeks harus tetap ada di memori; key v7 datang berurutan seperti angka auto-increment, tetapi server mana pun bisa membuatnya tanpa bertanya ke database. v7 menyimpan 74 bit acak per milidetik, jadi dua server yang membuatnya pada saat yang sama tetap tidak bertabrakan.

Konsekuensinya: siapa pun yang melihat v7 bisa membaca milidetik pembuatannya (tempel satu di dekoder di atas). Jika itu penting, pakai v4, atau pakai v7 hanya di internal dan tampilkan ID lain ke publik.

12 insert ke indeks B-tree8 halaman daun · masing-masing 16 key
key v4 masuk di mana saja7 dari 8 halaman tersentuh · 3 halaman terpecah
Halaman menurut byte pertama
00–1fpecah
20–3f
40–5f
60–7f
80–9f
a0–bf
c0–dfpecah
e0–ffpecah
c100eb4b-4f3f-4b29-ad77-da7cd9d1eda592c97333-2db8-4fc2-b5b6-cedd8c7abede
key v7 masuk di ujung1 dari 8 halaman tersentuh · 0 halaman terpecah
Halaman menurut hari key dibuat
17 Okt
18 Okt
19 Okt
20 Okt
21 Okt
22 Okt
23 Okt
24 Okt
01a16d3e-e1c0-70f6-99ec-6d454991b2fa01a16d3e-e1c0-70f6-99ec-6d45c2f6b35b
  • sudah ada di indeks
  • kosong
  • v4 baru
  • v7 baru
  • halaman terpecah: separuh key-nya pindah ke halaman baru
Sebuah model, bukan benchmark: halaman daun berisi 16 key. Key acak mendarat di halaman lama yang hampir penuh lalu memecahnya; byte pertama v7 adalah waktu, jadi kedua belas key masuk ke halaman terbaru, yang masih punya ruang.

GUID vs UUID: apakah ada bedanya?

GUID dan UUID adalah nilai 128 bit yang sama dalam bentuk teks yang sama; GUID adalah sebutan dari Microsoft. Guid.NewGuid() di .NET membuat UUID versi 4 yang acak, dan Guid.CreateVersion7() di .NET 9 membuat versi 7.

Bedanya ada di memori. Struktur GUID Microsoft menyimpan tiga grup pertamanya sebagai integer little-endian, sehingga ToByteArray() di .NET memberikan 8 byte pertama dalam urutan yang berbeda dari urutan byte jaringan RFC 9562: 919108f7-52d1-… menjadi byte f7 08 91 91 d1 52 …. Teksnya sama; byte mentah yang dipindahkan antarsistem perlu dikonversi. Dekoder menampilkan kedua urutan.

uniqueidentifier di SQL Server juga diurutkan menurut enam byte terakhirnya lebih dulu, jadi nilai v7 tidak tetap berurutan waktu di sana; NEWSEQUENTIALID() membuat nilai yang tetap berurutan, meski bisa mulai dari nilai yang lebih rendah lagi setelah restart dan mudah ditebak. GUID COM lama bisa membawa bit varian milik Microsoft sendiri, bukan milik RFC 9562; dekoder menyebutkan varian itu.

Satu GUID, tiga urutan byte16 byte
919108f7-52d1-4320-9bac-f847db4148a8
RFC 9562 urutan jaringan
.NET Guid.ToByteArray()
SQL Server urutan uniqueidentifierEnam byte terakhir menentukan urutannya
  • Data1 · 4 byte, dibalik
  • Data2 · dibalik
  • Data3 · dibalik
  • Data4 · apa adanya
Teks yang sama di memori: .NET menyimpan tiga grup pertama secara little-endian, dan SQL Server mengurutkan menurut enam byte terakhir lebih dulu, jadi key v7 yang berurutan waktu tidak tetap berurutan di sana.

Cara generate UUID di kode program

Sebagian besar bahasa membuat UUID v4 dalam satu baris, dan kini banyak yang juga bisa membuat v7: uuid.uuid7() di Python 3.14, Guid.CreateVersion7() di .NET 9, UUID.ofEpochMillis() di Java 26, uuid.NewV7() di Go 1.27, crypto.randomUUIDv7() di Node.js 26.1, dan uuidv7() di PostgreSQL 18. Browser masih hanya punya crypto.randomUUID(), sebuah v4.

Pilih bahasa Anda untuk melihat kode satu barisnya. Tidak setiap v7 menjaga urutan UUID yang dibuat di milidetik yang sama: milik Python dan Go menjaganya, milik .NET dan Node tidak menjaminnya. Selain itu, UUID() di MySQL mengembalikan UUID versi 1, yang di Linux dan Windows membawa alamat MAC asli server.

Fungsi UUID bawaan, per bahasa

Python
import uuid

uuid.uuid4()   # v4
uuid.uuid7()   # v7, Python 3.14+
uuid.uuid5(uuid.NAMESPACE_DNS, "www.example.com")  # v5

uuid7() menyimpan counter 42 bit, jadi UUID dari satu milidetik tetap berurutan.

Versi sesuai daftar di dokumentasi resmi tiap bahasa; logonya adalah logo resmi masing-masing proyek.

Mungkinkah dua UUID sama?

Secara teori mungkin, dalam praktik tidak: UUID v4 punya 122 bit acak, sekitar 5,3 × 10³⁶ nilai. Anda perlu membuat sekitar 103 triliun UUID untuk mendapat peluang satu banding satu miliar bahwa ada dua yang sama, dan sekitar 2,7 kuintiliun (2,7 × 10¹⁸) untuk peluang 50:50.

Itulah batas paradoks ulang tahun (birthday bound): dengan n nilai acak dari N kemungkinan, peluang ada yang kembar sekitar 1 − e^(−n(n−1)/2N). Jika Anda membuat satu miliar UUID per detik, peluang 50% baru tercapai setelah sekitar 86 tahun. Duplikat yang nyata berasal dari generator yang rusak: seed yang tidak acak, mesin virtual yang dikloning bersama status acaknya, atau ID yang disalin manual.

Untuk v7, hanya UUID yang dibuat di milidetik yang sama yang bisa kembar, dan 74 bit acak membedakannya. Generator di sini juga menjaga urutan batch di dalam satu milidetik (RFC 9562 §6.2), jadi 10.000 UUID sekaligus tetap unik dan terurut.

Batas paradoks ulang tahunhitungan kami
Peluang ada dua yang sama1 banding 1,1 × 1019p ≈ 9,4 × 10−20

Dengan satu miliar per detik, membuat sebanyak itu butuh 1 detik.

p ≈ 1 − e^(−n(n−1)/2N), dengan N = 2¹²² untuk v4 dan 2⁷⁴ per milidetik untuk v7. RFC 9562 tidak memberi angka tabrakan: angka ini hitungan kami, dari fungsi yang sama yang dipakai halaman ini.

Dekoder UUID: cara membaca timestamp UUID

Tempel UUID ke Dekode & validasi, dekoder dan validator UUID di atas: alat ini membaca versi dan varian dari dua posisi tetap, lalu field yang didefinisikan versi itu. v7 memberi milidetik pembuatannya, sedangkan v1 atau v6 memberi waktu hingga 100 nanodetik ditambah urutan jam (clock sequence) dan ID node.

Node v1 atau v6 yang bit multicast-nya tidak aktif mungkin adalah alamat MAC asli kartu jaringan; cari pembuatnya dengan cek MAC address. Generator yang menghargai privasi mengaktifkan bit itu dan memakai node acak, seperti generator ini.

Waktu itu adalah yang ditulis generator, bukan bukti kapan UUID dibuat. v4 tidak menyimpan waktu, hanya bit acak, sedangkan v3, v5, dan v8 menyimpan hash: tidak ada yang bisa dibaca kembali, dan hash tidak bisa dibalik menjadi namanya. Tempel daftar untuk memeriksa hingga 1.000 UUID sekaligus: baris tidak valid, duplikat, dan apakah UUID berbasis waktu sudah berurutan.

Dua cara menulis momen yang samaRFC 9562 · Appendix A
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
  1. unix_ts_ms0x017f22e279b0
  2. ms sejak 19701 645 557 742 000
  3. UTC2022-02-22T19:22:22.000Z
c232ab00-9414-11ec-b3c8-9f6bdeced846
  1. time_high · time_mid · time_low1ec 9414 c232ab00
  2. langkah 100 ns sejak 1582-10-15138 648 505 420 000 000
  3. UTC2022-02-22T19:22:22.0000000Z

Momen yang sama: contoh-contoh di RFC 9562 dibuat bersamaan.

v7 diawali jumlah milidetik sejak 1970. v1 menyimpan bagian rendah waktunya lebih dulu, jadi dekoder menyusun ulang ketiga bagian itu sebelum menghitung dari 15 Oktober 1582.

UUID berbasis nama: v5 dan v3

UUID v5 adalah hash SHA-1 dari UUID namespace ditambah sebuah nama, dipotong menjadi 128 bit dengan versi dan varian ditetapkan; v3 melakukan hal yang sama dengan MD5. Namespace dan nama yang sama selalu menghasilkan UUID yang sama, di komputer mana pun: pilih v5 di atas untuk memakai halaman ini sebagai generator UUID v5.

RFC 9562 mendefinisikan empat namespace: DNS untuk nama domain, URL, OID, dan X.500. Jadi www.example.com di namespace DNS selalu menjadi 2ed6657d-e927-568b-95e1-2665a8aea6a2 sebagai v5. Pakai UUID berbasis nama untuk memberi ID yang tetap pada sesuatu yang sudah punya nama unik, tanpa menyimpan tabel pemetaan.

Pilih v5 daripada v3: MD5 lebih lemah, dan RFC 9562 merekomendasikan v5. Keduanya bukan cara untuk menyembunyikan nama: siapa pun yang bisa menebak namanya bisa menghitung UUID yang sama. Opsi v8 di sini memakai SHA-256 dengan cara yang sama, seperti contoh v8 di RFC itu sendiri.

Namespace + nama → v5RFC 9562 §5.5
  1. Namespace6ba7b810-9dad-11d1-80b4-00c04fd430c8DNS · 16 byte
  2. Nama"www.example.com"UTF-8 · 15 byte
  3. Digest SHA-1, 160 bit2ed6657de927468b55e12665a8aea6a22dee3e35128 bit pertama diambil
  4. UUID-nya2ed6657d-e927-568b-95e1-2665a8aea6a2digit versi 4 → 5 · digit varian 5 → 9
  • DNS6ba7b810…
  • URL6ba7b811…
  • OID6ba7b812…
  • X.5006ba7b814…
Contoh v5 dari RFC 9562 sendiri: www.example.com di namespace DNS. Komputer mana pun yang meng-hash namespace dan nama yang sama mendapat UUID yang sama.

ULID vs UUID v7 (dan ID lainnya)

ULID dan UUID v7 sama-sama diawali timestamp milidetik 48 bit dan terurut menurut waktu. Bedanya: ULID memakai seluruh 80 bit sisanya untuk keacakan dan ditulis sebagai 26 karakter Base32, sedangkan v7 memakai 6 bit untuk versi dan variannya serta cocok dengan setiap kolom dan pustaka UUID.

Jika database, ORM, atau API Anda sudah mendukung UUID, v7 memberi urutan waktu tanpa tipe data baru. NanoID dan ID pendek sejenisnya adalah string acak dengan panjang yang dipilih, tanpa waktu dan tanpa tata letak standar. UUID apa pun juga bisa ditulis lebih pendek: 22 karakter dalam Base64url, paling banyak 22 dalam Base58.

Tiga ID, masing-masing 128 bitsesuai skala
UUID v7waktu, lalu acak
36 karakterterurut menurut waktu
ULIDwaktu, lalu acak
26 karakterterurut menurut waktu
UUID v4hanya acak
36 karaktertanpa urutan
  • milidetik sejak 1970
  • acak
  • versi dan varian
UUID v7 dan ULID sama-sama memakai jam milidetik 48 bit; v7 memberi 6 bit untuk versi dan variannya, ULID memakai seluruh 80 bit untuk keacakan. v4 hanya berisi bit acak; dalam Base64url, UUID apa pun panjangnya 22 karakter.

Amankah UUID dipakai sebagai token?

Tidak. RFC 9562 menyatakan agar UUID tidak dianggap sulit ditebak, dan jangan pernah dipakai sebagai kapabilitas keamanan (security capability): ID yang memberi akses kepada siapa pun yang memegangnya, seperti tautan reset password atau API key.

v4 dari generator yang baik memang acak, tetapi v1, v6, atau v7 mengungkap waktu pembuatannya, dan v3 atau v5 bisa dihitung ulang dari namanya. Untuk rahasia, pakai token yang memang dibuat untuk itu, seperti 256 bit acak dari generator kriptografis, dan periksa izin di setiap request. UUID aman dipakai sebagai ID publik jika akses diperiksa secara terpisah.

IDYang bisa diketahui siapa pun yang melihatnyaSebagai rahasia
v1, v6Kapan ia dibuat, dan mungkin alamat MAC kartu jaringanTidak
v7Milidetik pembuatannyaTidak
v5, v3Tidak ada yang baru, tetapi nama yang berhasil ditebak menghasilkan UUID yang samaTidak
v4Tidak ada, jika generatornya andalTidak
Token 256 bitTidak ada: memang dibuat untuk rahasiaYa
RFC 9562 menyatakan agar UUID tidak dianggap sulit ditebak atau dipakai sebagai kapabilitas keamanan. Pakai token dari generator kriptografis untuk rahasia dan periksa akses di setiap request.

Generator UUID: tanya jawab

Bagaimana cara generate UUID?

Buka halaman ini: UUID v4 acak sudah siap disalin, dan tombol UUID baru membuat yang lain. Pilih v7 untuk memakainya sebagai generator UUID v7, atur jumlahnya hingga 10.000 sekaligus, lalu pilih format seperti kurung kurawal atau Base64url. Di kode, crypto.randomUUID() di JavaScript, uuid.uuid4() di Python, dan Guid.NewGuid() di C# masing-masing membuat v4 dalam satu baris.

Apa kepanjangan UUID?

Universally Unique Identifier. UUID adalah nilai 128 bit, ditulis sebagai 36 karakter seperti 919108f7-52d1-4320-9bac-f847db4148a8, yang dibuat setiap komputer secara mandiri tanpa registri pusat dan tetap diharapkan unik. RFC 9562 mendefinisikannya. Microsoft menyebut nilai yang sama GUID, Globally Unique Identifier.

Apakah GUID sama dengan UUID?

Ya, untuk keperluan praktis: 128 bit yang sama dan bentuk teks yang sama, dan Guid.NewGuid() membuat UUID versi 4 standar. Ada dua detail yang berbeda. .NET menyimpan tiga grup pertama secara little-endian, sehingga array byte mentah keluar dalam urutan berbeda, dan SQL Server mengurutkan nilai uniqueidentifier menurut grup terakhir lebih dulu. Untuk membuat GUID, pakai halaman ini sebagai generator GUID acak: teks yang Anda salin berlaku di keduanya.

Versi UUID mana yang sebaiknya saya pakai?

Versi 7 untuk key database dan apa pun yang diurutkan, karena diawali waktu pembuatan dan menjaga indeks tetap ringkas. Versi 4 jika ID tidak boleh mengungkap kapan ia dibuat. Versi 5 jika nama yang sama harus selalu dipetakan ke ID yang sama. Hindari v1 untuk proyek baru: RFC 9562 merekomendasikan v7 sebagai gantinya, dan v1 bisa membawa alamat MAC asli.

Bisakah dua UUID kembar?

Hanya dengan peluang yang luar biasa kecil, selama generatornya andal. v4 punya 122 bit acak, jadi sekitar 103 triliun UUID memberi peluang satu banding satu miliar untuk satu duplikat, dan peluang 50% butuh sekitar 2,7 kuintiliun. Duplikat di dunia nyata berasal dari generator yang cacat, mesin virtual yang dikloning, atau data yang disalin, bukan dari matematikanya.

Bisakah UUID didekode?

Sebagian. Setiap UUID menunjukkan versi dan variannya. v7 juga mengungkap milidetik pembuatannya, dan v1 atau v6 waktunya hingga 100 nanodetik, urutan jam, dan ID node, kadang berupa alamat MAC asli. v4 hanya berisi bit acak, sedangkan v3 dan v5 berisi hash yang tidak bisa dikembalikan menjadi namanya. Tempel sebuah UUID di Dekode & validasi.

Berapa panjang UUID?

128 bit, atau 16 byte. Sebagai teks panjangnya 36 karakter: 32 digit heksadesimal dan 4 tanda hubung dalam grup 8-4-4-4-12. Tanpa tanda hubung 32 karakter, dalam kurung kurawal 38, dengan awalan urn:uuid: 45, dalam Base64url 22, dan sebagai bilangan bulat desimal hingga 39 digit. Jika bisa, simpan sebagai tipe UUID bawaan atau 16 byte, bukan sebagai teks.

Apa itu GUID kosong (empty GUID) atau UUID Nil?

Nilai yang seluruh 128 bitnya nol: 00000000-0000-0000-0000-000000000000. RFC 9562 menyebutnya UUID Nil, dan Guid.Empty di .NET adalah nilai yang sama, sering dipakai untuk menandai ID yang belum diisi. RFC 9562 juga mendefinisikan UUID Max, semua bitnya satu, ffffffff-ffff-ffff-ffff-ffffffffffff, sebagai sentinel (.NET 9: Guid.AllBitsSet). Keduanya tidak acak, jadi jangan pernah memakainya sebagai ID sungguhan.

Apakah UUID v7 bisa diurutkan?

Ya. 48 bit pertamanya adalah waktu Unix dalam milidetik, jadi mengurutkan UUID v7 sebagai teks atau byte sama dengan mengurutkannya menurut waktu pembuatan, hingga milidetik. Di dalam satu milidetik, urutannya tergantung generator: generator ini menjaga batch tetap naik secara ketat, seperti dijelaskan RFC 9562 bagian 6.2. uniqueidentifier di SQL Server adalah pengecualian: ia membandingkan grup terakhir lebih dulu.

Amankah memakai UUID sebagai password atau token akses?

Tidak. RFC 9562 memperingatkan agar UUID tidak dianggap sulit ditebak atau dipakai sebagai kapabilitas keamanan. Versi berbasis waktu mengungkap kapan ia dibuat, dan versi berbasis nama bisa dihitung ulang. Pakai token acak dari generator kriptografis untuk rahasia, dan perlakukan UUID sebagai ID publik dengan akses yang diperiksa terpisah. Untuk password, pakai pembuat kata sandi.

Apakah UUID yang dibuat di sini dikirim ke mana pun?

Tidak. UUID dibuat di browser Anda dengan crypto.getRandomValues, generator acak browser yang aman secara kriptografis, dan UUID yang ditempel didekode di perangkat Anda. Tidak ada yang Anda buat atau tempel dikirim ke kami atau pihak lain. Tautan berbagi hanya memuat yang Anda pilih: versi, jumlah, dan format, nama untuk v5, atau UUID yang Anda tempel ke dekoder, jadi bagikan tautan itu seperti Anda membagikan isinya.

Ada yang kurang?Usulkan fitur atau alat baru