Hejsan alla

Skulle vilja tillverka ett unikt ID till de personer jag lägger in i en arraylist. Hade bara tänkt en enkel sak som att använda personnr som bas (är ju unikt för alla) och omvandla det till någonsorts tal ex hex eller en hash (men verkade bli alltför många siffror) och använda detta som en slags kundID istället för personnr. Någon som vet hur jag omvandlar min long som innehåller personnummret till hex och omvandlar det till en sträng? eller finns det andra snygga lösningar (gör det förmodligen, så fort jag kommer på något så finns det bättre sätt hehe :))

Tackar på förhand,

/Andy

Var för inte använda dig av ett Guid

Det kommer garanterat vara unikt över hela världen om datorn har ett nätverkskort i sig.

Guid uniqueId = Guid.NewGuid()

- Magnus

Magnus,

Det är inte helt sant att de är unika i hela världen. Det har hänt några gånger att dessa IDn kan bli samma. Dock kan man nästan garantera att de är 100% unika under ens egna applikation. Även där har
jag en gång stött på en dublett.

Mvh Johan

Andreas...

Hur menar du med att ange unikt id för de användare du lägger i en arraylist? Är det unika IDt du skall ha i arraylisten eller är det användarna som ligger där?

Lite intresserad av vad det är du egentligen söker. Har du lust att föklara lite mera?

Mvh Johan

Lessen om jag bryter in i diskussionen här, men det där med Guid:t är jag lite fundersam på. Vad jag minns så är de generererade utifrån datorns serienummer, datum, och tid ner till tusendelar. Om två ska få samma GUID så måste de alltså ha samma serienummer och ha anropat funktionen exakt samma millisekund (bland annat).

Naturligtvis kan man fejka ett sådant ID, och då är det ju klart att det kan bli konflikter, men att det spontant skulle bli dubletter har jag väldigt svårt att föreställa mig. Någon referens där man har utrett det?

Niklas.

Eftersom de byggs upp av en algoritm baserat på flera olika faktorer så kan man utan tveckan ha ett annat makins id eller liknannde och på en viss tid bla bla få ett värde som någon annan fått.
1+5 = 6
0+6 = 6
3+3 = 6
2+4 = 6
4+2 = 6
...
Men som sagt det är rätt ovanligt, men kan hända så jag skulle inte kalla det unikt i hela världen.

Mvh Johan

det ska vara gjort utifrån
tid med stor nogranhet, mac-adress, någon sorts saker för att ta han om tidszoner + något annat om jag inte minns fel

GUID:
Short for Globally Unique Identifier, a unique 128-bit number that is produced by the Windows OS or by some Windows applications to identify a particular component, application, file, database entry, and/or user. For instance, a Web site may generate a GUID and assign it to a user's browser to record and track the session. A GUID is also used in a Windows registry to identify COM DLLs. Knowing where to look in the registry and having the correct GUID yields a lot information about a COM object (i.e., information in the type library, its physical location, etc.). Windows also identifies user accounts by a username (computer/domain and username) and assigns it a GUID. Some database administrators even will use GUIDs as primary key values in databases.
GUIDs can be created in a number of ways, but usually they are a combination of a few unique settings based on specific point in time (e.g., an IP address, network MAC address, clock date/time, etc.).

Mvh Johan

Jag är ändå inte med på att det skulle bli så. 128 bitar räcker väl till att representera all den informationen?
Då hade det ju räckt att slänga på allt utan att koda det på något sätt, typ:
2004-08-21|13:45:12.135|123456789

Och då har man ju hela grejen, den kommer inte att krocka med någon förutsatt att den inte genereras förutsatt att man inte har samma MAC-adress, etc.

Är det så att den kan hålla tillräckligt med data så är det ju en väldigt dåligt konstruerad algoritm om två stycken med helt olika indata krockar.

Med en snabb överslagsräkning.
Låt säga att vi har 16 bitar för att representera datumet. Det räcker för nästan 180 år.
Tiden ner till millisekunder på ett dygn klarar vi med 27 bitar. Alltså går hela tids-delen utan problem in i 48 bitar.

Sen har vi en MAC-adress. Den är väl på 48 bitar, vad jag kunde ana av det jag såg på internet. Det ger oss 32 bitar kvar för något annat. Alltså; om vi har bestämt exakta punkten i tiden, ner till millisekunder, och även vet exakt vilken Mac-adress det är gjort på, så har vi två miljarder olika val av GUID att välja mellan.

Jag har ärligt talat väldigt svårt för att tro att det skulle kunna komma dubletter, såvida inte MS har skrivit en onödigt korkad algoritm för det.

Niklas...

Har för mig jag läste om en miss i algoritmen, men är ej säker, vet bara att jag en gång fick samma.
Tänk om Mac-Adressen hade vart 6 och datumet ger en tick på 6 sedan lägger de ihop detta och får 12 så kan man ju med en Mac Adress som har 3 få ett datum som ger 9 de ihop blir 12 alltså samma ID.

Men precis som du säger det händer inte ofta, och det är nog lika sannolikt att en GUID har en deublett i sitt egna system som en tornado sklulle skapade ett viggen då den blåser genom en skrothög.

Det jag syftar på är att den inte är world wide unik. Tänk dig en databas med miljoner poster i ett system, det finns hundra tusen applikationer med minst lika många poster sokm använder GUIDs. Någonstans måste samma GUID finnas två ggr. Vad jag vill säga är att man skall vara lite förisktig med att säga att den är unik i hela världen och inte kan ha en dublett. Undrar om inte den otroligt dåliga .Net säkherhetsboken från Wrox pratar om detta?

Jag använder Guids ofta så jag är inte emot dem, dock är jag lite försiktg när jag bygger SOA apps, där försöker jag alltid hitta någon annan identifierare, har dock bara byggt transaktioner med Adressuppgifter och har då haft personnummer eller Organisationnummer som jag kunnat nyttja utan risk. Jo vet du förresten om Personummer är unika? Vi har ju typ 780309-56** vet du eller har du hörttalas om att någon kan ha samma som en själv?

Mvh Johan

Förutsatt att det inte är en bugg i algoritmen så gör ju faktumet att MAC-adressen används för att skapa ett GUID att det är unikt för datorn. Ifall bara ett GUID är unikt på en viss dator så innebär det också att det är unikt i hela världen.

MAC-adressen är 24 bitar och består av 12 bitar som är unika för tillverkaren av nätverkskortet och 12 bitar som är ett löpnummer.

Personnummer är unika. De fyra sista siffrorna består av en kod för födelseplats (två siffror), ett löpnummer (en siffra) och en kontrollsiffra.

<b>Personnummer är unika. De fyra sista siffrorna består av en kod för födelseplats (två siffror), ett löpnummer (en siffra) och en kontrollsiffra.</b>

så den som blir född som nummer 10 på en dag får 5 sista siffror? ;)

//Roger

"Det jag syftar på är att den inte är world wide unik. Tänk dig en databas med miljoner poster i ett system, det finns hundra tusen applikationer med minst lika många poster sokm använder GUIDs. Någonstans måste samma GUID finnas två ggr."
Det är ju det jag menar att det inte måste, att 128 bitar räcker för alla i hela världen. Det är ju bara att kolla på den lilla uträkningen jag gjorde. För varje millisekund får man ett nytt nummer, och för varje MAC-adress får man ett nytt nummer. Skulle två GUID bli samma (i okodad form) så skulle de behöva skapas samma millisekund, på datorer som skulle ha samma MAC-adress, och dessutom skulle de behöva ha samma 32 bitar som är kvar (alltså en chans på 2 miljarder, förutsatt att allt det andra stämmer, vilket är ytterst otroligt.)
Alltså - det _måste_ ju knappast finnas två som är lika.

"Har för mig jag läste om en miss i algoritmen, men är ej säker, vet bara att jag en gång fick samma.
Tänk om Mac-Adressen hade vart 6 och datumet ger en tick på 6 sedan lägger de ihop detta och får 12 så kan man ju med en Mac Adress som har 3 få ett datum som ger 9 de ihop blir 12 alltså samma ID."

Jo, men det var just det jag menade. Det behövs egentligen ingen algoritm, det hade kunnat sparas i klartext, konkatenerat, och då hade det aldrig blivit några problem. Naturligtvis förstår jag att en algoritm kan ge upphov till samma resultat; tycker bara att det är en jäkligt dåligt att man slänger upp en så stor grej (128 bitar) som egentligen utan problem kan hålla hur länge som helst, men ändå gör en sån miss...

Nilklas...

Jo visst, men nu råkar det vara så att samma Id kommit två gånger hur unikt det än skall vara. Tror to m. att det sägs att man inte skall ta GUID för givet som unikt i hela världen där ett nummer inte redan kan finnas. Det säger att den skall vara, men ingen säger direkt att den är.

Sedan kan man manipulera om man vill och för hand skapa ett identiskt id, finns ju sådana stollar :-)

Vill även påpeka att den inte använder MAC adressen längre som den gjorde förr.

Näää något unitk 100% world wide finns inte, men den är tillräckligt unik för många sammanhang och det är som du säger chansen att träffa på en dublett är extremt minimal, nästan omöjlig.
Men chansen finns.
Samma med hashning, det är många som hävdar att man inte kan få samma hashvärde ur två olika värden, men de har fel.

Nog pratar om det, jag är nu nyfiken hur lösningen blev för problemet.

Mvh Johan

>><b>Personnummer är unika. De fyra sista siffrorna består av en kod för födelseplats (två siffror), ett löpnummer (en siffra) och en kontrollsiffra.</b>

><b>så den som blir född som nummer 10 på en dag får 5 sista siffror? ;)</b>

Tidigare (före 1990) användes de första två siffrorna för att visa vilket län man är född i (t ex hade Kalmar siffran 29), men det har ändrats och numera är det en gemensam serie för hela landet. Det uppstår alltså inte problem förrän 500 pojkar eller flickor föds på samma dag...

Näst sista siffran (löpnumret) är alltid udda för män och jämn för kvinnor. Klippt från Riksskatteverkets hemsida :
<info>
Från och med år 1990 tilldelas födelsenumren slumpvis ur en serie som är gemensam för hela landet. Tidigare användes en särskild nummerserie för varje län. De enda uppgifter som kan utläsas ur ett personnummer är födelsetid och kön.
</info>
Följande dokument beskriver det i mer detalj : http://www.rsv.se/broschyrer/704/70407.html