Qual è la migliore pratica per nominare le immagini caricate?

Dovresti provare a raggiungere due obiettivi: unicità e utilità.

L'utilizzo di un GUID garantisce univocità, ma un giorno i file potrebbero essere scollegati dalla loro fonte originale, e quindi ti troverai nei guai.

La mia soluzione tipica è incorporare le informazioni cruciali nel nome file, come l'ID utente (se appartiene a un utente) o la data e l'ora caricate (se questo è significativo), o il nome file utilizzato quando lo si carica.

Questo può davvero salvare la tua pelle un giorno, quando le informazioni incorporate nel nome del file ti permettono, per esempio, di recuperare da un bug, o la cancellazione accidentale dei record. Se tutto ciò che hai è GUID, e perdi il catalogo, avrai un lavoro da pulire.

Ad esempio, se un file "My Holiday: Florida 23.jpg" è caricato, da userID 98765, il 2013/04/04 alle 12:51:23 lo chiamerei qualcosa di simile, aggiungendo una stringa casuale ad8a7dsf9 :

20130404125123-ad8a7dsf9-98765-my-vacanza-florida-23.jpg

• L'unicità è assicurata dalla data e dall'ora e dalla stringa casuale (a condizione che sia casuale da / dev / urandom o CryptGenRandom.
• Se il file viene mai staccato, puoi identificare l'utente, la data e l'ora e il titolo.
• Tutto è ripiegato in minuscolo e qualsiasi cosa non alfanumerica viene rimossa e sostituita da trattini, il che rende il nome del file facile da gestire con strumenti semplici (ad es. nessuno spazio che possa confondere script mal scritti, niente due punti o altri caratteri che sono vietati su alcuni filesystem e così via).

Non vuoi stressare le applicazioni (come Explorer) e farlo schiantare quando apri la directory. Anche se è improbabile che tu sottolinei il file system attuale, devi tenerne conto se stai memorizzando migliaia di file.

Se ti aspetti di memorizzare migliaia di file il mio suggerimento è di partizionare in cartelle. Ad esempio upload\silo001 , upload\silo002 , ecc. Puoi bilanciare i file o attendere fino a quando una cartella raggiunge un certo numero di file e quindi crearne un'altra.

Per quanto riguarda la denominazione, nomino sempre un file con un GUID perché è globalmente unico. Estraggo l'estensione dal caricamento e imposta l'estensione del file in modo che corrisponda, ma il nome effettivo viene impostato da una nuova guida.

Se stai facendo questo in combinazione con un RDBMS e hai diverse categorie, ad es. prodotti, categorie, ecc. potresti avere upload\products , upload\categories e così via, e potresti usare l'ID di riga come nome file .

In termini di buone pratiche, anch'io ho guardato nel passato e non ho trovato nulla. Mi sono imbattuto in quanto sopra mentre discuto con alcuni dei miei sviluppatori.

In una delle soluzioni su cui ho lavorato anni fa abbiamo fatto questo: sottocartelle per parte dell'ID utente, quindi se il tuo ID utente era 232950192

avremmo immagini sottocartelle / 23/29/50/192/232950192

nella cartella finale hanno cartelle per albun e profilo imgs ecc.

Ma salviamo anche tutto nel database e lo manteniamo nel file system per un accesso rapido al server web (che ha anche il caching)

In ogni caso l'immagine finale avrebbe il nome dell'immagine originale. Non abbiamo bisogno di mantenere le versioni. Ma per quello che può tenere più sottocartelle sotto i nomi degli album finali o nel database con un id della versione. è necessario pensarlo come una volta che si passa alla produzione sarebbe difficile cambiare le cose senza perdite di tempo e correzioni soggette a errori nella struttura attuale

È molto facile creare una sottocartella in java e creare un file al suo interno:

    File folder = new File(pathwithslashes);// like "images/23/29/50/192/232950192"
    folder.mkdirs();
    File imgFile = new File(folder, name);
    //Now get output stream etc

Per ottenere il timbro della data nelle sottocartelle:         SimpleDateFormat sdf = new SimpleDateFormat ("/ yyyy / MM / dd /");         pathwithslashes = pathwithslashes + sdf.format (now); // ora è un util.Date         File folder = new File (pathwithslashes);

Dot net link

Consiglierei di usare solo md5 o qualcosa di concettualmente equivalente. Rinominando i file digerendone i contenuti non solo garantisci l'unicità (sempre le immagini della cache il più a lungo possibile, e con la ridenominazione basata sul contenuto, beh, con quella corretta, puoi memorizzare le immagini praticamente per sempre).

Inoltre, non è un grosso problema, ma tuttavia non è un caso puramente ipotetico quando diversi utenti caricano esattamente la stessa immagine. Avrai subito una piccola ottimizzazione per l'archiviazione dei dati.

Come per qualsiasi altra cosa proposta: per quanto mi riguarda, sono un strong oppositore di mantenere qualsiasi tipo di informazione ausiliaria in un nome di file. Quando ero molto più giovane (e un po 'più magro :), ero uno sviluppatore di Perl e avevo l'abitudine dubbia di memorizzare tante informazioni ausiliarie nel nome del file come mi ha permesso il buon senso, dal momento che le caratteristiche del pattern di stringa Perl sono fantastiche. E sono giunto alla conclusione che, parlando di sviluppo web, è sempre una scelta migliore per mantenere i dati associati al file separatamente dal nome del file.

Tenere presente che al giorno d'oggi, quando le interfacce mobili sono dominanti, il nome del file effettivo è una cosa meno importante di 5, 10 anni fa. Ma anche se questo sarà cruciale nel contesto della tua applicazione, puoi sempre coinvolgere qualche magia vecchia scuola con coinvolgendo Content-Disposition: attachment; filename="pretty_file_name.jpg" intestazione HTTP, costruendo qualsiasi nome di file rilevante che desideri. Inoltre, i browser moderni stanno aprendo la strada al nuovo attributo HTML5, download . Non credo che vedere il nome dell'immagine "leggibile" sia una cosa a cui dovresti pensare nella maggior parte dei casi.

UPD: È possibile apportare una modifica per non avere troppi file in una directory: basta prendere le prime 3 lettere e creare dir.

Le probabilità di collisioni con qualcosa come sha4 sono infinitesime. Se combini l'hash con l'ID utente o anche con una data semplice, ancor meno.