Yüklenen resimleri adlandırmak için en iyi yöntem nedir?

Web uygulamamda kullanıcıların profil resmi yükleyebilecekleri bir formum olduğunu varsayalım.

Dosya boyutu, boyutları vb. İle ilgili birkaç gereksinimim var, ancak kullanıcı resmi yüklediğinde bunları sistemime nasıl adlandırmalıyım? Herhalde tutarlı ve benzersiz olması gerekir.

Belki bir GUID?

a5c627bedc3c44b7ae7c06a44fb3fcf8.jpg

Zaman damgası mı?

129899740140465735.jpg

Bir karma mı? Örn: md5

b1a9acaf295cf14ffbc5b6538294562c.jpg

Bunu yapmanın standart veya önerilen bir yolu var mı?

İki hedefe ulaşmaya çalışmalısınız: Benzersizlik ve kullanışlılık.

Bir GUID kullanmak benzersizliği garanti eder, ancak bir gün dosyalar orijinal kaynaklarından ayrılabilir ve sorun yaşarsınız.

Tipik çözümüm, userID (bir kullanıcıya aitse) veya yüklenen tarih ve saat (eğer bu önemliyse) gibi dosya adına veya yüklerken kullanılan dosya adına gömülü bilgileri yerleştirmektir.

Bu, dosya adına gömülü olan bilgilerin örneğin bir hatadan kurtulmanıza veya kayıtların yanlışlıkla silinmesine izin verdiğinde, bir gün cildinizi gerçekten kurtarabilir. Tek sahip olduğunuz GUID'lerdir ve kataloğu kaybederseniz, bunu temizleyen bir işiniz olur.

Örneğin, "My Holiday: Florida 23.jpg" dosyası 2013/04/04 saat 12:51:23 tarihinde userID 98765 tarafından yüklenirse, rastgele bir dize ekleyerek şöyle bir şey söylerdim ad8a7dsf9:

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

• Benzersizlik, tarih ve saat ve rastgele dize (/ dev / urandom veya CryptGenRandom'dan düzgün rasgele olması şartıyla) sağlanır.
• Dosya hiç ayrılmazsa kullanıcıyı, tarihi, saati ve başlığı tanımlayabilirsiniz.
• Her şey küçük harfe katlanır ve alfasayısal olmayan herhangi bir şey kaldırılır ve çizgilerle değiştirilir, bu da dosya adının basit araçlar kullanılarak işlenmesini kolaylaştırır (örneğin, kötü yazılmış komut dosyalarını karıştırabilecek boşluklar yok, sütunlar veya bazı dosya sistemlerinde yasaklanmış diğer karakterler yok) , ve bunun gibi).

Dizini açtığınızda uygulamaları (Explorer gibi) vurgulamak ve çökmesini istemezsiniz. Gerçek dosya sistemini vurgulamanız pek olası olmasa da, binlerce dosyayı saklayacaksanız bunu dikkate almanız gerekir.

Binlerce dosyayı saklamayı bekliyorsanız önerim klasörlere bölümlemektir. Örneğin upload\silo001, upload\silo002vb Ya dosyalarınızı dengelemek veya klasör dosyaları belirli sayıda vurur kadar bekleyin ve sonra başka oluşturabilir.

Adlandırma konusunda, bir dosyayı her zaman GUID ile adlandırıyorum çünkü global olarak benzersiz. Yüklemeden uzantıyı alıyorum ve dosyanın uzantısını eşleşecek şekilde ayarladım, ancak gerçek ad yeni bir Rehberden ayarlanır.

Eğer bir RDBMS ile birlikte bu yapıyor ve vb birkaç kategori, yani Ürünler, kategoriler var ediyorsanız olabilir upload\products, upload\categoriesve benzeri, ve dosya adı olarak satır kimliğini kullanabilirsiniz.

En iyi uygulamalar açısından ben de geçmişe baktım ve hiçbir şey bulamadım. Bazı geliştiricilerimle tartışırken yukarıdakileri buldum.

Yıllar önce çalıştığım çözümlerden birinde şunu yaptık: kullanıcı kimliğinizin bir kısmı için alt klasörler, böylece kullanıcı kimliğiniz 232950192

alt klasörlerimiz olurdu / 23/29/50/192/232950192

son klasörde albümler ve profil imgs vb için klasörler var

Ancak her şeyi veri tabanına da kaydediyoruz ve hızlı web sunucusu erişimi için dosya sisteminde tutuyoruz (önbellekleme de var)

Her neyse, son görüntünün orijinal görüntü adı olurdu. Sürümleri tutmamız gerekmiyordu. Ancak, son albüm adlarının altında veya sürüm kimliğine sahip veri tabanında daha fazla alt klasörü nelerin tutabileceği için. üretime geçtiğinde, mevcut yapıda zaman alıcı ve hata eğilimli düzeltmeler olmadan bir şeyleri değiştirmek zor olacağını düşünmek gerekir

Java'da bir alt klasör oluşturmak ve içinde bir dosya oluşturmak çok kolaydır:

    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

Alt klasörlerde tarih damgası almak için: SimpleDateFormat sdf = new SimpleDateFormat ("/ yyyy / MM / dd /"); pathwithslashes = pathwithslashes + sdf.format (şimdi); // şimdi bir util.Date File klasörü = new File (pathwithslashes);

Nokta ağı /programming/5482230/c-sharp-equivalent-of-javas-mkdirs

Sadece md5 veya kavramsal olarak eşdeğer bir şey kullanmanızı tavsiye ederim. Dosyaları içeriği sindirerek yeniden adlandırarak, yalnızca benzersizlik vermezsiniz (görüntüleri her zaman mümkün olduğunca uzun süre önbelleğe alırsınız ve içerik tabanlı yeniden adlandırma ile, uygun olanla görüntüleri neredeyse sonsuza kadar önbelleğe alabilirsiniz).

Ayrıca, büyük bir anlaşma değil, ancak yine de farklı kullanıcılar tam olarak aynı görüntüyü yüklediğinde saf bir varsayımsal durum değildir. Kutudan çıkar çıkmaz küçük bir veri depolama optimizasyonu elde edersiniz.

Önerilen her şeye gelince: Bana gelince, her türlü yardımcı bilgiyi bir dosya adında tutmanın güçlü bir rakibiyim . Ben çok daha gençken (ve biraz daha ince :), bir Perl geliştiricisi oldum ve Perl string desen özellikleri harika olduğundan, dosya adında yardımcı bilgi kadar bana yardımcı olarak çok fazla yardımcı bilgi saklamak için şüpheli bir alışkanlık vardı. Ve ben web geliştirme söz, dosya ile ilişkili verileri dosya adından ayrı tutmak her zaman daha iyi bir seçim olduğu sonucuna vardım .

Günümüzde, mobil arayüzler baskın olduğunda, gerçek dosya adının 5, 10 yıl önce daha az önemli bir şey olduğunu unutmayın. Ancak bu, uygulamanız bağlamında önemli olsa bile, istediğiniz zaman Content-Disposition: attachment; filename="pretty_file_name.jpg"herhangi bir ilgili dosya adını oluşturarak HTTP başlığını dahil etmekle her zaman eski okul büyüsünü dahil edebilirsiniz . Ayrıca, modern tarayıcılar yeni HTML5 özniteliğini indirmenin yolunu açıyor . Aslında "insan tarafından okunabilir" görüntü adını görmenin çoğu durumda düşünmeniz gereken bir şey olduğuna inanmıyorum.

UPD: Bir dizinde çok fazla dosya olmaması için bir değişiklik yapılabilir - sadece ilk 3 harfi alın ve dir oluşturun.

Sha4 gibi bir şeyle çarpışma olasılığı sonsuzdur. Karma kullanıcı kimliği veya hatta basit bir tarih ile birleştirirseniz, daha da az.