Come creare guide deterministiche

Nella nostra applicazione stiamo creando file Xml con un attributo che ha un valore Guid. Questo valore doveva essere coerente tra gli aggiornamenti dei file. Quindi, anche se tutto il resto nel file cambia, il valore guid per l'attributo dovrebbe rimanere lo stesso.

Una soluzione ovvia è stata creare un dizionario statico con il nome del file e le guide da utilizzare per loro. Quindi ogni volta che generiamo il file, cerchiamo nel dizionario il nome del file e utilizziamo il guid corrispondente. Ma questo non è fattibile perché potremmo scalare fino a centinaia di file e non volevamo mantenere un lungo elenco di guide.

Quindi un altro approccio è stato quello di rendere il Guid lo stesso in base al percorso del file. Poiché i nostri percorsi dei file e la struttura della directory dell'applicazione sono univoci, il Guid dovrebbe essere univoco per quel percorso. Quindi ogni volta che eseguiamo un aggiornamento, il file ottiene lo stesso guid in base al suo percorso. Ho trovato un modo fantastico per generare tali " Guide deterministiche " (Grazie Elton Stoneman). Fondamentalmente fa questo:

private Guid GetDeterministicGuid(string input) 

{ 

//use MD5 hash to get a 16-byte hash of the string: 

MD5CryptoServiceProvider provider = new MD5CryptoServiceProvider(); 

byte[] inputBytes = Encoding.Default.GetBytes(input); 

byte[] hashBytes = provider.ComputeHash(inputBytes); 

//generate a guid from the hash: 

Guid hashGuid = new Guid(hashBytes); 

return hashGuid; 

} 

Quindi data una stringa, il Guid sarà sempre lo stesso.

Esistono altri approcci o modi consigliati per farlo? Quali sono i pro o i contro di questo metodo?

Come menzionato da @bacar, RFC 4122 §4.3 definisce un modo per creare un UUID basato sul nome. Il vantaggio di fare questo (rispetto al solo utilizzo di un hash MD5) è che è garantito che questi non entrino in collisione con UUID non basati su nome e hanno una (molto) piccola possibilità di collisione con altri UUID basati su nome.

Non c'è supporto nativo in .NET Framework per la creazione di questi, ma ho pubblicato del codice su GitHub che implementa l'algoritmo. Può essere utilizzato come segue:

Guid guid = GuidUtility.Create(GuidUtility.UrlNamespace, filePath);

Per ridurre ulteriormente il rischio di collisioni con altri GUID, è possibile creare un GUID privato da utilizzare come ID spazio dei nomi (invece di utilizzare l'ID spazio dei nomi URL definito nella RFC).

Questo convertirà qualsiasi stringa in un Guid senza dover importare un assembly esterno.

public static Guid ToGuid(string src)
{
    byte[] stringbytes = Encoding.UTF8.GetBytes(src);
    byte[] hashedBytes = new System.Security.Cryptography
        .SHA1CryptoServiceProvider()
        .ComputeHash(stringbytes);
    Array.Resize(ref hashedBytes, 16);
    return new Guid(hashedBytes);
}

Esistono modi molto migliori per generare un Guid univoco, ma questo è un modo per aggiornare in modo coerente una chiave dati stringa a una chiave dati Guid.

Come menziona Rob, il tuo metodo non genera un UUID, genera un hash che assomiglia a un UUID.

L' RFC 4122 sugli UUID consente specificamente UUID deterministici (basati sul nome) - Le versioni 3 e 5 utilizzano md5 e SHA1 (rispettivamente). La maggior parte delle persone ha probabilmente familiarità con la versione 4, che è casuale. Wikipedia offre una buona panoramica delle versioni. (Si noti che l'uso della parola "versione" qui sembra descrivere un "tipo" di UUID - la versione 5 non sostituisce la versione 4).

Sembra che ci siano alcune librerie là fuori per la generazione di UUID versione 3/5, incluso il modulo uuid python , boost.uuid (C ++) e OSSP UUID . (Non ho cercato nessuno .net)

È necessario fare una distinzione tra istanze della classe Guide identificatori che sono globalmente univoci. Un "guid deterministico" è in realtà un hash (come evidenziato dalla tua chiamata a provider.ComputeHash). Gli hash hanno una probabilità molto maggiore di collisioni (due stringhe diverse che producono lo stesso hash) rispetto a Guid creato tramite Guid.NewGuid.

Quindi il problema con il tuo approccio è che dovrai accettare la possibilità che due percorsi diversi producano lo stesso GUID. Se hai bisogno di un identificatore univoco per una determinata stringa di percorso, la cosa più semplice da fare è semplicemente usare la stringa . Se hai bisogno che la stringa venga oscurata dai tuoi utenti, crittografala : puoi usare ROT13 o qualcosa di più potente ...

Il tentativo di inserire qualcosa che non è un GUID puro nel tipo di dati GUID potrebbe portare a problemi di manutenzione in futuro ...

MD5 è debole, credo che tu possa fare la stessa cosa con SHA-1 e ottenere risultati migliori.

A proposito, solo un'opinione personale, vestire un hash md5 come GUID non lo rende un buon GUID. I GUID per loro stessa natura non sono deterministici. questo sembra un imbroglio. Perché non chiamare semplicemente un picche un picche e dire semplicemente che è una stringa resa hash dell'input. puoi farlo usando questa linea, piuttosto che la nuova linea guida:

string stringHash = BitConverter.ToString(hashBytes)