I've got a problem. I been using MD5 hash as the name for images, but it's too damn long. What would you guys suggest as a shorter alternative solution?
Are you aware the MD5 hash of an image bears no relation to any potential, natural, or possibly inferred "ordering" of images and that it is indeed debatable whether or not there even exists an ordering mechanism for images that a human would appreciate?
How about a descriptive naming scheme with a decent folder hierarchy?
Name:
Anonymous2009-09-14 4:45
why not just use a number that's incremented for each file?
seems like the sensible thing to do
If your database can't handle a 128-bit number, I suggest you move to another, stat.
That said, you really ought to be using a non-broken hashing algorithm for any new application.
>>2
Sorry! I used the wrong term, I did not mean sorting. Just for the sake of giving them a unique identifier.
>>4
Has nothing to do with the database, just my own personal preference for naming my files. I just wanted something shorter and fixed-length because it looks less pig disgusting.
>>12 less cryptic and easy if you want to sort your pic by date
That's just too stupid. When you upload an image, it is created in the server. You can simply sort by creation time and you've got the same feature. OP has to consider things like, how it will look as a link (http://.../1839128398120983912083921.jpg isn't likable)
>>17
Yes, in theory, if you have two images, the chances of the two images having the same hash might be 2³². Now, what if you have three images? Or four? Or 10000?
>>23
I wouldn't do this if I were you. If you're going to use a 1-byte hash, there's probably a faster way of calculating it than md5. For example, you could do something like this :
If you used a base64 representation of the hash instead of hexadecimal, it would only be 22 characters instead of 32. Still pretty long, though.
In your case, you only want the IDs to be unique, so you can just use an incrementing counter. (MD5's only benefit here¹ is that it produces IDs which aren't sequential, which you don't need.)
>>17
Birthday paradox. ❝The birthday problem in this more generic sense applies to hash functions: the expected number of N-bit hashes that can be generated before getting a collision is not 2N, but rather only 2N/2❞.
Yes, you expect a collision after 216 = 65536 items. Enjoy your collisions, Patrick.
_____
¹ Probably. Too lazy to think of any others.
>>37
But.. you're wrong. Unix time is only 10 characters. Filenames on 4chan are 13 chars because the last 3 chars are there in case two files are uploaded at the same time.
Name:
Anonymous2009-09-14 19:56
just a simple increment. That's all you need.
Name:
Anonymous2009-09-14 20:06
Use the full contents of the file as an ID.
Name:
Anonymous2009-09-15 18:51
>>43
Some sort of reversible AND unique hash?
BRILLIANT!
Name:
Anonymous2009-09-15 20:04
>>41
I always assumed the last three numbers were milliseconds.
Name:
Anonymous2009-09-15 21:19
the number of bytes in the file converted to base36
Name:
Anonymous2009-09-15 21:23
>>46
actually, why not just use MD5 instead?
assuming you're using a hex string representation of the hash value, converting that to base 36 effectively halves its length.
>>49
Insomuch that most OS's don't have a file system at all. But the ones that do, including all the most popular desktop and server OS's, tend to be permissive to a fault, requiring you only to escape somewhere between one and a dozen control characters.