pour différencier deux fichiers textes, nous avons diff.
Je dois aujourd'hui différencier deux fichiers binaires.
Le premier est plus gros que le second. Tous les octets du second
sont dans le premier.
Comment visualiser la différence entre les deux fichiers?
Comment concaténer les octets superflus du premier dans fichier?
J'utilise hexdump et diff qui me permet de visualiser facilement
l'emplacement de la première différence. Néanmoins, comme par la suite
les octets ne sont plus alignés, diff m'indique que tout le reste est différent.
pour différencier deux fichiers textes, nous avons diff. Je dois aujourd'hui différencier deux fichiers binaires.
Le premier est plus gros que le second. Tous les octets du second sont dans le premier.
Comment visualiser la différence entre les deux fichiers?
cksum $FICHIER1 cksum $FICHIER2
Cyrille Lefevre
Le 08/04/2011 11:47, Kevin Denis a écrit :
Bonjour,
pour différencier deux fichiers textes, nous avons diff. Je dois aujourd'hui différencier deux fichiers binaires.
cmp (-s) est plus adapté et plus rapide.
Le premier est plus gros que le second. Tous les octets du second sont dans le premier.
à la suite ? ou mélangés ?
Comment visualiser la différence entre les deux fichiers? Comment concaténer les octets superflus du premier dans fichier?
man dd , cf seek, skip, count, bs
J'utilise hexdump et diff qui me permet de visualiser facilement l'emplacement de la première différence. Néanmoins, comme par la suite les octets ne sont plus alignés, diff m'indique que tout le reste est différent.
sinon, tu peux toujours aller voir du côté de xdelta (A binary delta generator)
an application program designed to compute changes between files. These changes (deltas) are similar to the output of the 'diff' program in that they may be used to store and transmit only the changes between files. However, unlike diff, the output of Xdelta is not expressed in a human-readable format--Xdelta can also also apply these deltas to a copy of the original file. Xdelta uses a fast, linear algorithm and performs well on both binary and text files.
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Le 08/04/2011 11:47, Kevin Denis a écrit :
Bonjour,
pour différencier deux fichiers textes, nous avons diff.
Je dois aujourd'hui différencier deux fichiers binaires.
cmp (-s) est plus adapté et plus rapide.
Le premier est plus gros que le second. Tous les octets du second
sont dans le premier.
à la suite ? ou mélangés ?
Comment visualiser la différence entre les deux fichiers?
Comment concaténer les octets superflus du premier dans fichier?
man dd , cf seek, skip, count, bs=1c
J'utilise hexdump et diff qui me permet de visualiser facilement
l'emplacement de la première différence. Néanmoins, comme par la suite
les octets ne sont plus alignés, diff m'indique que tout le reste est différent.
sinon, tu peux toujours aller voir du côté de xdelta (A binary delta
generator)
http://xdelta.sourceforge.net
an application program designed to compute changes between
files. These changes (deltas) are similar to the output of the 'diff'
program in that they may be used to store and transmit only the
changes between files. However, unlike diff, the output of Xdelta is
not expressed in a human-readable format--Xdelta can also also apply
these deltas to a copy of the original file. Xdelta uses a fast,
linear algorithm and performs well on both binary and text files.
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
pour différencier deux fichiers textes, nous avons diff. Je dois aujourd'hui différencier deux fichiers binaires.
cmp (-s) est plus adapté et plus rapide.
Le premier est plus gros que le second. Tous les octets du second sont dans le premier.
à la suite ? ou mélangés ?
Comment visualiser la différence entre les deux fichiers? Comment concaténer les octets superflus du premier dans fichier?
man dd , cf seek, skip, count, bs
J'utilise hexdump et diff qui me permet de visualiser facilement l'emplacement de la première différence. Néanmoins, comme par la suite les octets ne sont plus alignés, diff m'indique que tout le reste est différent.
sinon, tu peux toujours aller voir du côté de xdelta (A binary delta generator)
an application program designed to compute changes between files. These changes (deltas) are similar to the output of the 'diff' program in that they may be used to store and transmit only the changes between files. However, unlike diff, the output of Xdelta is not expressed in a human-readable format--Xdelta can also also apply these deltas to a copy of the original file. Xdelta uses a fast, linear algorithm and performs well on both binary and text files.
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Kevin Denis
Le 11-04-2011, Cyrille Lefevre a écrit :
pour différencier deux fichiers textes, nous avons diff. Je dois aujourd'hui différencier deux fichiers binaires.
cmp (-s) est plus adapté et plus rapide.
effectivement.
Le premier est plus gros que le second. Tous les octets du second sont dans le premier.
Comment visualiser la différence entre les deux fichiers? Comment concaténer les octets superflus du premier dans fichier?
man dd , cf seek, skip, count, bs
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N' premiers octets, et qui les efface si identique. Si différent, on compare les 'n' octets (on supprime si différent), puis chaque octet (supprimé si différent). On arrive donc au premier changement entre les deux fichiers. On boucle en supprimant octet par octet du fichier 2, et en vérifiant que les 'n' premiers octets sont différents. S'ils sont identiques, on repart dans une boucle avec 'N' octets.
Avec N24 et n, je n'ai pas trop de pb de perfs, ni de faux positifs. (en vérifiant octet par octet uniquement, j'ai des faux positifs: abcdefghijk abcdef1234g5678ghijk qui ne convient pas..)
J'ai juste un énorme problème de perfs lors de la suppression d'1 octet: dd if=fichierB of=fichier bs=1 skip=1 est très très très lent. En modifiant par: dd if=fichierB of=fichier ibs=1 obs24 skip=1 C'est meilleur, mais lent tout de même (10s pour supprimer le premier octet d'un fichier de quelques Mo).
Il y a surement plus optimisé :) mais comme je n'avais à faire l'opération qu'une seule foi ça m'a convenu.
an application program designed to compute changes between files. These changes (deltas) are similar to the output of the 'diff' program in that they may be used to store and transmit only the changes between files. However, unlike diff, the output of Xdelta is not expressed in a human-readable format--Xdelta can also also apply these deltas to a copy of the original file. Xdelta uses a fast, linear algorithm and performs well on both binary and text files.
Je vais voir, merci. -- Kevin
Le 11-04-2011, Cyrille Lefevre a écrit :
pour différencier deux fichiers textes, nous avons diff.
Je dois aujourd'hui différencier deux fichiers binaires.
cmp (-s) est plus adapté et plus rapide.
effectivement.
Le premier est plus gros que le second. Tous les octets du second
sont dans le premier.
Comment visualiser la différence entre les deux fichiers?
Comment concaténer les octets superflus du premier dans fichier?
man dd , cf seek, skip, count, bs
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N'
premiers octets, et qui les efface si identique. Si différent,
on compare les 'n' octets (on supprime si différent), puis chaque octet
(supprimé si différent). On arrive donc au premier changement entre les
deux fichiers.
On boucle en supprimant octet par octet du fichier 2, et en vérifiant
que les 'n' premiers octets sont différents. S'ils sont identiques, on repart
dans une boucle avec 'N' octets.
Avec N24 et n, je n'ai pas trop de pb de perfs, ni de faux positifs.
(en vérifiant octet par octet uniquement, j'ai des faux positifs:
abcdefghijk
abcdef1234g5678ghijk
qui ne convient pas..)
J'ai juste un énorme problème de perfs lors de la suppression d'1 octet:
dd if=fichierB of=fichier bs=1 skip=1
est très très très lent.
En modifiant par:
dd if=fichierB of=fichier ibs=1 obs24 skip=1
C'est meilleur, mais lent tout de même (10s pour supprimer le premier octet
d'un fichier de quelques Mo).
Il y a surement plus optimisé :) mais comme je n'avais à faire l'opération
qu'une seule foi ça m'a convenu.
http://xdelta.sourceforge.net
an application program designed to compute changes between
files. These changes (deltas) are similar to the output of the 'diff'
program in that they may be used to store and transmit only the
changes between files. However, unlike diff, the output of Xdelta is
not expressed in a human-readable format--Xdelta can also also apply
these deltas to a copy of the original file. Xdelta uses a fast,
linear algorithm and performs well on both binary and text files.
Comment visualiser la différence entre les deux fichiers? Comment concaténer les octets superflus du premier dans fichier?
man dd , cf seek, skip, count, bs
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N' premiers octets, et qui les efface si identique. Si différent, on compare les 'n' octets (on supprime si différent), puis chaque octet (supprimé si différent). On arrive donc au premier changement entre les deux fichiers. On boucle en supprimant octet par octet du fichier 2, et en vérifiant que les 'n' premiers octets sont différents. S'ils sont identiques, on repart dans une boucle avec 'N' octets.
Avec N24 et n, je n'ai pas trop de pb de perfs, ni de faux positifs. (en vérifiant octet par octet uniquement, j'ai des faux positifs: abcdefghijk abcdef1234g5678ghijk qui ne convient pas..)
J'ai juste un énorme problème de perfs lors de la suppression d'1 octet: dd if=fichierB of=fichier bs=1 skip=1 est très très très lent. En modifiant par: dd if=fichierB of=fichier ibs=1 obs24 skip=1 C'est meilleur, mais lent tout de même (10s pour supprimer le premier octet d'un fichier de quelques Mo).
Il y a surement plus optimisé :) mais comme je n'avais à faire l'opération qu'une seule foi ça m'a convenu.
an application program designed to compute changes between files. These changes (deltas) are similar to the output of the 'diff' program in that they may be used to store and transmit only the changes between files. However, unlike diff, the output of Xdelta is not expressed in a human-readable format--Xdelta can also also apply these deltas to a copy of the original file. Xdelta uses a fast, linear algorithm and performs well on both binary and text files.
Je vais voir, merci. -- Kevin
Paul Gaborit
À (at) 11 Apr 2011 11:09:47 GMT, Kevin Denis écrivait (wrote):
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N' premiers octets, et qui les efface si identique. Si différent, on compare les 'n' octets (on supprime si différent), puis chaque octet (supprimé si différent). On arrive donc au premier changement entre les deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au problème que vous posez... Et que la recherche de la solution optimale (par exemple par la taille de la différence) est un problème complexe.
À (at) 11 Apr 2011 11:09:47 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait (wrote):
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N'
premiers octets, et qui les efface si identique. Si différent,
on compare les 'n' octets (on supprime si différent), puis chaque octet
(supprimé si différent). On arrive donc au premier changement entre les
deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au
problème que vous posez... Et que la recherche de la solution optimale
(par exemple par la taille de la différence) est un problème complexe.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 11 Apr 2011 11:09:47 GMT, Kevin Denis écrivait (wrote):
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N' premiers octets, et qui les efface si identique. Si différent, on compare les 'n' octets (on supprime si différent), puis chaque octet (supprimé si différent). On arrive donc au premier changement entre les deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au problème que vous posez... Et que la recherche de la solution optimale (par exemple par la taille de la différence) est un problème complexe.
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N' premiers octets, et qui les efface si identique. Si différent, on compare les 'n' octets (on supprime si différent), puis chaque octet (supprimé si différent). On arrive donc au premier changement entre les deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au problème que vous posez...
oui, bien évidemment. Mais dans mon cas, j'ai des petits ajouts (quelques octets) intercalés par plusieurs centaines de ko identiques. C'est une hypothèse simplificatrice. Je suis à peu près certain qu'on peut créer des paires de fichiers qui n'auront pas de réponse unique avec cet algo :)
Et que la recherche de la solution optimale (par exemple par la taille de la différence) est un problème complexe.
Je le pense aussi. Mais j'avais surtout besoin du résultat (c'est fait avec n), donc ça reste acceptable comme solution. -- Kevin
Le 11-04-2011, Paul Gaborit <Paul.Gaborit@invalid.invalid> a écrit :
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N'
premiers octets, et qui les efface si identique. Si différent,
on compare les 'n' octets (on supprime si différent), puis chaque octet
(supprimé si différent). On arrive donc au premier changement entre les
deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au
problème que vous posez...
oui, bien évidemment. Mais dans mon cas, j'ai des petits ajouts (quelques
octets) intercalés par plusieurs centaines de ko identiques. C'est une
hypothèse simplificatrice. Je suis à peu près certain qu'on peut créer des
paires de fichiers qui n'auront pas de réponse unique avec cet algo :)
Et que la recherche de la solution optimale
(par exemple par la taille de la différence) est un problème complexe.
Je le pense aussi. Mais j'avais surtout besoin du résultat (c'est fait
avec n), donc ça reste acceptable comme solution.
--
Kevin
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N' premiers octets, et qui les efface si identique. Si différent, on compare les 'n' octets (on supprime si différent), puis chaque octet (supprimé si différent). On arrive donc au premier changement entre les deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au problème que vous posez...
oui, bien évidemment. Mais dans mon cas, j'ai des petits ajouts (quelques octets) intercalés par plusieurs centaines de ko identiques. C'est une hypothèse simplificatrice. Je suis à peu près certain qu'on peut créer des paires de fichiers qui n'auront pas de réponse unique avec cet algo :)
Et que la recherche de la solution optimale (par exemple par la taille de la différence) est un problème complexe.
Je le pense aussi. Mais j'avais surtout besoin du résultat (c'est fait avec n), donc ça reste acceptable comme solution. -- Kevin
À (at) 11 Apr 2011 11:09:47 GMT, Kevin Denis écrivait (wrote):
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N' premiers octets, et qui les efface si identique. Si différent, on compare les 'n' octets (on supprime si différent), puis chaque octet (supprimé si différent). On arrive donc au premier changement entre les deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au problème que vous posez... Et que la recherche de la solution optimale (par exemple par la taille de la différence) est un problème complexe.
Ca s'appelle la "distance d'édition" (ou de Lehvenstein -- sp?), non ? Un exemple classique de ce qu'on appelle la programmation dynamique (il n'y a effectivement pas forcément de solution unique). Ou bien j'ai raté quelque chose ?
Non. Je voulais juste souligner qu'un algorithme naïf risque de ne pas trouver la plus petite solution (au sens qui minimise le nombre de suppressions, ajouts et remplacements).
Paul Gaborit <Paul.Gaborit@invalid.invalid> writes:
À (at) 11 Apr 2011 11:09:47 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait (wrote):
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N'
premiers octets, et qui les efface si identique. Si différent,
on compare les 'n' octets (on supprime si différent), puis chaque octet
(supprimé si différent). On arrive donc au premier changement entre les
deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au
problème que vous posez... Et que la recherche de la solution optimale
(par exemple par la taille de la différence) est un problème complexe.
Ca s'appelle la "distance d'édition" (ou de Lehvenstein -- sp?), non ?
Un exemple classique de ce qu'on appelle la programmation dynamique (il
n'y a effectivement pas forcément de solution unique). Ou bien j'ai raté
quelque chose ?
Non. Je voulais juste souligner qu'un algorithme naïf risque de ne pas
trouver la plus petite solution (au sens qui minimise le nombre de
suppressions, ajouts et remplacements).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 11 Apr 2011 11:09:47 GMT, Kevin Denis écrivait (wrote):
C'est ce que j'ai fini par faire. Une boucle qui compare les 'N' premiers octets, et qui les efface si identique. Si différent, on compare les 'n' octets (on supprime si différent), puis chaque octet (supprimé si différent). On arrive donc au premier changement entre les deux fichiers.
[... et la suite...]
J'expère que vous êtes conscient qu'il n'y pas une solution unique au problème que vous posez... Et que la recherche de la solution optimale (par exemple par la taille de la différence) est un problème complexe.
Ca s'appelle la "distance d'édition" (ou de Lehvenstein -- sp?), non ? Un exemple classique de ce qu'on appelle la programmation dynamique (il n'y a effectivement pas forcément de solution unique). Ou bien j'ai raté quelque chose ?
Non. Je voulais juste souligner qu'un algorithme naïf risque de ne pas trouver la plus petite solution (au sens qui minimise le nombre de suppressions, ajouts et remplacements).