Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C validation de format de fichier

validation de format de fichier

8 réponses
Avatar
Nicolas aunai
encore moi..,

en plein dans les tests et vérifications sur un programme, je cherche a
faire un test de format de fichier.

mon programme permet d'enregistrer un fichier de données binaires, (*.box
mais on s'en fout..) bref, je l'écris/lis avec les fonctions fread/fwrite
comme nous en avions discuté dans le thread "fread, fwrite...."

au moment de la lecture du fichier, il n'y a aucune vérification... alors
certes ça marche.. mais en supposant que le fichier ouvert ait bien le
format que j'attend !

si ledit fichier doit contenir une structure particulière avec disons 4
membres... et qu'en fait, il n'a pas du tout ça, ou bien pire... il ne
contient rien du tout ! que va-t-il se passer ??

du coup, juste après l'ouverture du fichier j'aimerai vérifier qu'il est
bien conforme au format attendu, et dans le cas contraire, afficher un
message a l'utilisateur du style "format de fichier non valide ou fichier
corrompu" un truc de ce style...

pour l'instant le seul truc que je vois c de vérifier le retour de fread,
mais ça, ça me donne le nombre d'objets lus, et si par exemple ça lit bien
une structure mais que c pas la bonne (autrement dit, le retour de fread
donne-t-il le nombre d'objet /du type du parametre 1/ ? ou juste le nombre
d'objets lus ?); et si par exemple un ou plusieurs des membres de ma
structure est vide, ou bien "non valide"...?


je propose de faire une fonction verif_format(size_t nb_obj,structytpe
*structure) qui ferait un truc du genre :

int verif(size_t nb_obj, structype *structure)
{

if(nb_obj!=1) /*si fread n'a pas lu le seul objet normalement présent
dans le fichier*/
return 0; /*on retourne 0, qui sera testé après dans la fonction
lecture*/



/*on teste les membres de la structure un à un
le problème étant que je vois pas du tout comment faire !*/

}


ma structure dois être :

typedef struct PostMessageBox{

char message[256];
char titre[256];
UINT uTypebut;
UINT uTypeico;

}PostMessageBox;


je peux au moins vérifier si les membres sont non "vides", par exemple si
message[0]!=0 (idem pour titre) par contre je vois pas comment faire pour
vérifier que le premier membre de la structure est bien une chaine (mais
peut-etre est-ce inclu dans fread dans le sens ou si ça n'est pas une
chaine, ça n'est pas un type PostMessageBox, donc nb_obj!=1)

pour uTypebut je pense qu'il suffit d'initialiser les variables avec une
valeur négative et de tester ensuite qu'elles ne le sont pas

bon, comme d'hab j'espère avoir été clair :o)

--
nico,
http://astrosurf.com/nicoastro
messenger : nicolas_aunai@nospam@hotmail.com
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Emmanuel Delahaye
In 'fr.comp.lang.c', "Nicolas aunai" @free.fr> wrote:

encore moi..,

en plein dans les tests et vérifications sur un programme, je cherche a
faire un test de format de fichier.

mon programme permet d'enregistrer un fichier de données binaires, (*.box
mais on s'en fout..) bref, je l'écris/lis avec les fonctions fread/fwrite
comme nous en avions discuté dans le thread "fread, fwrite...."

au moment de la lecture du fichier, il n'y a aucune vérification... alors
certes ça marche.. mais en supposant que le fichier ouvert ait bien le
format que j'attend !


En principe, si la fonction d'écriture n'a pas renvoyé d'erreur, et que le
fichier a ensuite bien été fermé, les données enregistrées sont valides.

Ensuite il peut effectivement arriver que les données du fichiers soient
modifiées par un autre programme, mais il faut le vouloir. Par sécurité, tu
peux joindre un checksum à tes données, mais je pense que ce n'est pas
vraiment utile.

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Avatar
Guillaume Rumeau
"Nicolas aunai" @free.fr>
a informé le monde le 07/26/03 à 17:40:29 que :

[...]

checksum ? :)



Une empreinte si tu préfères.

bon ce que je pensais, c pas forcément que ça soir modifié par un autre
programme, ou mal écris, mais par exemple, si j'ai un guguss qui s'amuse a
changer l'extension d'un fichier euh... texte par exemple en .box, et essaye
de l'ouvrir avec mon programme... qu'est-ce qui va se passer ?? bah ça va
buguer... voir planter grave le machin...

vu qu'il faut prévoir tous les cas de bug... autant ne pas laisser cette
situation comme ça, et faire en sorte qu'elle soit prévue dans le code. non
:) ?


Dans, ce cas, tu ajoutes à ton fichier un en-tête, qui contiendra
entre autre, le type du format, un numéro de version du format, un
copyright, un checksum.

Bien sûr, seulement si tu as la main sur le dit format. Sinon, à toi
de gérer dans ton code, avec des contrôles sur la validité des données
lues (qu'il est, même avec un en-tête, de bon ton d'ajouter).

--
GR
http://www.isty-info.uvsq.fr/~rumeau/fclc/

Avatar
Emmanuel Delahaye
In 'fr.comp.lang.c', "Nicolas aunai" @free.fr> wrote:

Ensuite il peut effectivement arriver que les données du fichiers
soient modifiées par un autre programme, mais il faut le vouloir. Par
sécurité, tu peux joindre un checksum à tes données, mais je pense
que ce n'est pas vraiment utile.


checksum ? :)


'somme de contrôle' Qu'en pense Google?

bon ce que je pensais, c pas forcément que ça soir modifié par un autre
programme, ou mal écris, mais par exemple, si j'ai un guguss qui s'amuse
a changer l'extension d'un fichier euh... texte par exemple en .box, et
essaye de l'ouvrir avec mon programme... qu'est-ce qui va se passer ??
bah ça va buguer... voir planter grave le machin...


Non. Tu vas lire un flot de bytes qui va être copié dans la structure. Les
données seront erronées (un checksum permet de s'en rendre compte) et c'est
tout.

vu qu'il faut prévoir tous les cas de bug... autant ne pas laisser cette


Il ne faut pas non plus tomber dans l'absurde...

situation comme ça, et faire en sorte qu'elle soit prévue dans le code.
non
:) ?


--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/


Avatar
Nicolas aunai
Emmanuel Delahaye a écrit:

checksum ? :)


'somme de contrôle' Qu'en pense Google?


je sais pas du tout pas eu le temps de chercher encore... bah tiens v le
faire...

Non. Tu vas lire un flot de bytes qui va être copié dans la
structure. Les données seront erronées (un checksum permet de s'en
rendre compte) et c'est tout.


bon ok

vu qu'il faut prévoir tous les cas de bug... autant ne pas laisser
cette


Il ne faut pas non plus tomber dans l'absurde...


hum... ça me semblais (semble) pas si absurde que ça, si l'utilisateur ouvre
un mauvais fichier il faut le détecter et l'avertir... ça me semble plutôt
important même.


je reviens sur un point tout de même, le retour de fread est le nombre
d'objet lu, est-ce le nombre d'objet quelconque ou bien le nombre d'objet de
type identique a celui passé en 1ere argument ?

--
nico,
http://astrosurf.com/nicoastro
messenger : @hotmail.com


Avatar
Emmanuel Delahaye
In 'fr.comp.lang.c', "Nicolas aunai" @free.fr> wrote:

vu qu'il faut prévoir tous les cas de bug... autant ne pas laisser
cette


Il ne faut pas non plus tomber dans l'absurde...


hum... ça me semblais (semble) pas si absurde que ça, si l'utilisateur
ouvre un mauvais fichier il faut le détecter et l'avertir... ça me
semble plutôt important même.


Ok.

je reviens sur un point tout de même, le retour de fread est le nombre
d'objet lu, est-ce le nombre d'objet quelconque ou bien le nombre
d'objet de type identique a celui passé en 1ere argument ?


C'est le nombre d'objets dont la taille en bytes est passée en 2ème argument
lus correctement. Qu'en pense ton livre de C?

<Borland C>

_______
¦fread¦ <STDIO.H>
_______
Lit des données depuis un flux.

Déclaration:
size_t fread(void *ptr, size_t size, size_t n, FILE *stream);

Description:
fread lit un certain nombre d'éléments de données de taille identique depuis
un flux en entrée vers un bloc mémoire.

Argument¦ Description
--------Ï-------------------------------------------
ptr ¦ Pointe sur un bloc recevant les données
size ¦ Longueur unitaire d'élément à lire en octets
n ¦ Nombre d'éléments à lire
stream ¦ Pointeur sur flux en entrée

Le nombre d'octets lus est (n * size).

Valeur Renvoyée:
_ Si succès, fread renvoie le nombre d'éléments lus (pas d'octets)
_ Si EOF ou erreur, fread renvoie une valeur inférieure à n (ou même 0)

Portabilité:
+ DOS Ð UNIX Ð ANSI C Ð C++ Seul +
¦ Oui ¦ Oui ¦ Oui ¦ ¦
+-----¤------¤--------¤----------+

</>

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/



Avatar
Emmanuel Delahaye
In 'fr.comp.lang.c', "Nicolas aunai" @free.fr> wrote:

C'est le nombre d'objets dont la taille en bytes est passée en 2ème
argument lus correctement. Qu'en pense ton livre de C?


hum mouais justement je trouvait ça pas très clair...
donc ça veut dire que (juste pour une petite confirmation) si je fait
fread(ptr,sizeof(toto),1,file) et que mon fichier contient une structure
'bidule', le retour est 0 ?


Si tu codes n'importe quoi, le résultat n'est pas garanti. Ce que dit la
norme, c'est que si tu demandes à lire 1 element de n bytes, la valeur
retournée est 1 en cas de succes ou < 1 en cas d'échec (ici, 0).

long x;

size_t n = fread (&x, sizeof x, 1, file);

if (n < 1)
{
puts("error");
}

Le but n'est pas de tester la validité de ton code, mais de savoir si
l'ensemble des bytes ont été lus ou non.

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/


Avatar
Stephane Legras-Decussy
"Nicolas aunai" @free.fr> a écrit dans le message news:
3f22a640$0$1790$
hum... ça me semblais (semble) pas si absurde que ça, si l'utilisateur
ouvre

un mauvais fichier il faut le détecter et l'avertir... ça me semble plutôt
important même.


il ne faut pas tomber dans la parano non plus...

normalement, les fichiers binaires ont une signature
dans leur 2 premiers octets pour etre partiquement sur
de leur type...

par exemple, toutes les images bmp commence par les caracteres B et M...

tu testes juste le debut et apres tu supposes que le fichier est valide...
s'il ne l'est pas, ça plantera peut etre ou ça affichera n'importe quoi...
t'y peux rien...

Avatar
Stephane Legras-Decussy
"Guillaume Rumeau" a écrit dans le message
news:
Un programme qui plante ou qui fait n'importe quoi sous prétexte que
les données en entrée ne sont pas bonnes est un mauvais programme,
sauf cas particuliers.


ok mais alors ecrire un programme capable de
savoir si des données en entrée sont absolument "bonnes", c'est
deja un projet gigantesque...