İstediğin sürümde UUID üret, toplu al, biçimini seç ve tek tıkla kopyala. Elindeki bir UUID’yi çözümleyip sürümünü ve içindeki zaman damgasını da görebilirsin. Üretim tamamen tarayıcında yapılır; hiçbir değer sunucuya gönderilmez.
Elindeki bir UUID’yi yapıştır: sürümünü, variant’ını ve varsa içindeki zaman damgasını okur. Süslü parantezli, urn:uuid: önekli, büyük harfli ve tiresiz biçimleri de kabul eder.
Ne istediğinden emin değilsen v4'te kal. Veritabanı birincil anahtarı üretiyorsan v7, aynı girdiden hep aynı kimliği istiyorsan v5 seç.
Tek bir kimlik ya da bir seferde 500 tanesine kadar. Üretim tarayıcında yapıldığı için beklemek gerekmez.
Büyük harf, tiresiz yazım, süslü parantez ve urn:uuid: öneki anahtarlarla açılır; liste anında yeniden yazılır.
Düz liste, JSON dizisi, CSV veya hazır SQL INSERT olarak kopyala; istersen .txt dosyası olarak indir.
UUID (Universally Unique Identifier), 128 bitlik bir kimlik numarasıdır. Amacı, merkezî bir numara dağıtıcısına hiç danışmadan, birbirinden habersiz sistemlerin aynı numarayı üretme ihtimalini pratikte sıfıra indirmektir. Bir veritabanı sunucusundan sıradaki numarayı istemeniz gerekmez; kaydı oluşturan taraf kimliği kendisi üretir.
GUID (Globally Unique Identifier) ise aynı şeyin Microsoft dünyasındaki adıdır. Aralarında teknik bir fark yoktur; yalnızca Microsoft araçları değeri çoğu zaman süslü parantez içinde ve büyük harfle yazar. Bu sayfadaki biçim anahtarları da tam olarak bunun için var.
Standart, 2024’te RFC 9562 ile güncellendi ve eski RFC 4122’nin yerini aldı. Yeni metin v7 ve v8 sürümlerini ekledi, NIL’in karşısına Max değerini koydu ve v1 yerine v7, v3 yerine v5 kullanılmasını önerdi. Bu araç RFC 9562’yi izler.
| Sürüm | Ne içerir? | Ne zaman kullanılır? |
|---|---|---|
| v4 | 122 bit rastgelelik | Varsayılan tercih. Hiçbir bilgi taşımaz, hiçbir şey sızdırmaz. Ne istediğinden emin değilsen bunu seç. |
| v7 | Unix zaman damgası + rastgelelik | Veritabanı birincil anahtarı. Üretim sırasına göre sıralandığı için indeks parçalanmasını önler. |
| v1 | Zaman damgası + düğüm kimliği | Yalnızca v1 bekleyen eski bir sistemle uyum gerekiyorsa. Yeni işlerde yerine v7 önerilir. |
| v5 | İsim alanı + isim (SHA-1) | Aynı girdiden her zaman aynı kimliği üretmek gerektiğinde. Örneğin bir URL’ye kalıcı bir kimlik türetmek. |
| v3 | İsim alanı + isim (MD5) | v5 ile aynı iş, eski hash ile. Yalnızca MD5 bekleyen bir sistem varsa. Aksi hâlde v5. |
| NIL / Max | Tamamı 0 / tamamı f | “Değer yok” ve “üst sınır” anlamında kullanılan iki özel sabit. |
v4 tamamen rastgeledir, yani üretilen her kimlik indeksin rastgele bir yerine düşer. B-tree indekste bu, her yeni kaydın farklı bir sayfayı değiştirmesi demektir: sayfalar bölünür, önbellekte tutulması gereken alan büyür ve tablo büyüdükçe yazma performansı düşer. Otomatik artan bir tam sayıda ise her yeni kayıt indeksin sonuna eklenir, tek bir sayfa sıcak kalır.
v7 tam olarak bu farkı kapatmak için tasarlandı. İlk 48 biti milisaniye cinsinden Unix zaman damgası olduğu için art arda üretilen kimlikler birbirine yakın değerler alır ve indekse sırayla eklenir. Yani UUID’nin dağıtık üretilebilme avantajını, artan tam sayının indeks davranışıyla birleştirir.
Bedeli şudur: v7 üretildiği anı kimliğin içine yazar. Bir kaydın ne zaman oluşturulduğunu gizlemek istiyorsan v7 bunu ele verir; böyle bir durumda v4 doğru tercihtir. Bu sayfadaki çözümleyiciye bir v7 yapıştırıp içindeki zaman damgasını görmen bunun ne kadar kolay olduğunu gösterir.
v4’te 122 bit rastgeledir; bu 5,3 × 10³⁶ farklı değer eder. Çakışma olasılığını anlamlı bir seviyeye çıkarmak için milyarlarca UUID üretmek gerekir — pratikte kimsenin karşılaşmadığı bir sayı. Bu yüzden UUID’ler benzersizliği bir garanti değil, ihmal edilebilir bir olasılık olarak sunar.
Asıl risk matematikte değil, kötü rastgelelikte. Zayıf bir rastgele sayı üretecine dayanan bir uygulama, teorik olasılıktan çok daha sık çakışma üretebilir. Bu sayfa tarayıcının kriptografik üretecini (crypto.getRandomValues) kullanır; Math.random’a hiçbir koşulda düşmez.
İsim tabanlı sürümlerde ise durum farklıdır: v3 ve v5 kasten deterministiktir. Aynı isim alanı ve aynı isim her zaman aynı kimliği verir — bu bir kusur değil, o sürümlerin varlık sebebidir.
v4, v7, v1, v5 ve v3’ün yanında NIL ve Max sabitleri. Her seçeneğin ne işe yaradığı seçtiğin anda yazıyor.
Adet gir, listeyi al. Tarayıcında üretildiği için beklemek gerekmez ve sunucuya hiçbir yük binmez.
Düz liste, JSON dizisi, CSV ya da hazır SQL INSERT. Ayrıca .txt olarak indirebilirsin.
Sürümünü, variant’ını ve v1/v6/v7 ise içindeki zaman damgasını okur. Geçersizse nedenini söyler.
v1 klasik olarak MAC adresi taşır. Burada tarayıcı MAC okuyamadığı için düğüm rastgele üretilir ve standardın istediği gibi işaretlenir.
Üretim de çözümleme de tamamen tarayıcında yapılır. Ne ürettiğin ne de çözümlediğin bir yere kaydedilir.
UUID, 128 bitlik evrensel bir kimlik numarasıdır. Merkezî bir numara dağıtıcısına danışmadan üretilebilmesi için tasarlanmıştır: birbirinden habersiz iki sistem aynı anda UUID üretse bile aynı değere düşme olasılığı ihmal edilebilir düzeydedir.
Teknik olarak hiçbir fark yok; GUID, Microsoft'un aynı şeye verdiği addır. Tek fark yazımdadır: Microsoft araçları değeri çoğu zaman süslü parantez içinde ve büyük harfle yazar. Bu sayfadaki biçim anahtarlarıyla iki gösterimi de üretebilirsin.
Emin değilsen v4. Veritabanında birincil anahtar olarak kullanacaksan v7, çünkü zaman sıralı olduğu için indeksi parçalamaz. Aynı girdiden her zaman aynı kimliği üretmen gerekiyorsa v5. v1 ve v3 yalnızca eski sistemlerle uyum için vardır; RFC 9562 bunların yerine v7 ve v5 önerir.
v4'te 122 bit rastgeledir, yani 5,3 × 10³⁶ farklı değer vardır. Çakışma olasılığını anlamlı bir seviyeye çıkarmak için milyarlarca kimlik üretmek gerekir. Asıl risk matematikte değil, zayıf bir rastgele sayı üretecindedir; bu araç tarayıcının kriptografik üretecini kullanır.
v4 tamamen rastgele olduğu için her yeni kayıt indeksin farklı bir yerine düşer; sayfalar bölünür ve tablo büyüdükçe yazma performansı düşer. v7'nin ilk 48 biti zaman damgası olduğu için art arda üretilen kimlikler indekse sırayla eklenir. Bedeli, kaydın oluşturulma anının kimlikten okunabilmesidir.
Klasik v1 üretiminde evet — düğüm alanı makinenin MAC adresidir. Bu sayfada böyle bir risk yok, çünkü tarayıcı MAC adresi okuyamaz. Düğüm rastgele üretilir ve standardın istediği gibi multicast biti işaretlenir, böylece gerçek bir ağ arabirimiyle karıştırılamaz.
Çünkü öyle olmaları gerekiyor. Bu iki sürüm bir isim alanı ile bir ismi hash'leyerek kimlik üretir; aynı girdi her zaman aynı çıktıyı verir. Bir URL'ye ya da bir e-postaya kalıcı ve tekrarlanabilir bir kimlik türetmek istediğinde işe yarar. Bu yüzden bu iki sürümde adet seçici görünmez.
PostgreSQL'de yerleşik uuid tipi vardır ve 16 bayt yer kaplar; metin olarak saklamaktan hem küçük hem hızlıdır. MySQL'de yerleşik tip yoktur; CHAR(36) kolay okunur ama BINARY(16) yarıdan az yer kaplar. Hangisini seçersen seç, tüm kayıtlarda aynı biçimi kullan.
NIL tamamı sıfır olan özel değerdir ve "değer yok" anlamında kullanılır — null yerine geçen bir yer tutucu gibi. Max ise tamamı f olan, RFC 9562 ile tanımlanmış karşıtıdır; sıralamalarda üst sınır olarak kullanılır. İkisi de gerçek bir nesneyi tanımlamaz.
Hayır. Üretim de çözümleme de tamamen tarayıcında yapılır; sayfa bu iş için sunucuya hiçbir istek göndermez. Ne ürettiğin ne de çözümlemek için yapıştırdığın değer bir yere yazılır.