Bonsoir,
 
Je cherche une fonction qui avec un fichier en entrée me ressortirait un identificateur spécifique à ce fichier.
 
Ainsi, si deux fichiers retournent le meme identificateur, on pourrait considérer que ces deux fichiers sont identiques.
 
Et si on applique la fonction à deux fichiers différents, l'identificateur retourné devra etre différent.
 
 
Déjà, est ce que ce genre de fonction est possible ?
est ce qu'elle existe déjà en java ?
le cas échéant, est-elle réalisable ?
 
Merci

Euh bin... à pat comparer les fichiers octet par octet, y a pas de méthode 100 % sûre de comparaison
Tu peux utiliser diverses méthodes qui vont te donner un résultat avec une marge d'erreur minime (hashage, etc...) mais je crois pas qu'il y ait quoi que ce soit qui permettent de générer un identifiant affirmant avec certitude que deux fichiers sont identiques.

en meme temps, File f = new File(pouet) et File g = new File(tralala), if (f!=null && g !=null && f.exists() && f.getAbsolutePath().equals(g.getAbsolutePath()), ça doit pouvoir le faire

le truc c que mes deux fichiers sont sur deux ordinateurs différents
 
Je m'interesse à la méthode donnant un résultat avec une marge minime, pourrais je avoir plus de détails sur les fonction de hashage en java svp ?
 
Merci

Bin y a la classe MessageDigest dans javax.security qui devrait faire la plus grosse partie du boulot pour toi avec l'algorithme MD5. Maintenant, stu connais pas la notion, je te recommanderais de te documenter un peu dessus avant de te lancer dans le codage du truc

il faut que les deux fichiers soient identiques ou que ce soit le meme fichier ?
 
genre 2 fichiers texte avec "toto" dedans doivent avoir le meme identificateur ? un identificateur different chacun ?

Ben, vu ce qu'il vient de dire, il parle du contenu qui doit ê identique, pas des fichiers. Par contre j'vois pas pourquoi y aurait pas une méthode 100% sûre de comparaison. Essaye de voir si t'as moyen de trouver les sources du fameux "MD5Check" du monde unix (qui permet de calculer un identifiant unique en fonction du contenu d'un fichier, afin de vérifier si, lors d'un téléchargement par exemple, le fichier reçu a exactement le même contenu que le fichier d'origine).

faut faire un hash du contenu

un genre de 'diff/sdiff', il me semble qu'il y a une methode pour ça  
 
edit: ben non (c'est pour des objets ) je vote donc pour un hashage aussi  

ben parce que tu peux pas mettre 2 bits en 1
 
par contre avec un algo de hashage bien choisi tu peux dire que si le hashachage obtenu est identique, il y a de très fortes chances que les fichiers soient identiques.

 
Ha ouais. En plus j'avais déja eu une discution + ou - similaire avec toi !

ouais il me semblait bien

mais pour calculer le hash d'un fichier tu dois lire le fichier en intégralité (enfin je crois???), donc autant comparer bit à bit..

 
et zou  

Bin ui, +1
Pis ça bouffera moins de CPU
Sinon, uriel, pour ton bout de code, j'avais lu quelque part qu'un buffer pour lire des fichiers, c'était bien par blocs de 1024 (j'parle au niveau des perfs).

heckedInputStream cis = new CheckedInputStream(new BufferedInputStream(new FileInputStream("filename" ))
 

 
au fait, en passant par un Buffered* , est-ce que ça pose un problème de faire ensuite un read byte par byten c-a-d read(), au lieu de passer par un array buffer?

je viens de voir qu'il y avait aussi CRC32 qu'on peut utiliser a la place du Adler32 ci-dessus.
 
http://java.sun.com/j2se/1.4.2/doc [...] CRC32.html
 
Mais ici qqun a du recoder un algo de CRC, parce qu'il n'était apparement pas standard, celui de la sdk.... qqun à un avis la dessus??

c'est vrais quand tu fais une comparaison unitaire, maintenant  si tu dois comparer un ensemble de fichiers à un ensemble de fichier ...

euh quoi?

ben quoi ?
 
Imagine que tu dois comparer les fichiers contenus dans 2 reps ? si tu fais des comparaisons bit à bit faudra comparer tous les fichiers 1 à 1 ... alors qu'en calculant un identifiant, tu n'as ensuite plus qu'à comparer les identifiants 1 à 1 ce qui au final t'as fait économiser pas mal de calcul.

et pour calculer les identifiants de chacun des fichiers tu fais comment?

ben tu lis chaque fichier mais juste une fois

honnetement, tu te trouves clair là?
 
qui a parlé d'effectuer plusieurs comparaison de chacun des fichiers?
et qu'est-ce que ça a voir avec le fait qu'il y ait plusieurs fichiers, justement. ça n'a a voir qu'avec le fait qu'on veut comparer et recomparer un meme fichier plusieurs fois.
 
alors ton kiki, tu te le fous au cul, merci.

oui je me trouve clair. C'est même tellement évident que ca a pas besoin d'explication alors c'est pas parce que tu comprends pas que je suis pas clair.
 
Et je réponds pas pas aux impolis

ok
 
 
(sérieux ça fait presque pitié)

attends, t'as vu comment tu me prends de haut ??
 
C'est toi qui demande un truc et tu te permets de me répondre comme ca parce que je suis pas assez clair pour toi

stoi qui m'a fait un kiki, alors je t'ai demandé si tu te trouvais clair
après avoir compris ou tu voulais en venir, je t'ai expliqué que tu ne l'étais pas, et t'ai renvoyé ton kiki, voila tout

vos gueules

ok
 
 
 
 
 

retournez bosser bande de connards

Je ne peux pas comparer les deux fichiers bit à bit puisque qu'il ne sont pas sur le meme ordinateur
je vais me renseigner sur la fonction MD5, elle a l'air interessante
 
et si j'ai bien compris les fonction adler-32 et CRC32 retourne un identifiant de 32 bits, ce qui me parait insuffisant.
 
MD5, c bien 128 bits ?

Ui.

y'a une implementation de md5 qui passerait dans CheckedInputStream ?
 
(d'ailleurs pq ils ont mis CheckedInputStream dans java.util.zip? )

 
je me posais la même question

bitte