Manipulation de fichiers : perte de données

Bonjour,

j'essaye de faire un petit programme qui fait un XOR en 1 fichier et 1 mot de passe. Quand le fichier n'est pas trop gros ça marche, mais dès que ca dépasse une certaine taille, j'ai des pertes.

La manip est la suivante : j'ai un fichier A, je fais un XOR avec un mot de passe quelconque, ça me donne un fichier B. Je refait la manip pour le fichier B, ça me donne un fichier C qui devrait être identique au fichier A.

J'ai testé avec un fichier de 163ko, ça marche, avec un fichier de 3Mo j'ai plein de différences en A et C.

Mon main ressemble à ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

void main(void) { CFichier fichierIn("test.txt", std::ios::in | std::ios::binary); CFichier fichierOut("resultat.txt", std::ios::out | std::ios::binary);   CXOR xor(pass);   const long int nbChunk = fichierIn.getNbChunk(BUF_LEN); const long int lastChunkSize = fichierIn.getLastChunkSize(BUF_LEN);   for(long int i = 0 ; i<nbChunk ; i++) { fichierIn.read(i*nbChunk, BUF_LEN); fichierOut.write(fichierIn.getBuffer()); }   fichierIn.read(i*nbChunk, lastChunkSize); fichierOut.write(fichierIn.getBuffer()); }

---

Les autres fichiers sont en pièces attachées.

Merci d'avance pour votre aide !

Andy.

Bonjour,

j'ai regardé rapidement ton code, et ça me semble beaucoup, beaucoup trop compliqué pour ce qu'il est censé faire.
Qu'entends-tu exactement par faire "un XOR en 1 fichier et 1 mot de passe"?

Bonjour,

l'idée c'est de prendre le premier octet du fichier, le premier octet du mot de passe, de faire un XOR, et d'écrire le résultat dans le fichier de sortie, et ainsi de suite jusqu'à la fin du fichier d'entrée.

Alors en fait je viens de me rendre compte d'un truc là, j'ai pas filé la bonne version du prog. Mais finalement c'est mieux, ça simplifie les choses.

Je crée un objet CXOR mais je n'en fais rien. Tout ce que je fais c'est lire le fichier d'entrée et le recopier dans le fichier de sortie, malgré tout j'ai des différences entre les 2 fichiers, pas de taille mais de contenu.
Donc la classe CXor on s'en fout, le problème doit se situer dans CFichier. J'avais fais cette modif là justement pour isoler le problème.

Sinon, quel est le souci quand a la complexité de mon prog ?

Je ne comprends toujours pas ce que tu entends par XOR. Pour moi XOR c'est un ou exclusif ( A XOR B = (A ET non B) OU (non A ET B) ), et je ne vois pas le rapport avec ton histoire de fichiers.

Ensuite, de ce que je comprends pour l'instant de ton problème, il s'agit de parcourir un fichier et de remplacer un token par un autre. Cela se fait très simplement en C++:
1. Lire le fichier et stocker son contenu en mémoire (par exemple, lire ligne par ligne et stocker dans un std::vector<std::string>
2. Parcourir le texte stocké et remplacer les token par le motif souhaité (par exemple avec find et replace).
3. Ecrire le résultat dans un nouveau fichier.

S'il n'y a pas de cas particulier compliqué à gérer, cela se fait en quelques lignes.

Il s'agit bien du ou exclusif.
Je prends le premier caractère de mon fichier, disons "A", je prends le premier caractère de mon mot de passe, disons "?", je fais un XOR entre eux et ça me donne "~" que j'écris dans le fichier résultat. Et je fais de même avec tous les octets du fichier source en cyclant sur le mot de passe.

Le fichier résultant est alors un version chiffrée du fichier source. Pour retrouver le fichier source, je prends le fichier résultant et je fais la même manip qu'avec le fichier source : je prends le premier caractère, ici "~", je fais un XOR avec le premier caractère du mot de passe, "?", et je retrouve mon "A".

Je suis bien d'accord avec les points 1,2 et 3.
Ce que je fais c'est que j'utilise un buffer de taille BUF_LEN.
Pour copier mon fichier, procède par tronçons de taille BUF_LEN que je lis dans la source puis que j'écris dans le fichier destination.
Puis à la fin je lis ce qui reste éventuellement et je l'écris de même.

Seulement les 2 fichiers ne sont pas identiques et je ne vois pas d'où ça vient.

Je fais un read :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

std::streamsize CFichier::read(std::streampos pos, std::streamsize len) { if(!_File.is_open()) { return -1; } if(pos<0) { return -2; } if(len<0) { return -3; }   if(!len) len=size();   _File.seekg(pos);   char *charBuffer = new char [len]; _File.read(charBuffer, len); std::streamsize actuallyRead = _File.gcount();   _buffer.clear(); if(actuallyRead>0) _buffer.assign(charBuffer, actuallyRead);   delete [] charBuffer;   return actuallyRead; }

---

puis j'écris le contenu du buffer :

Code:

---

1 2 3 4 5 6 7 8

std::streamsize CFichier::write(const std::string &s) const { std::ostream outStream(_File.rdbuf());   outStream.write(s.c_str(), (std::streamsize)s.length());   return (std::streamsize) s.length(); }

---

Tu veux dire que même sans faire le XOR (donc sans modifier les données lues), le fichier de sortie (résultat du write) est différent du fichier lu?

ps: je ne comprends toujours pas cette histoire de XOR. Le résultat d'un XOR c'est vrai ou faux, donc si ça n'a pas de sens si toi tu souhaites avoir un char.

Oui, c'est ce que je disais dans mon post de 14h32 :

"Je crée un objet CXOR mais je n'en fais rien. Tout ce que je fais c'est lire le fichier d'entrée et le recopier dans le fichier de sortie, malgré tout j'ai des différences entre les 2 fichiers, pas de taille mais de contenu."

C'est exactement ce que tu as compris, je fais une bête copie mais j'ai des différences, et je vois pas en regardant mon code où le bât blesse.

Alors pour le XOR, ça a un sens si on considère que le char c'est en fait 8bits, je reprends avec mon exemple :

Mon caractère A vaut 65 en ASCII, soit 1000001
Mon caractère ? vaut 63 en ASCII, soit 0111111
Mon caractère ~ vaut 65 en ASCII, soit 1111110

Quand on les voit comme ça alignés, on se rend compte que :

A ^ ? = ~

1 ^ 0 = 1
0 ^ 1 = 1
0 ^ 1 = 1
0 ^ 1 = 1
0 ^ 1 = 1
0 ^ 1 = 1
0 ^ 1 = 1
1 ^ 1 = 0

Et du coup, forcément :

~ ^ ? = A

1 ^ 0 = 1
1 ^ 1 = 0
1 ^ 1 = 0
1 ^ 1 = 0
1 ^ 1 = 0
1 ^ 1 = 0
1 ^ 1 = 0
0 ^ 1 = 1


A étant le contenu du fichier source, et ~ le contenu du fichier destination, le fichier destination est une version chiffrée du fichier source avec la clé "?".

L'opération A ^ ? chiffre le fichier source, le résultat est stocké dans le fichier de destination.
L'opération ~ ^ ? récrée le fichier source à partir du fichier de destination.

Vois-tu ?

Ha ok je vois maintenant. Oui bien sûr, où avais-je la tête...
Oui alors effectivement, c'est un peu plus compliqué que je ne le pensais.
Je n'ai pas le temps de regarder en détail, mais effectivement, il faut faire attention à la façon dont tu lis et écris les données, parce que là tu effectues des manipulations en binaire. Il faut donc éviter les char, et ne manipuler que des unsigned char (le signe dans le char fausse les opérations). Pas de char => pas de std::string. A la limite, des std::biset, mais je sais pas trop si c'est une bonne idée ici. Essaie de lire et écrire tes fichiers en mode binaire (std::ios::bin) et vois ce que ça donne.

Mes fichiers sont déjà ouverts en binaire :

Code:

---

1 2	CFichier fichierIn("test.txt", std::ios::in | std::ios::binary); CFichier fichierOut("resultat.txt", std::ios::out | std::ios::binary);

---

Par contre je vais passer mes char en unsigned char.

Le truc c'est que pour l'instant je ne fais aucune manip sur les données : je lis un fichier, je stock le résultat dans un buffer, puis j'écris le buffer dans un autre fichier.

Le problème situe peut-être lors de la conversion char* vers string, notamment si je colle des 0 dans un string je sais pas trop ce que ça fait.

Je vais donc aussi virer les std::string.

Merci pour ton aide précieuse !

Je

Citation:

---

Envoyé par r0d

Ha ok je vois maintenant. Oui bien sûr, où avais-je la tête...
Oui alors effectivement, c'est un peu plus compliqué que je ne le pensais.
Je n'ai pas le temps de regarder en détail, mais effectivement, il faut faire attention à la façon dont tu lis et écris les données, parce que là tu effectues des manipulations en binaire. Il faut donc éviter les char, et ne manipuler que des unsigned char (le signe dans le char fausse les opérations). Pas de char => pas de std::string. A la limite, des std::biset, mais je sais pas trop si c'est une bonne idée ici. Essaie de lire et écrire tes fichiers en mode binaire (std::ios::bin) et vois ce que ça donne.

---

hello
Cela voudrai dire que std::string a un bug que je considère comme grave (tout est relatif)
car si la conversion ce fait mal pas mal d'appli aurai du souci a ce faire, je pense que sa doit venir des pointeur et le C qui son a mon avis la source du problème.

Citation:

---

Envoyé par panthere noire

Cela voudrai dire que std::string a un bug

---

Non, ça veut dire que le type char n'est pas fait pour manipuler des données en binaire. De même que le type float n'est pas fait pour manipuler des entiers, c'est aussi simple que cela.

Le type char me semble pas mal du tout pour lire du binaire, après on peut se poser la question de unsigned ou non.
Le problème doit plutôt se situer autour de std::string qui est gaulé je présume pour manipuler du texte plutôt que du binaire.

Si en C pur on utilise un fopen() pour lire un fichier dans un buffer char*, puis qu'on écrit le contenu du buffer dans un autre fichier, ça marche. Un fichier binaire bien sûr.

J'aurais aimé éviter de manipuler des char* dans mon prog C++, notamment pour l'allocation, j'aurais préférer utiliser des objets. Peut-être avec bitset ?

En tous cas dans un premier temps je vire tout ce qui est std::string et je remplace par du char* pour valider le concept.

Tu fais comme tu veux, mais d'expérience, je peux t'assurer que le problème n'est pas dans la classe string (qui n'est qu'un vector de char un peu amélioré) mais du type char.

Parfois (selon les plateforme, les libs, etc.) on trouve un type BYTE, qui n'est qu'un define sur un unsigned char.

Dans ma lib perso, j'ai des fonctions de traitements de string d'unsigned char (des std::basic_string<unsigned char> avec la politique qui va bien, je rappelle que la classe std::string est un basic_string<char>) et qui fonctionnent bien (elles sont utilisées en production sur plusieurs applis).

Il faut bien comprendre que le premier bit d'un char est son signe, du coup les traitements (à niveau du compilateur, pas à niveau de la classe string) son faussé si on souhaite manipuler des octets (en binaire quoi), puisque le premier bit n'a pas la même signification dans un cas que dans l'autre.

Citation:

---

Envoyé par Vojenbon

Le type char me semble pas mal du tout pour lire du binaire, après on peut se poser la question de unsigned ou non.

---

Il arrive souvent qu'on aie des pbs lorsqu'on manipule des octets avec des char signés. C'est pour ça qu'on essaie en général d'utiliser des unsigned char.

Pour ton problème, ça se fait rapidement avec la STL :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

#include <fstream> #include <iterator> #include <algorithm> #include <functional> #include <string>   typedef std::basic_string<unsigned char> byte_string;   struct my_key { my_key(byte_string const&key_) :key(key_),index(0),len(key_.size()) {} unsigned char operator()(unsigned char c_) { unsigned char c_ret = c_^key[index]; ++index; if(index>len){index=0;}   return c_ret; } byte_string const key; int index; int const len;   };     int main() { std::basic_ifstream<unsigned char> input("input_file",std::ios::binary); std::basic_ofstream<unsigned char> output("output_file",std::ios::binary);   unsigned char const key[]="coucou"; std::transform( std::istreambuf_iterator<unsigned char>(input.rdbuf()) ,std::istreambuf_iterator<unsigned char>() ,std::ostreambuf_iterator<unsigned char>(output.rdbuf()) ,my_key(key) );   return 0;   }

---

dont r0d propose un excellent tutoriel ;)

Merci pour la pub chef ;)

En tous cas merci pour vos réponses.

Je vais essayer le bout de code de 3DArchi (et demander à la doc ce qu'elle pense de std::transform parce que je sais même pas à quoi ça sert =) ).
Alors Rod, pour etayer ma théorie sur les char, j'ai viré tous les string, j'ai mis que des char ! Et voilà ! Ca marche pas du tout ... hm... bon ok donc voilà ma théorie -> poubelle, je vais me coucher.
Le truc aussi c'est qu'on peut difficilement utiliser du unsigned char avec du ostream comme je faisais, parce qu'ostream attend du char signé. Et le cast là je le sens pas... enfin bon on s'en fout, je vais comme je disais, quand j'aurais fini de raconter ma vie, tester le code de 3DArchi.

Et re merci !

J'essaye de comprendre le code là, et comme je suis habitué au C j'ai du mal.
En regardant sur le site ce microsoft, je vois que basic_ifstream::rdbuf() retourne l'adresse du buffer du flux.
Je suppose qu'en utilisant le transform, on va lire octet par octet le fichier, et à chaque fois écrire l'octet encodé généré.

Par contre du coup je vois pas du tout ce que ça fait, c'est boîte noire.
En C, tu dis je veux prendre 127 octets du fichier d'entrée, je mets ça dans mon buffer, je m'amuse avec, et puis j'écris 127 octets. dans le fichier de sortie.

Là, il prend tout le fichier d'un coup dans un buffer ? Il lit ça au goutte à goutte ? Comment ça marche si je veux lire des tronçons de données ?

Indépendamment des différentes remarques qui t'ont déjà été faite et de différentes erreurs dans le code (void main(void), utilisation de xor, etc.), l'erreur que tu décris me semble provenir de la ligne :

Code:

---

fichierIn.read(i*nbChunk, BUF_LEN);

---

Qui devrait plutôt être :

Code:

---

fichierIn.read(i*BUF_LEN, BUF_LEN);

---

Citation:

---

Envoyé par Vojenbon

[...]

---

std::transform est un algorithme de la STL qui construit un ensemble en appliquant un foncteur à chacun des éléments de l'ensemble de départ :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

OutputIterator transform( InputIterator first, InputIterator last, OutputIterator result, UnaryOperator op ) { while (first != last){ *result++ = op(*first++); } return result; }

---

my_key jour le rôle de opération.
std::istreambuf_iterator présente le buffer comme un itérateur (InputIterator). Schématiquement, l'opérateur '*' retourne le caractère courant et ++ lit le caractère suivant.
std::ostreambuf_iterator fait la même chose mais pour un buffer de sortie. Au lieu de lire, on écrit.
Un streambuffer peut se comprendre comme ... un buffer. Est-ce qu'il lit caractère par caractère, par bloc de 127 octets ou tout d'un coup ? A la limite, tant que tu n'as pas identifié de problème de perf à ce niveau, ce n'est pas ton problème. C'est un détail d'implémentation de ta STL

Gl : woohoo en reprenant mon code initial(c'est à dire celui que j'ai posté avec mes strings et mes char* dégueux) et en modifiant juste ce qui tu as dis ça fonctionne nikel.

Je comprenais pas non plus pourquoi en C ça marchait et pas quand je mélangeais ça avec du C++. Le but n'étant pas de faire un patchwork, mais comme je navigue à vue avec le C++, je colmate les fruits de mon ignorance avec du C.

Bon sinon le void main(void) je suis au courant, mais est-ce que fondamentalement ça va changer le cours du Yen ?

3DArchi : c'est vrai que là je n'ai rien identifié, étant donné que j'ai même pas un bout de code qui compile =) Mais je me pose la question en avance de phase, question de pas me retrouver avec un truc qui rame pour des gros volumes et de devoir tout réécrire autrement parce qu'avec cette méthode là on ne sait pas faire autrement.(dans le cas bien sur ou avec cette méthode là on ne saurait pas faire autrement =) ).

La science progresse (moi non mais c'est pas grave =) ).

Citation:

---

Envoyé par Vojenbon

Bon sinon le void main(void) je suis au courant, mais est-ce que fondamentalement ça va changer le cours du Yen ?

---

Qui sait ?

Citation:

---

Envoyé par Vojenbon

(dans le cas bien sur ou avec cette méthode là on ne saurait pas faire autrement =) ).

---

Facilement modifier pour optimiser, tu pourras.

Citation:

---

Envoyé par Vojenbon

La science progresse (moi non mais c'est pas grave =) ).

---

A moins que ce ne soit l'inverse ...

Alors par ailleurs, dans le but de faire évoluer les mentalités dans les populations qui pratiquent des rîtes vaudou au Sud du Groenland, j'ai déclaré une série de char et d'unsigned char, j'ai fait des XOR avec les uns et les autres pour voir ce que ça donnait.

Genre si je mets 206 dans un char, à l'affichage ça me met -50. Si je mets -50 dans un unsigned char, à l'affichage ça me met 206. J'ai aussi fait des XOR, en d'abord sans mélanger, puis en mélangeant signés et non signés, les résultats finaux sont toujours identiques.

C'est à dire que l'on fasse 206 ^ 'A' ou -50 ^ 'A', ça fait toujours pareil. Le codage binaire ne change pas(j'ai testé avec des bitset notamment, et -50 = 206).

La où ça devient plus délicat, c'est si on se mettait à additionner tout ça avec un entier par exemple. Là c'est plus du tout pareil. Mais tant qu'on reste dans le char ça marche. Enfin ça marche... pour le XOR, pour la multiplication c'est moins sur hein, en même temps le gars qui s'amuse à multiplier 'A' par -50, hein bon... ok ça pourrait être moi.

Sinon je pense qu'il faut délester d'urgence ce post avant qu'une âme pure et innocente ne vienne à tomber sur les immondices que je raconte.

Vers l'infini et au-delà.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <iostream>   template<typename byte_> void dump(byte_ b_) { unsigned int val = b_&0xff; std::cout<<std::hex<<val<<"\n"; } int main() { char c=-128; unsigned char uc=-128; dump(c); dump(uc); c = c>>1; uc = uc>>1; dump(c); dump(uc);   return 0; }

---

Sortie :

Citation:

---

80
80
c0
40

---

La façon dont est traitée le bit de signe dans certaines opérations de ce type (décalage) est dépendante du compilateur et non de la norme il me semble. D'où la préconisation d'utiliser toujours des versions non signées lorsqu'on manipule les bits de l'octet. Note que pour être vraiment sur tu pourrais carrément t'appuyer sur un std::bitset.

L'avantage dans mon cas c'est que le résultat en soit m'est égal.
Il faut simplement que si A^B donne C alors C^B donne A. Au moins ça c'est bon.

Je me suis permis de modifier

Code:

---

1 2	unsigned int val = b_&0xff; std::cout<<std::hex<<val<<"\n";

---

Code:

---

1 2 3

unsigned int val = b_&0xff; std::bitset<8> valb = val; std::cout<<std::hex<<val<<"\t"<<valb<<"\n";

---

Avec le binaire on voit bien que le bit de parité est conservé lors d'un décalage. Espérons que notre langue reste une langue vivante.