effectue un appel système à "MD5Sum File1" et "MD5Sum File2" et comparez deux valeurs de retour suffisantes dans ce cas?
8 Réponses :
oui, il suffit de
Eh bien, cela vous dira s'il est vraiment différent ou probablement le même. Il est possible pour deux fichiers pour avoir le même hachage, mais pas réellement les mêmes données ... juste très improbable.
Dans votre situation, quel est l'impact si vous obtenez un faux positif (c'est-à-dire si vous pensez qu'ils sont les mêmes, mais ils ne sont pas)? MD5 est probablement assez bon pour ne pas vous inquiéter des collisions si elles ne se produiraient que accidentellement ... mais si vous avez une sécurité (ou de l'argent) en jeu et que quelqu'un pourrait planter un "mauvais" fichier avec le même hachage en tant que "bon" fichier, vous ne devriez pas compter sur elle.
Personnellement, je voudrais probablement simplement lire les deux fichiers, comparer chaque octet - pour une comparaison unique, à la fois la hache et cette approche nécessitera la lecture du fichier entier lorsqu'ils sont égaux; Comme Daniel souligne dans les commentaires, une comparaison d'octets par octets vous permet de sortir tôt dès que vous voyez une différence. La comparaison des tailles de fichiers en premier est une autre optimisation rapide :)
L'avantage général du hachage se produit lorsque vous stockez le hasch du fichier existant quelque part, de sorte que la prochaine fois que vous pouvez juste lire le nouveau fichier.
Dépend de la source. S'il existe une question de confiance / de sécurité en jeu et que vous ne pouvez pas compter sur la bonne intention du ou des créateurs de fichiers, alors "improbable" n'est pas le mot approprié.
@Msalters: En effet, élaborera.
Une fois, un "conférencier universitaire" me dit sans équivoque, aucun fichier ne peut avoir le même MD5 et ne pas être identique au contenu de données.
@Jon, merci pour votre explication. Comment générer la valeur de hachage d'un fichier? Hashlib ressemble à des œuvres avec une corde uniquement.
«Le hachage et cette approche nécessiteront à la fois la lecture du fichier entier» - seulement vrai dans le cas où les fichiers sont les mêmes. Vous pouvez sauter tôt dans le cas lorsque les fichiers diffèrent si vous faites la comparaison vous-même. C'est une raison suffisante pour ne pas utiliser l'approche MD5 (comme indiqué dans ma réponse!).
@Jack: Lorsque vous appelez md5sum, que est générer un hash.
@Jon: Vous pourriez aussi bien mettre mon autre bonne idée de votre réponse - comparer les tailles de fichiers avant de vous soucier de comparer le contenu du fichier;)
@Daniel - fera, bien que j'espère que cela serait évident :)
@Dominic Bou-Samra: C'est évidemment faux car si c'était vrai, seulement 2 ^ 128 = 340282366920938463463374646346337464634633746463463374646346337464631768211456 Différents contenus de fichier pourraient exister. Cela n'est tridicalement pas vrai, car vous pouvez créer autant de fichiers, le contenu est le compteur réel. Ensuite, créez un fichier avec le contenu "foobar" et il doit être mappé sur l'une des valeurs ci-dessus. Voyez ici: th.informatik.uni-mannheim.de/people/lucks/ HashCollisions pour deux fichiers PostScript valides avec la même somme MD5.
@Jon: Je suis J'espère qu'il était assez évident que la plupart des développeurs ne manquent pas cela, cependant, je ne suis plus surpris lorsque des optimisations évidentes sont manquées par les développeurs ... Jaded je suis.
Si vous êtes sur un système avec MD5Sum, c'est probablement assez bon.
Vous pouvez le faire avec Python Standard Bibliothèques - Checkout OUT OUT HASHLIB .
dépend si vous vous sentez à l'aise avec la probabilité de collision sur l'algorithme MD5. Il suffit de noter qu'il est très improbable: alors oui, allez-y.
Si vous voulez faire plus que détecter simplement s'ils diffèrent ou ne faites pas confiance à la solution de hachage, il existe des modules dans la bibliothèque standard appelée DIFFLIB et FileCMP qui ne s'appuie pas sur des programmes externes.
Il suffit de lire le doco pour Filecmp - cela semble certainement être la bonne approche pour une application Python. J'aime l'idée que "les fichiers comparés à l'aide de cette fonction ne seront plus comparés à moins que leur modification de la signature OS.STAT ()." Nul doute que la fonction FileCmp.CMP () est plus efficace que de rouler le vôtre. Je pense que cela devrait être la réponse acceptée ...
Bien sûr, il existe un test simple que vous devez faire avant de comparer le contenu du fichier du tout - si les fichiers sont des tailles différentes, ils ne peuvent pas éventuellement être les mêmes.
ne serait-il pas plus efficace de simplement lire chaque fichier et effectuer une comparaison d'octets par octets, en évitant complètement l'algorithme de hachage. Cela évite les chances (très improbables) que deux fichiers différents produisent le même hachage MD5. De plus, vous pouvez mettre cautionnement de la comparaison lorsque la première différence est détectée, ce que pour des fichiers très différents sera très tôt dans la comparaison (possible sur le premier octet!)
Je suis d'accord. Simple Filecmpume serait plus rapide que le calcul de l'informatique.
S'il n'y a personne d'essayer de créer des collisions, vous devrez alors comparer environ 2 fichiers 64 avant de vous attendre à voir un collision par hasard au hasard . Cependant, il est possible que quelqu'un construise soigneusement deux fichiers avec la même somme MD5 en raison de Faibless cryptographiques dans MD5 < / a>. Que les faiblesses cryptographiques de MD5, matières ou non dépendent de votre candidature, où les fichiers proviennent et ce qu'un attaquant pourrait se tenir à gagner s'il a trompé votre programme en pensant que deux fichiers différents étaient identiques. MD5 est toujours une très bonne somme de contrôle, tout comme un hachage cryptographique.
Un hachage est utile si vous allez le mettre en cache (pour comparer de nombreux fichiers différents avec l'autre). Si vous voulez simplement comparer deux fichiers, c'est un gaspillage monstrueux de cycles. Après tout, les deux fichiers seront lus, et beaucoup de traitement seront utilisés sur chaque bouchée.
Si c'est un 1: 1 comparer, il suffit d'utiliser: D'autre part, un bon hash est le seul moyen de comparer un grand nombre de fichiers avec l'autre. SHA-1 et MD5 sorte de brisé - mais pas pour les fichiers normaux. Quelques chercheurs peuvent générer 2 fichiers de non-sens qui pourraient s'affronter, mais il est peu probable que quiconque puisse clocter un fichier existant. git utilise SHA-1 pour comparer le texte, donc ce n'est pas un choix terrible. Ce qui suit fonctionnera tous:
"Si peu profonds est vrai, les fichiers avec des signatures id.stat () identiques sont prises pour être égales. . Sinon, le contenu des fichiers est comparé. " Avez-vous l'intention de cela?
C'est exactement ce dont j'avais besoin de comparer deux fichiers et de vous assurer qu'ils sont identiques pour une conversion de marque à JSON.