Gratis UUID-generator - Opprett V1 & V4 UUID-er umiddelbart

UUID-generator

En UUID-generator er et verktøy som oppretter en universelt unik identifikator, eller UUID: en kode på 128 bit som brukes til å merke et dataelement, slik at det er svært usannsynlig at noe annet element noe sted har samme merke. Denne siden genererer UUID-er av versjon 1 (tidsbaserte) og versjon 4 (tilfeldige).

Hva er en UUID?

En UUID er et 128-bit-tall skrevet som 32 heksadesimale sifre (tegnene 0–9 og a–f). Det deles inn i fem grupper atskilt med bindestreker, etter mønsteret 8-4-4-4-12, med totalt 36 tegn. En UUID kan for eksempel se slik ut:

1550e8400-e29b-41d4-a716-446655440000
2

UUID-er er definert av RFC 9562, som ble publisert av Internet Engineering Task Force i mai 2024, og erstattet den eldre RFC-en 4122 fra 2005. Begge dokumentene beskriver det samme formatet på 128 bit. Programvare bruker dem til å identifisere rader i databaser, filer, brukerøkter og andre poster uten at en sentral instans må dele ut numre. Fordi mengden mulige UUID-er er så stor, kan to datamaskiner generere UUID-er uavhengig av hverandre samtidig og nesten aldri lage den samme.

UUID-format og -struktur

De 128 bitene i en UUID deles inn i navngitte felt. Hvert felt bruker et fast antall bit:

• time_low – 32 bit
• time_mid – 16 bit
• time_hi_and_version – 16 bit
• clock_seq_hi_and_reserved – 8 bit
• clock_seq_low – 8 bit
• node – 48 bit

Fire bit i time_hi_and_version inneholder UUID-ens versjonsnummer, og to bit i clock_seq_hi_and_reserved inneholder varianten, som forteller programvaren hvordan resten av feltene skal leses. Åtte versjoner er definert.

Feltnavnene ovenfor stammer fra versjon 1, der de faktisk inneholder en tidsverdi og en nodeverdi. Andre versjoner beholder samme oppsett 8-4-4-4-12 og de samme feltgrensene, men fyller de fleste bitene med tilfeldige data. I en UUID av versjon 4 er gruppen merket time_low tilfeldig, ikke en tidsverdi.

Slik genererer du en UUID med dette verktøyet

1. Velg en versjon: versjon 1 (tidsbasert) eller versjon 4 (tilfeldig).
2. Les UUID-en i resultatfeltet. En ny UUID vises så snart siden lastes inn eller versjonen endres.
3. Velg «Generer» for å lage en ny.
4. Velg «Kopier» for å kopiere resultatet til utklippstavlen, og lim det deretter inn i kode, en database eller en konfigurasjonsfil.

Panelet under resultatet deler UUID-en inn i de fem feltene og navngir hvert av dem, slik at versjonssifferet og variantsifferet er enkle å finne.

Versjon 4 passer til de fleste formål, blant annet databasenøkler og økttokener, fordi den ikke inneholder informasjon om når eller hvor den ble opprettet. Versjon 1 passer til poster der opprettelsestidspunktet må kunne hentes fra selve identifikatoren, for eksempel loggoppføringer.

UUID-versjon 1 mot versjon 4

Versjon 1 koder det aktuelle tidspunktet samt en tilfeldig valgt klokkesekvens og nodeverdi. Standarden tillater at nodeverdien er datamaskinens faktiske nettverksadresse (MAC-adresse), men den tillater også en tilfeldig generert nodeverdi som et personvernbevarende alternativ. Dette verktøyet bruker alltid det tilfeldige alternativet: UUID-er av versjon 1 leser eller eksponerer aldri en faktisk MAC-adresse. Standarden krever også at det laveste bitet i den første byten i nodefeltet settes til 1 for en tilfeldig nodeverdi, og dette verktøyet setter det. Ekte nettverkskort har aldri dette bitet satt, så en tilfeldig node kan aldri forveksles med en ekte. Derfor er det andre heksadesimale sifferet i den femte gruppen alltid oddetall i en UUID av versjon 1 fra denne siden: 1, 3, 5, 7, 9, b, d eller f.

Tidsstempelet i en UUID av versjon 1 kan leses tilbake, slik at poster kan ordnes etter opprettelsestidspunkt. Sortering av selve UUID-teksten gjør ikke dette, fordi den første gruppen inneholder de laveste 32 bitene av tidsstempelet, som går rundt omtrent hvert 7 minutt. Versjon 6, som ble lagt til i RFC 9562, lagrer det samme tidsstempelet med de høyeste bitene først, slik at vanlig tekstsortering fungerer.

Versjon 4 er bygget av tilfeldige bit, med noen få bit fastsatt for å angi versjonen og varianten. Den inneholder ikke noe tidsstempel eller maskinspesifikke data, og avslører derfor ikke når eller hvor den ble opprettet. Den kan ikke sorteres etter opprettelsesrekkefølge.

Seks andre versjoner finnes i standarden, men genereres ikke av dette verktøyet: versjon 2 (DCE Security, sjelden brukt); versjon 3 og versjon 5, som bygges ved å hashe et navnerom og et navn med MD5 eller SHA-1, slik at samme inndata alltid gir samme UUID; samt versjon 6, 7 og 8, som ble lagt til av RFC 9562 i (24 300 cm) 2024 for sorterbare og egendefinerte identifikatorer.

Slik beregnes en UUID (formel)

Versjon 4:

1. Generer 128 tilfeldige bit.
2. Sett de fire versjonsbitene, det første heksadesimale sifferet i den tredje gruppen, til 0100 (heks. 4).
3. Sett de to øverste bitene i den fjerde gruppen til 10 (slik at det første heksadesimale sifferet i gruppen blir 8, 9, a eller b).

Bare 122 av de 128 bitene er faktisk tilfeldige, siden 6 bit er fastsatt av trinn 2 og 3. Det gir 2^122, eller omtrent 5,3 × 10^36, mulige UUID-er av versjon 4.

Versjon 1:

1. Ta det aktuelle tidspunktet som et antall intervaller på 100 nanosekunder siden 15. oktober 1582, datoen for reformen av den gregorianske kalenderen. I praksis er dette vanlig Unix-tid i millisekunder pluss 12 219 292 800 000, alt multiplisert med 10 000.
2. Del dette antallet på 60 bit mellom tre felt: de laveste 32 bitene går i time_low, de neste 16 i time_mid, og de øverste 12 i time_hi_and_version.
3. Generer en klokkesekvens på 14 bit, som brukes til å unngå kollisjoner hvis systemklokken stilles tilbake.
4. Generer en nodeverdi på 48 bit, med det laveste bitet i den første byten satt til 1.
5. Sett versjonsbitene til 0001 og variantbitene til 10.

På tvers av alle UUID-versjoner inneholder hele området på 128 bit 2^128, eller omtrent 3,4 × 10^38, mulige verdier. Tallet er så stort at tilfeldige kollisjoner ikke er en praktisk bekymring.

Regneeksempel

Slik leses en UUID av versjon 4. Ta eksempelet fra tidligere: 550e8400-e29b-41d4-a716-446655440000.

• Tredje gruppe, 41d4: det første sifferet er 4, som markerer dette som en UUID av versjon 4.
• Fjerde gruppe, a716: det første sifferet, a (binært 1010), begynner med 10, de påkrevde variantbitene.
• De resterende heksadesimale sifrene er den tilfeldige nyttelasten.

Et program som leser denne UUID-en, kontrollerer mønsteret 4 og 10 for å bekrefte formatet, og behandler deretter resten som en ugjennomsiktig tilfeldig verdi.

Slik bygges en UUID av versjon 1. Anta at klokken viser 1 700 000 000 000 millisekunder Unix-tid, som er 14. november 2023, 22:13:20 UTC.

1. Legg til forskyvningen: 1 700 000 000 000 + 12 219 292 800 000 = 13 919 292 800 000 ms.
2. Multipliser med 10 000 for å få intervaller på 100 nanosekunder: 139,192,928,000,000,000. I heksadesimal er dette 01EE833B04AFC000.
3. Del det opp: time_low = 04AFC000 (de laveste 8 heksadesimale sifrene), time_mid = 833B (de neste 4), og de øverste 12 bitene er 1EE.
4. Sett versjonssifferet 1 foran 1EE, slik at time_hi_and_version = 11EE.

UUID-en blir da 04afc000-833b-11ee- etterfulgt av klokkesekvensen og nodeverdien. Programvare kan reversere disse fire trinnene for å hente 14. november 2023 fra identifikatoren.

Vanlige bruksområder for UUID-er

• Primærnøkler i databaser, særlig når flere servere oppretter poster samtidig uten å kommunisere med hverandre.
• Øktbrikker og API-nøkler, vanligvis versjon 4 på grunn av personvernet den gir.
• Identifikatorer for filer, hendelser og ressurser i distribuerte systemer, for eksempel mikrotjenester.
• Enhets-ID-er i store IoT-nettverk, der hver enhet kan generere sin egen ID uten nettforbindelse.

Den viktigste avveiningen er størrelsen: En UUID krever 16 byte lagringsplass, sammenlignet med 4 eller 8 byte for en enkel heltallsteller, og noen databaser indekserer UUID-er saktere enn sekvensielle heltall.

Alternativer til UUID-er

Heltall som økes automatisk, er mindre og enklere, men fungerer dårlig når mer enn én server må dele ut ID-er uavhengig. Snowflake-ID-er, utviklet hos Twitter, kombinerer et tidsstempel med en arbeider-ID for å generere kompakte, sorterbare identifikatorer i et distribuert system. ULID-er (universelt unike leksikografisk sorterbare identifikatorer) er et nyere format utformet for å være både tilfeldige og sorterbare etter opprettelsestidspunkt, i motsetning til en standard UUID av versjon 4.

UUID-standardens historie

UUID-konseptet oppsto på 1980-tallet hos Apollo Computer, som en del av selskapets Network Computing System. Open Software Foundation tok senere i bruk formatet for sitt Distributed Computing Environment. Internet Engineering Task Force publiserte RFC 4122 i (10 500 cm) 2005 og erstattet den med RFC 9562 i mai 2024. RFC 9562 beholder alle tidligere versjoner uendret og legger til versjon 6, 7 og 8.

Ofte stilte spørsmål

Hva brukes en UUID-generator til? Den oppretter unike identifikatorer i databaser, distribuerte systemer, økttokener, API-nøkler og enhets-ID-er, slik at ingen poster trenger å dele samme identifikator.

Hva er forskjellen mellom UUID v1 og v4? Versjon 1 koder et tidsstempel som programvare kan lese tilbake for å finne opprettelsestidspunktet. Versjon 4 er fullstendig tilfeldig og inneholder ikke noe tidsstempel. Verktøyets resultat for versjon 1 bruker en tilfeldig generert nodeverdi i stedet for en ekte MAC-adresse, og avslører derfor heller ikke maskinidentifiserende informasjon.

Avslører versjon 1 MAC-adressen min? Ikke med dette verktøyet. Standarden tillater at nodefeltet i en UUID av versjon 1 inneholder en ekte MAC-adresse, men denne generatoren fyller alltid feltet med tilfeldige bit og setter bitet som markerer verdien som ikke en ekte nettverksadresse.

Er UUID-er garantert å være unike? Ingen identifikasjonsordning kan garantere absolutt unikhet, men området på 128 bit inneholder omtrent 3,4 × 10^38 mulige verdier, og en UUID av versjon 4 har omtrent 5,3 × 10^36 mulige tilfeldige verdier. Sannsynligheten for en duplikat er liten nok til å kunne ignoreres i nesten alle praktiske bruksområder.

Kan jeg bruke en UUID som primærnøkkel i en database? Ja. UUID-er fungerer godt som primærnøkler i distribuerte systemer fordi enhver node kan generere en uten å kommunisere med en sentral server. Kostnaden er 16 byte lagringsplass per nøkkel, mer enn for et vanlig heltall, og potensielt tregere indeksytelse i svært store tabeller.

Er en UUID det samme som en GUID? Ja. GUID (globalt unik identifikator) er Microsofts betegnelse på det samme konseptet som er definert som en UUID av RFC 4122.

Kan UUID-er av versjon 4 sorteres etter opprettelsestidspunkt? Nei. UUID-er av versjon 4 er tilfeldige og inneholder derfor ingen opplysninger om når de ble opprettet. En UUID av versjon 1 inneholder et slikt tidspunkt, men det må dekodes først; sortering av teksten gir ikke opprettelsesrekkefølgen. Versjon 6, versjon 7 og ULID-er er utformet for å kunne sorteres direkte som tekst.

Referanser

1. Davis, K., Peabody, B. og Leach, P. (2024). Universally Unique IDentifiers (UUIDs). RFC 9562. https://www.rfc-editor.org/rfc/rfc9562
2. Leach, P., Mealling, M. og Salz, R. (2005). A Universally Unique IDentifier (UUID) URN Namespace. RFC 4122. https://www.rfc-editor.org/rfc/rfc4122
3. Universally unique identifier. I Wikipedia. https://en.wikipedia.org/wiki/Universally_unique_identifier
4. Snowflake ID. I Wikipedia. https://en.wikipedia.org/wiki/Snowflake_ID
5. ULID-spesifikasjon. GitHub. https://github.com/ulid/spec