Generator ng UUID v4

Ang Generator ng UUID v4 ay isang libreng tool na gumagawa ng bersyon 4 na Universally Unique Identifier para gamiting identifier ng record, object o request.

Paano pinangangasiwaan ng Generator ng UUID v4 ang data ko?

Sa server ginagawa ang pagbuo ng UUID. Ipinapadala roon ang input sa pamamagitan ng HTTPS, at hindi ito iniimbak. Kaya hindi tumpak na sabihing sa browser mo lamang nagaganap ang buong proseso o hindi kailanman umaalis sa device mo ang data.

Hindi kailangan ng UUID v4 ang personal na text, pangalan o password bilang pinagmulan. Binubuo ito bilang identifier at hindi kinakalkula mula sa impormasyong ibinibigay mo. Huwag iugnay ang sensitibong kahulugan sa resultang value, dahil maaari itong kopyahin at gamitin muli ng sinumang makakakita rito.

Ano ang UUID v4?

Ang UUID v4 ay isang 128-bit na identifier. Random o pseudo-random na binubuo ang nababagong bahagi nito, habang nakalaan ang ilang bit para tukuyin ang bersyon at variant ng UUID. Karaniwan itong ginagamit kapag kailangang gumawa ng magkakahiwalay na system ng mga identifier nang hindi muna humihingi sa isang sentral na serbisyo ng susunod na available na numero.

Ang karaniwang nakasulat na anyo nito ay may 32 hexadecimal na character na hinati ng mga gitling sa limang grupo. Sinusunod nito ang pattern na 8-4-4-4-12 at may kabuuang 36 na character kapag isinama ang apat na gitling.

Isang halimbawang tama ang syntax ay 550e8400-e29b-41d4-a716-446655440000. Sa bersyon 4 na UUID, ang unang character ng ikatlong grupo ay 4. Ang dalawang pinakamataas na bit na tumutukoy sa variant ay 10, kaya ang unang hexadecimal na character sa ikaapat na grupo ay 8, 9, a o b.

Identifier ang value, hindi naka-encode na impormasyon. Hindi mo ito maaaring i-decode upang mabawi ang petsa ng pagkakagawa, pangalan ng account, address ng machine o sequence number.

Aling bersyon ng UUID ang dapat kong piliin?

Piliin ang bersyon 4 kung kailangan mo ng opaque na identifier na maaaring buuin nang hiwalay at hindi mo kailangang makuha ang parehong resulta mula sa parehong input. Sa madaling sabi, gumagamit ang v1 ng oras at impormasyon ng node, ang v2 ay anyong DCE Security, gumagawa ang v3 ng UUID mula sa namespace at pangalan gamit ang MD5, random ang v4, gumagamit ang v5 ng SHA-1 upang bumuo ng UUID, inaayos muli ng v6 ang time-based na data, pinagsasama ng v7 ang Unix timestamp at random na data, at nakalaan ang v8 para sa mga experimental o vendor-specific na format.

• Gamitin ang UUID v4 para sa mga record ID, upload reference, API request ID at test fixture kung angkop ang mga identifier na random ang distribution.
• Gamitin ang UUID v5 kapag kailangang laging makabuo ng parehong identifier ang isang partikular na namespace at pangalan. Kapaki-pakinabang ito para sa mga nauulit na import at panuntunan sa deduplication.
• Isaalang-alang ang UUID v7 kung kailangan ng mga record ng mga identifier na malawakang sumusunod sa oras ng pagkakagawa at sinusuportahan ito ng database o software mo.
• Gumamit ng karaniwang sequential integer kapag iisang database ang gumagawa ng mga value at mas mahalaga ang compact at likas na pagkakasunod-sunod ng mga key kaysa sa desentralisadong pagbuo.

Ginagamit pa rin sa mga kasalukuyang system ang mas lumang mga bersyon, pero sa bagong disenyo, pumili batay sa aktuwal na pangangailangan sa halip na ituring na maaaring pagpalit-palitin ang lahat ng bersyon ng UUID.

Paano gamitin ang UUID v4

Gumawa ng UUID, kunin ang value sa field ng resultang UUID v4, at iimbak ang buong canonical string maliban kung ibang representasyon ang hinihingi ng tatanggap na system.

1. Gumawa ng bagong UUID para sa object o event na nangangailangan ng identity.
2. Panatilihin ang lahat ng limang grupo at apat na gitling kapag ipinapasa ito sa iba't ibang system.
3. Iimbak ito sa UUID type ng database kung available iyon. Kung wala, gumamit ng text o binary field na may tamang laki para sa napiling representasyon.
4. Maglagay ng unique constraint kung kailangang tanggihan ng database ang magkakaparehong nabuong UUID v4.

Kabilang sa mga karaniwang gamit nito ang pagtukoy sa isang order bago ito makarating sa pangunahing database, pag-uugnay ng mga log entry sa iba't ibang serbisyo, pagpapangalan sa isang na-upload na object, o pagtatalaga ng mga stable ID sa mga row na inihanda para sa pag-import. Kadalasang mas madaling pagsamahin ang magkakahiwalay na ginawang data set gamit ang UUID kaysa sa mga lokal na integer sequence, na maaaring magkaroon ng magkakaparehong value sa bawat pinagmulan.

Hindi nagiging problematikong input sa UUID v4 ang mga espasyo, bantas, letrang may accent at non-Latin na character dahil hindi kinukuha sa text ang identifier sa proseso ng pagbuo. Kung kailangan mo ng identifier na nakabatay sa pangalang may ganitong mga character, gumamit ng name-based na UUID scheme at tukuyin ang eksaktong character encoding at mga panuntunan sa normalisation. Kung hindi, maaaring magkaroon ng magkaibang byte sequence ang text na magkamukha at, dahil dito, makabuo ng magkaibang identifier.

Posible bang magkapareho ang dalawang UUID v4?

Oo, posible sa teorya ang collision, pero hindi ito praktikal na alalahanin sa karaniwang paggamit ng UUID v4 kung angkop na random source ang ginagamit sa pagbuo. May 122 nababagong bit ang isang v4 UUID dahil ginagamit ang natitirang mga bit upang tukuyin ang bersyon at variant nito. Dahil dito, napakalaki ng hanay ng mga posibleng value.

Kaya ang "universally unique" ay praktikal na paglalarawan, hindi matematikal na garantiya. Mas makatotohanang panganib ng pagdodoble ang mga value na aksidenteng nakopya o nagamit muli, mga depekto sa implementation, o mahinang pagbuo ng random na numero kapag hindi sapat ang random source, kaysa sa purong tsansa lamang. Dapat pa ring magpatupad ng uniqueness sa database o application boundary ang mga system na hindi maaaring magkaroon ng duplicate.

Hindi rin patunay ang UUID na tunay ang isang request. Huwag gumamit ng nakikitang UUID lamang bilang awtorisasyon, at huwag ipalagay na protektado ang isang object dahil lang mahirap hulaan ang address nito. Dapat ilapat ang mga access check sa mismong resource na tinutukoy ng UUID.

Mga madalas itanong

Case-sensitive ba ang mga UUID?

Hindi. Karaniwang hindi isinasaalang-alang ang laki ng titik sa mga hexadecimal na letra sa text ng UUID, kaya iisang value ang kinakatawan ng A at a. Lowercase ang karaniwang canonical na presentasyon. Ang pag-normalise ng case bago paghambingin ang text ay nakaiiwas sa hindi magkakatugmang resulta sa mga system na case-sensitive maghambing ng mga string.

Pwede bang gumamit ng UUID v4 sa URL o pangalan ng file?

Oo. Hexadecimal na mga character at gitling ang ginagamit sa canonical na anyo, at ang lahat ng ito ay angkop sa karaniwang URL path segment at mga karaniwang file system. Huwag magdagdag ng mga brace maliban kung kinakailangan ng isang partikular na API, at tandaan na hindi nagiging pribado ang resource dahil lamang inilagay ang UUID sa URL.

Dapat ko bang alisin ang mga gitling sa UUID?

Alisin lamang ang mga ito kung tahasang nangangailangan ang tatanggap na format ng 32 hexadecimal na character. Tinatanggap ng maraming library at database UUID type ang canonical na anyong may mga gitling. Mas madali rin itong makilala ng tao at mas maliit ang posibilidad na mapagkamalang ibang hexadecimal na value.

Pwede bang gawing password o API secret ang UUID v4?

Hindi. Magkaiba ang layunin ng identifier at secret. Maaaring gumamit ng angkop na randomness ang ilang UUID implementation, pero hindi ginagarantiya ng mismong format ng UUID ang mga kinakailangan sa pangangasiwa, pagiging lihim o entropy ng mga password, session token at API credential. Gumawa ng mga credential o token gamit ang mekanismong sadyang dinisenyo para roon, hindi gamit ang Generator ng UUID v4.

Maaari bang ituring na personal information ang UUID sa ilalim ng Data Privacy Act?

Oo, maaari itong maging personal information kapag tinutukoy nito o maaaring iugnay sa isang taong matutukoy, kahit hindi direktang ipinapakita ng mga character ang pangalan. Pangasiwaan ang mga UUID na nakakabit sa mga customer account, device o record ng aktibidad ayon sa konteksto at sa mga panuntunan ng organisasyon sa retention at access.

Pwede bang gawing primary key sa database ang UUID v4?

Oo, maraming database ang direktang sumusuporta sa mga UUID primary key. Maaaring magdulot ang mga key na random ang distribution ng mas hindi nakalokalisang index insertion kaysa sa mga ordered integer o time-based na identifier, kaya tingnan ang gabay ng database para sa mga table na maraming write operation. Panatilihin ang unique constraint at gumamit ng iisang pare-parehong storage representation sa mga import, query at application code.