UUID v4 generator

UUID v4 generator er et gratis værktøj, der opretter en Universally Unique Identifier i version 4 til brug som identifikator for en post, et objekt eller en anmodning.

Hvordan håndterer UUID v4 generator mine data?

Genereringen foregår på serveren. Inputtet sendes til serveren via HTTPS og bliver ikke gemt. Det vil derfor være misvisende at sige, at genereringen udelukkende foregår i din browser, eller at data aldrig forlader din enhed.

En UUID v4 kræver ikke personlig tekst, et navn eller en adgangskode som grundlag. Den genereres som en identifikator og beregnes ikke ud fra oplysninger, du angiver. Undlad at knytte fortrolig betydning til den genererede værdi, da alle, der kan se den, kan kopiere og genbruge den.

Hvad er en UUID v4?

En UUID v4 er en 128-bit-identifikator, hvor den variable del genereres tilfældigt eller pseudotilfældigt. Flere bit er reserveret til at angive UUID'ens version og variant. Den bruges ofte, når separate systemer skal kunne oprette identifikatorer uden først at spørge en central tjeneste om det næste ledige nummer.

Den skriftlige standardform består af 32 hexadecimale tegn fordelt på fem grupper med bindestreger imellem. Den følger mønsteret 8-4-4-4-12 og er 36 tegn lang, når de fire bindestreger tælles med.

Et syntaktisk gyldigt eksempel er 550e8400-e29b-41d4-a716-446655440000. I en UUID version 4 er det første tegn i den tredje gruppe 4. De to mest betydende bit, der angiver varianten, er 10. Det giver et indledende hexadecimalt tegn på 8, 9, a eller b i den fjerde gruppe.

Værdien er en identifikator, ikke kodede oplysninger. Den kan ikke afkodes for at finde en oprettelsesdato, et kontonavn, en maskinadresse eller et sekvensnummer.

Hvilken UUID-version skal jeg vælge?

Vælg version 4, når du har brug for en uafhængigt genereret, uigennemsigtig identifikator og ikke kræver, at det samme input altid giver det samme resultat. Kort fortalt bruger v1 tids- og nodeoplysninger, v2 er DCE Security-formatet, v3 udleder en UUID fra et navnerum og et navn ved hjælp af MD5, v4 er tilfældig, v5 udleder en UUID ved hjælp af SHA-1, v6 omarrangerer tidsbaserede data, v7 kombinerer et Unix-tidsstempel med tilfældige data, og v8 er beregnet til eksperimentelle eller leverandørspecifikke formater.

• Brug UUID v4 til post-id'er, uploadreferencer, id'er til API-anmodninger og testdata, hvor tilfældigt fordelte identifikatorer er velegnede.
• Brug UUID v5, når et bestemt navnerum og navn altid skal give den samme identifikator. Den er nyttig til gentagelige importer og regler for deduplikering.
• Overvej UUID v7, når posters identifikatorer i store træk skal følge oprettelsestidspunktet, og din database eller software understøtter formatet.
• Brug et almindeligt fortløbende heltal, når værdierne oprettes af én database, og kompakte nøgler med en naturlig rækkefølge er vigtigere end decentral generering.

Ældre versioner findes fortsat i eksisterende systemer, men i et nyt design bør valget baseres på de faktiske krav frem for at behandle alle UUID-versioner som indbyrdes udskiftelige.

Sådan bruger du UUID v4 i praksis

Generér en UUID, hent værdien fra resultatfeltet UUID v4, og gem hele den kanoniske tekstværdi, medmindre det modtagende system angiver en anden repræsentation.

1. Opret en ny UUID til det objekt eller den hændelse, der skal have en identitet.
2. Behold alle fem grupper og fire bindestreger, når UUID'en overføres mellem systemer.
3. Gem den med databasens UUID-type, hvis en sådan findes. Ellers skal du bruge et tekst- eller binærfelt med plads til den valgte repræsentation.
4. Tilføj en unik begrænsning, hvis databasen skal afvise dubletter blandt genererede UUID v4-værdier.

Typiske anvendelser er at identificere en ordre, før den når hoveddatabasen, sammenkæde logposter på tværs af flere tjenester, navngive et uploadet objekt eller tildele stabile id'er til rækker, der er klargjort til import. En UUID er ofte lettere at flette på tværs af uafhængigt oprettede datasæt end lokale heltalssekvenser, som kan indeholde de samme værdier i hver kilde.

Mellemrum, tegnsætning, bogstaver med diakritiske tegn og ikke-latinske tegn giver ikke problemer som input til UUID v4, fordi identifikatoren ikke udledes af tekst. Hvis du har brug for en identifikator baseret på et navn, der indeholder sådanne tegn, skal du bruge en navnebaseret UUID-metode og fastlægge den præcise tegnkodning og reglerne for normalisering. Ellers kan tekst, der ser ens ud, give forskellige bytesekvenser og dermed forskellige identifikatorer.

Kan to UUID v4-værdier være ens?

Ja, en kollision er teoretisk mulig, men ved almindelig brug af UUID v4 er det ikke et praktisk problem, når genereringen anvender en egnet kilde til tilfældighed. En v4-UUID har 122 variable bit, fordi de resterende bit angiver version og variant. Det efterlader et ekstremt stort antal mulige værdier.

"Universelt unik" er derfor en praktisk beskrivelse, ikke en matematisk garanti. Værdier, der ved en fejl kopieres eller genbruges, implementeringsfejl eller dårlig generering af tilfældige tal på grund af en utilstrækkelig tilfældighedskilde kan give en mere realistisk risiko for dubletter end tilfældigheder alene. Systemer, der ikke kan acceptere dubletter, bør stadig håndhæve unikhed i databasen eller applikationen.

En UUID beviser heller ikke, at en anmodning er ægte. Brug ikke en synlig UUID som eneste grundlag for autorisation, og gå ikke ud fra, at et objekt er beskyttet, blot fordi dets adresse er svær at gætte. Adgangskontrol skal gælde for den underliggende ressource, som UUID'en henviser til.

Ofte stillede spørgsmål

Er der forskel på store og små bogstaver i en UUID?

Nej, hexadecimale bogstaver i en UUID behandles normalt uden hensyn til store og små bogstaver, så A og a repræsenterer den samme værdi. Små bogstaver er den sædvanlige kanoniske skrivemåde. Ved at normalisere bogstaverne før en tekstsammenligning undgår du uens resultater i systemer, der skelner mellem store og små bogstaver ved sammenligning af tekstværdier.

Kan jeg bruge en UUID v4 i en URL eller et filnavn?

Ja, den kanoniske form bruger hexadecimale tegn og bindestreger, som alle er velegnede til almindelige URL-stisegmenter og udbredte filsystemer. Undlad at tilføje krøllede parenteser, medmindre et bestemt API kræver dem, og husk, at en ressource ikke bliver privat, fordi dens UUID vises i en URL.

Skal jeg fjerne bindestregerne fra en UUID?

Fjern dem kun, hvis det modtagende format udtrykkeligt forventer 32 hexadecimale tegn. Mange biblioteker og UUID-typer i databaser accepterer den kanoniske form med bindestreger. Den er lettere for mennesker at genkende og bliver ikke så let forvekslet med en anden hexadecimal værdi.

Kan en UUID v4 bruges som adgangskode eller API-hemmelighed?

Nej, en identifikator og en hemmelig værdi tjener forskellige formål. Nogle UUID-implementeringer bruger muligvis egnet tilfældighed, men UUID-formatet garanterer ikke i sig selv den håndtering, hemmeligholdelse eller entropi, som adgangskoder, sessionstokens og API-legitimationsoplysninger kræver. Generér legitimationsoplysninger og tokens med en mekanisme, der er beregnet til formålet, ikke med en UUID v4 generator.

Kan en UUID v4 være en personoplysning efter EU's GDPR?

Ja, den kan være en personoplysning, hvis den identificerer eller kan knyttes til en identificerbar person, selv om tegnene ikke direkte afslører et navn. Behandl UUID'er, der er knyttet til kundekonti, enheder eller aktivitetsregistre, i overensstemmelse med sammenhængen og organisationens regler for opbevaring og adgang.

Kan jeg bruge UUID v4 som primærnøgle i en database?

Ja, mange databaser understøtter UUID'er direkte som primærnøgler. Tilfældigt fordelte nøgler kan medføre mindre lokaliseret indsættelse i indeks end ordnede heltalsbaserede eller tidsbaserede identifikatorer, så læs databasens anbefalinger for tabeller med mange skriveoperationer. Bevar en unik begrænsning, og brug den samme lagerrepræsentation konsekvent i importer, forespørgsler og applikationskode.