Discussion :

[darkwall_37]

Bonjour,

Je me suis mis à implémenter l'algorithme XOR.
Quand j'ai fais mes algos, je n'ai pas pensé au fait qu'un caractère pouvait être transformé en caractère EOF qui vaut je crois -1 sous Windows.
Une fois le fichier crypté, le résultat est enregistré dans un fichier texte ainsi que la clé de cryptage.

Or si dans l'un ou dans les deux fichiers, un caractère est changé en EOF avant la fin réelle du fichier, ils deviennent donc tronqués au décryptage et celui ci est incomplet.

En gros ce que je fais:
Je récupère le fichier à crypter dans un string.
Je convertis en binaire signé chaque caractère de la string.
J'applique une clé xor de la taille de l'ensemble de la string convertis en binaire signé.
Je convertis en caractères les binaires signés "xoré" et la clé.
J'enregistre la clé et le résultat du cryptage dans un fichier texte.

Quelqu'un a t-il une idée pour remédier à cela ?
Sinon je pourrais coller dans les fichier textes le code binaire des char au lieu du char lui même mais bon cela occupe 8*plus de place et çela procure moins d'effet qu'un ramassis de caractères imbitable.

Je mets le code source en PJ si quelqu'un souhaite regarder.
Projet codeblocks complié sous windaub.

Merci d'avance.

[Neckara]

Bonjour,

EOF équivaut généralement à (int)-1 et n'est pas inscrit dans le fichier ou le flux.
EOF est juste une valeur que retourne les fonctions de lecture pour signaler la fin du fichier (ou une erreur).

Je ne penses donc pas que ton problème vienne de là.

Au cas où tu peux toujours faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int caractere;
char caractereAEcrire = (char)caractere;

[darkwall_37]

Ok merci pour ta réponse.
J'ai remarqué cependant que fscanf s'arrête d'enregistrer le fichier en mémoire lorsqu'il tombe sur ce caractère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

�)ZÁ�Çûm—ici}èÉR_,â…)-¤¡öãȹ?Ô¿mECI•ËÉwL�*ˆªý*ó³

Il y a "ici" un caractère que je vois dans le fichier texte, mais une fois copié ici, on ne le voit plus. Cependant, quand on passe à la flêche, il faut appuyer deux fois pour passer au caractère suivant, ce qui prouve bien qu'il y a bien un caractère.

On peut le voir sur l'image ci dessous :



Dans ce cas là, le fichier s'arrête au deuxième caractère (le carré).

[Neckara]

Il faudrait ouvrir ton fichier avec un éditeur de texte pouvant afficher l'hexadécimal pour voir la valeur de ce caractère.
Peut-être est-ce un EOT (End Of Transmission) que fscanf interprète (?).
Mais pour lire un fichier binaire, n'oublie pas de l'ouvrir avec l'option "b" lors du fopen (cf man fopen) pour la compatibilité.
Et je n'ai pas vu comment tu utilise fscanf, mais peut-être serait-il préférable d'utiliser un fread ?

[darkwall_37]

Comme ça.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
char *file_to_string_1( const char *p )
{
    char c;
    unsigned long long int i = 0;
    char *s = allocate_1D_c( file_length(p)+1 );
    FILE *f = file_open(p,"r");
    while( fscanf(f,"%c",&c) != EOF )
    {
        s[i] = c;
        i++;
    }
    file_close(f);
    return s;
}

J'y ai pensé mais fread s'arrête quand il tombe sur EOF aussi ?
Ca ne va pas régler le problème ?!

[Neckara]

fread ne peut pas tomber sur EOF car EOF n'est pas présent dans un fichier.

Sinon, je pense qu'un fgetc serait bien plus approprié qu'un fscanf(f, "%c", &c).
Comme tu sembles être sous windows, ouvre bien ton fichier avec FILE *f = file_open(p,"rb");

[Ngork]

Si tu ouvres un fichier qui n'est pas du texte, sous Windows, avec l'option "r", alors la lecture sera faussée de nombreuses manières y compris quant à la fin du fichier.
Je te conseille d'ouvrir le fichier en lecture non textuelle, soit "rb" ...

Edit : Argggh ! Neckara a publié plus vite !

[darkwall_37]

c'est un fichier texte que j'ouvre.
Quand j'enregistre le code binaire de la clé et du xor sous forme de chaine, ca marche.
Mais bon ce n'est pas ce que je veux.
J'ai rajouté b au mode d'ouverture mais ça plante à l'execution, SIGTRAP.
Qu'est ce que ça va changer le mode rb à la façon d'utiliser fscanf ?
Je peux toujours prendre des caractères ?

[Neckara]

Sous Linux non mais sous Windows, si on ouvre le fichier en mode texte, Windows ignorera les caractères non-imprimables.

Sinon il me semble que SIGTRAP est normalement émis lors de l'utilisation d'un débogueur lors qu'on arrive à un point d'arrêt.

[darkwall_37]

C'est normal qu'un fichier texte bug si on l'ouvre en mode rb si on utilise fscanf car on cherche EOF qui n'existe pas non ?

[Neckara]

On ne recherche jamais EOF, EOF n'est jamais présent dans un fichier ou dans un flux. EOF n'est qu'une valeur retournée par les fonctions de lecture pour avertir d'une erreur comme la fin de fichier.

La seule différence avec le mode texte sous Windows, à ma connaissance, c'est que Windows ne prend pas en compte les caractères non-imprimables lors de la lecture en mode texte.

[Sve@r]

J'y ai pensé mais fread s'arrête quand il tombe sur EOF aussi ?
Ca ne va pas régler le problème ?!

Salut
fread() est plus adapté à la lecture d'informations "en vrac" (comme c'est le cas d'un flux crypté) que fscanf() adapté, lui, à la lecture de flux texte "formaté" (comme pourrait l'être un CSV par exemple).

fread() renvoyant le nombre d'éléments réellement lus, tu peux détecter la fin de fichier quand ce nombre renvoyé est inférieur au nombre d'éléments demandés...

[darkwall_37]

Ah okay, merci pour vos éclaircissements.
Donc probablement que ce caractère n'est pas imprimable, ce pourquoi la lecture avec fscanf d'un fichier texte sous windows provoque cette erreur.
Je potasse tout ça.

Merci

[Ngork]

Neckara : La seule différence avec le mode texte sous Windows, à ma connaissance, c'est que Windows ne prend pas en compte les caractères non-imprimables lors de la lecture en mode texte.

Le mode "rb" en lecture d'un fichier non texte sous Windows est essentiel, car en mode "r" il ne passe pas seulement les caractères non affichables mais s'arrête aussi avant la fin, en rencontrant un zéro par exemple, et attend des fins de ligne de type CR LF ...

darkwall_37 : c'est un fichier texte que j'ouvre.

Bah, non, s'il est crypté, ce n'est plus un fichier texte, il n'y a qu'à voir la copie d'écran du fichier dans le bloc-note !
fichier texte = fichier à plat ne comportant que des caractères affichables ou de formatage (TAB, CR, LF) ...

[darkwall_37]

Oui c'est pas faux. Mais je me suis mépris quant à ce qu'était un fichier texte. Merci pour les précisions.

Concernant fread, il bloque de même, quand je récupère la taille du fichier ouvert en rb, il s'arrête comme fscanf, au même endroit.
Ou alors tu parlais de faire encore autrement et je ne t'ai pas compris.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  fseek (pFile , 0 , SEEK_END);
  lSize = ftell (pFile);
  rewind (pFile);

[Sve@r]

Oui c'est pas faux. Mais je me suis mépris quant à ce qu'était un fichier texte. Merci pour les précisions.

Concernant fread, il bloque de même, quand je récupère la taille du fichier ouvert en rb, il s'arrête comme fscanf, au même endroit.
Ou alors tu parlais de faire encore autrement et je ne t'ai pas compris.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  fseek (pFile , 0 , SEEK_END);
  lSize = ftell (pFile);
  rewind (pFile);

Pas besoin de récupérer la taille. Un truc de ce genre devrait le faire

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int nb;
char buf[1000];
while ((nb=fread(pFile, 1, 1000, buf)) > 0)
{
    xor_decode(buf, nb);
    fwrite(stdout, 1, nb, buf);
}

Bien entendu, à toi de programmer xor_decode pour décrypter les nb octets situés dans buf...

[darkwall_37]

Ah si j'ai saisi ce que tu disais et ça semble marcher !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
#include <stdio.h>
#include <stdlib.h>
 
int main()
{
   FILE *f = fopen("c:\\xored.txt","rb");
   char *buffer = malloc(sizeof(char));
   while (0<fread(buffer,1,sizeof(char),f))
        printf("%s",buffer),getchar();
 
   fclose(f);
   free(buffer);
   return 0;
}

EDIT : AH trop rapide tu es !
Ce n'est pas conseillé comme façon de faire de manière générale je suppose ? Cela m'a l'air d'être la façon la plus simple et la plus sûre pour lire un fichier (binaire+fread) et ce n'est pourtant pas ce qui est enseigné en premier comme méthode.

[darkwall_37]

Merci à tous pour vos réponses et vos explications.
L'utilisation du mode d'ouverture rb ainsi que l'utilisation de fread & fwrite a réglé les problèmes décris dans ce post.

Il faut que je reprenne le code pour l'améliorer à tout point de vue. En tous cas pour le moment après avoir lancé des 1.000.000 de cryptages à la suite, l'entrée = la sortie à chaque fois :p.

[Sve@r]

Ah si j'ai saisi ce que tu disais et ça semble marcher !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <stdio.h>
#include <stdlib.h>

int main()
{
   FILE *f = fopen("c:\\xored.txt","rb");
   char *buffer = malloc(sizeof(char));
   while (0<fread(buffer,1,sizeof(char),f))
        printf("%s",buffer),getchar();

   fclose(f);
   free(buffer);
   return 0;
}

EDIT : AH trop rapide tu es !
Ce n'est pas conseillé comme façon de faire de manière générale je suppose ? Cela m'a l'air d'être la façon la plus simple et la plus sûre pour lire un fichier (binaire+fread) et ce n'est pourtant pas ce qui est enseigné en premier comme méthode.

Hum. Déjà faire un malloc de 1 char c'est un peu absurde vu que si tu déclares un simple char c'est déjà un char qui t'est directement réservé. Mais ensuite traiter ce char comme une chaine de caractères c'est le clash assuré à plus ou moins long terme. Et dernier détail, fread() veut en premier la taille d'un élément et en second le nombre d'éléments à récupérer. Toi tu l'as mis dans l'autre sens. Là c'est pas grave vu que les deux valeurs sont à 1 mais si ensuite tu veux faire évoluer ton code (remarque dans mon exemple de ce matin j'ai inversé le buffer et le flux )

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <stdio.h>
#include <stdlib.h>
 
int main()
{
   FILE *f = fopen("c:\\xored.txt","rb");
   char c;
 
   while (fread(&c,sizeof(char), 1,f) > 0)
        fwrite(&c, sizeof(char), 1, stdout);
 
   fclose(f);
   return 0;
}

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <stdio.h>
#include <stdlib.h>
 
#define SZ_BUF       (1000)
 
int main()
{
   FILE *f = fopen("c:\\xored.txt","rb");
   char buf[SZ_BUF];
   int nb;
 
   while ((nb=fread(buf,sizeof(char), SZ_BUF,f)) > 0)
        fwrite(buf, sizeof(char), nb, stdout);
 
   fclose(f);
   return 0;
}

[darkwall_37]

Oui en effet, mais j'ai refais les fonctions au propre et je l'avais corrigé. Je suis allé lire un petit man entre temps :X. Merci pour ton oeil intraitable quoiqu'il en soit :p.
EDIT : je vais rajouter le retour de fread (nb) que j'ai manqué. Merci.

Pour le char, totalement absurde je confirme. Je suis absurde, j'aime l'absurdité, j'assume