Génération d'un identifiant unique - Page 1

Etant en train de créer un site permettant d'upper des images, je me retrouve face à un léger problème. En effet, je souhaite que chaque image uppée soit enregistrée dans une table MySQL mais pour cela il faut que je lui donne un identifiant unique.

La solution la plus simple semble être d'utiliser le nom de l'image comme identifiant unique mais on s'aperçoit rapidement qu'avec les nouveaux appareils photos numériques, le nom des photos est souvent le même ... ce système entrainerait donc des refus assez fréquemment sous prétexte que "L'image sélectionnée est déja existante : Merci de la renommer".

Ce site ayant pour cible un public assez nul en informatique , j'aimerai que l'interface permettant l'upload se charge de résoudre tous les problèmes. La seule solution que je vois à mon problème est donc de renommer les images que l'utilisateur vient d'upper et dont le nom existe déja dans la base de donnée. Malheureusement, je n'arrive pas à trouver de moyen simple permettant la génération d'un nom unique si ce n'est le fait d'appeler chaque image de la même façon : Par exemple "img_X.jpg" où X serait un nombre entier enregistré dans une table à part qui s'incrémenterai à chaque upload d'images..

Si il y a des solutions plus simples et qui évite d'enregistrer une variable d'incrémentation je suis à votre écoute. Merci

en utilisant un champ integer, auto_increment comme clef primaire de ta table ?
en gros, en ayant dans ta table :
- un champ auto_increment, clef primaire
- un champ nom original de l'image
- des champs pour les droits, le propriétaire, ... ça c'est ton problème

à l'upload, tu insére un enregistrement dans la table
tu récupére la dernière valeur de l'auto_increment (qui fait valeur = valeur + 1 à chaque ajout), et tu renommes ton fichier comme ça
et tu garde le nom d'origine dans la table, pour l'afficher à l'utilisateur - plus parlant que numéro.jpg ^^

(enfin, c'est juste une idée sans réfléchir ^^ )
(et y'a une variable d'incrémentation - mais gérée automatiquement par la base de données)

Bin tu peux te servir en interne de la date systeme + du nom de user + de son album et eventuellement tu hash tout ca avec un md5 afin de rendre la chose le plus aleatoire possible afin qu'il n'y ait jamais de doublons.

Ou alors tu utilises le timestamp pour renommer l'image (Voire même microtime())

Ok en gros ce sont les méthodes que j'avais en tête. En ce qui concerne l'upload d'images j'ai autre problème. L'augmentation des qualités de photo provoque inévitablement une augmentation de la taille en mémoire (en octet). Malheureusement certaines connections à Internet ne permettent pas l'envoi d'une dizaine de photos pesant prés de 2Mo chacune. Existe t'il un moyen de transmettre des fichiers zippés qui pourront être dézippé sur le serveur. Et existe t'il un programme qui redimmendionnerait par exemple chaque images supérieure à 300Ko automatiquementet dans une taille toujours identique?

Petit rappel : le public visé est novice en informatique

Tu peux sûrement dézipper des fichiers en lançant une commande externe avec PHP, pour redimensionner ou recompresser une image, il y a GD.

de toutes façons, zipper une photo (en jpeg) ne sert à rien, l'image est déjà compressée, tu ne gagnerais que quelques centaines d'octets
si tu veux réduire sa taille (en octets) tu dois réduire ses dimensions,a mais je sais pas si c'est possible de faire ça ne javascript par exemple

Ca permet quand même d'envoyer tout un paquet d'image en une fois, ça peut servir.

Pour redimensionner, faut utiliser GD ou regarder du côté d'ImageMagick.

Ca permet quand même d'envoyer tout un paquet d'image en une fois, ça peut servir.

Oui c'est pour ça que je veux qu'on puisse décompresser un zip : c'est exactement l'utilisation que je souhaite

skweek :
Bin tu peux te servir en interne de la date systeme + du nom de user + de son album et eventuellement tu hash tout ca avec un md5 afin de rendre la chose le plus aleatoire possible afin qu'il n'y ait jamais de doublons.

Euh pour la premiere partie ok. Mais en quoi faire un md5 t'empêche d'avoir des doublons ? A priori, si tu fais un md5 de ce truc, tu as justement plus de chances d'obtenir des doublons que si tu n'en fais pas ...

En effet.
Pour être précis, skweek, le MD5 sur ce qui précède n'apporte strictement rien puisque si ce qui précède est identique, le hash le sera également.

En effet. Pour être précis, skweek, le MD5 sur ce qui précède n'apporte strictement rien puisque si ce qui précède est identique, le hash le sera également.

sauf si on met un time&datestamp dans le seed pour generer le hash, je doute qu'a la meme seconde on puisse avoir deux image du meme nom qui se font uploader

Faut lire tout le topic avant de faire un UP !

Et j'ai lu nan mais

je sais pas si utiliser un auto_increment est une 'bonne' idée.
Ca marchera, mais ca permettra à tout le monde de voir toutes les photos. (vu qu'il y aura probablement un lien du genre blabla/display.php?image_id=xxx.

En mettant à la place un hash quelconque, ca sera beaucoup plus difficile de trouver une image 'au hasard'.

Après ca dépends ce que tu veux faire, mais ma solution me paraît un peu mieux dans le cas d'un site façon imageshack.

./14> dans ce cas tu as noté que ton ./12 est à côté de la plaque.

Il se proposait de stocker la date et l'heure, plus le MD5 des deux. D'où ma réflexion sur l'inutilité du MD5 pour la garantie de l'unicité, puisque si la date et l'heure sont identiques, le MD5 le sera aussi.

Haaa

oui en effet stoquer le md5 de tout ça n'est pas forcement utile, SAUF si tu utilise le md5 comme clef mais avec comme seed plus d'info que date et heure, du genre


md5($date . $time . $filename . $author . $rand(0,65535))

par exemple

oui mais je comprends pas l'intérêt du md5, autant stocker ces informations en clair

Si tu concatene la date en microseconde, le nom du fichier et de l'auteur, peut-être que le MD5 sera plus court.

oui mais tu t'exposes à un risque de collision (que ce soit par hasard ou par une attaque)

pas plus que dans l'autre cas je pense

bah si dans l'autre cas dès que la date est différente, la clé est différente.
et dans le cas d'un simple auto_increment y a jamais de collisions

dualmoo :
oui mais je comprends pas l'intérêt du md5, autant stocker ces informations en clair

je vois trois très bonnes raisons :
- pas de leak d'information
- nom de taille bornée même si la taille des informations n'est pas bornée
- ensemble de caractères "gentil" (contrairement au cas où, par exemple, on rajoute le nom de fichier)

Et le risque de collision est de toute façon complètement négligeable dans l'hypothèse où un attaquant n'a aucun intérêt à créer de toutes pièces deux fichiers avec un même hash, et accessoirement ce serait très difficile à faire si le md5 est randomisé avec un microtime() ou un rand() suffisamment gros... (menfin si on a un rand() suffisamment gros, je vois pas bien l'intérêt de s'embarrasser avec d'autres informations )

dualmoo :
et dans le cas d'un simple auto_increment y a jamais de collisions

oui mais il y a d'autres inconvénients :
- pas parallélisable (bon ça aura p-ê pas bcp d'importance pour le site de Thor )
- leak d'informations
- possibilité de deviner des numéros et donc d'accéder à n'importe quelle image (alors que pour des random sur 256 bits, faudra se lever tôt )

l'auto_increment est tout de même à la fois plus simple et meilleur
(cross)

Oui le MD5 peut servir d'index aussi et sera bcp plus rapide que de devoir utiliser un champ texte & co (doubeul cross, tripeul meme)

pas d'accord.

pour le zip, c'est tout à fait faisable, et dans les deux sens (zipper coté serveur ou dézipper coté serveur)

Tiens et si pour l'identifiant tu utilisais des GUID ?