Bonjour
J’aimerais écrire dans un fichier en mode binaire. (en C)
Je fais alors :
fichier = fopen("Image.bmp", "ab") ;
Pour l’ouvrir.
Et après je ne sait pas si j’utilise fputs, fputc ou fprintf.
Et si je doit mettre ce que je veut écrire sous forme binaire, hexadécimal, ou caractère ...
Merci
Bonjour,
Tu l'as dit toi-même : "J’aimerais écrire dans un fichier en mode binaire.".
Tu l'ouvres correctement pour ça, donc à partir de là ?
Les cours/tutos ne manquent pas.
regarde du côté des fonctions fread et fwrite.
A+
En faite je veut, convertir un nombre entier en hexa, et l’écrire en hexa dans un fichier .bmp.
Et je pensait que pour faire cela, il fallait ouvrir en mode binaire, mais avec ce lui ci on ne peut écrire qu’en texte...
Sinon le texte irait aussi mais il faudrait alors que je trouve une fonction qui convertit des nombres en chaîne de caractère.
J'ai essayé :
Mais ça ne marche qu'avec des nombres < 256, car char c'est 8 bit.void conv_hex (int a, FILE *fichier)
{
char g ;
g = a ;
fputc (g, fichier) ;
}
Ca ne veut rien dire. Un nombre est un nombre. La base n'est qu'une manière de l'écrire. N'importe comment toutes les données dans un ordi ne sont représentées que par 2 état, ce qu'on va simplifier en disant binaire.En faite je veut, convertir un nombre entier en hexa
Et je pensait que pour faire cela, il fallait ouvrir en mode binaire, mais avec ce lui ci on ne peut écrire qu’en texte...Précise parce que là, je n'y comprend rien.
la fonction fprintf le fait très bien.Sinon le texte irait aussi mais il faudrait alors que je trouve une fonction qui convertit des nombres en chaîne de caractère.
Finalement, je ne vois vraiment pas ce que des caractères vont faire dans un fichier bmp (quoique j'ai ma petite idée). A mon avis tu pars dans la mauvaise direction et ce serait le;moment de préciser ce que tu veux exactement.
A+
Bonjour,
Un fichier bmp est une image, tu ne peux pas lui coller du texte dessus comme ça.
(Si c'est bien ça que tu veux faire, sinon je ne comprends pas ce que tu veux)
ok, je précise
Mon programme doit créer un fichier .bmp, et y enregistrer les données de l’image, qu’il aura calculer.
Dans les fichier .bmp il y’a "une entête", le contenue, et éventuellement une palette.
Pour l’entête je commence par écrire :
Puis il faut sur 4 octets, la taille du fichier, que le programme aura aussi calculer.Code:fprintf (fichier, "BM6") ; // en haxa : 42 4D ==> 2 octets
Imaginons c’est 2217412o
Je veut alors que mon fichier contient 000000000101011100010000101111(2) ou 00 21 D5 C4 (16) ou .!ÕÄ en caractères. (Je sait, c’est tout pareil)
Mon problème est alors d'écrire sur 4 octets : .!ÕÄ ou 00 21 D5 C4 (16) ou le binaire dans mon fichier.
(J’utilise un éditeur hexadécimal pour visualiser les résultats)
Voici ma nouvelle fonction inventé (qui marche presque) pour faire cette opération :
Si je n’écrit pas la dernière partie, ce code marche, mais bien-sur que pour 3 octets.Code:void conv_print (unsigned long int x, FILE *fichier) { unsigned long int c ; char h ; c = x & 255 ; h = c ; fputc (h, fichier) ; c = x & 65280 ; c = c / 256 ; h = c ; fputc (h, fichier) ; c = x & 16711680 ; c = c / 65536 ; h = c ; fputc (h, fichier) ; c = x & 4278190080 ; //[Warning] this decimal constant is unsigned only in ISO C90 c = c / 16777216 ; h = c ; fputc (h, fichier) ; }
Sur tout les sites ou j’ai regarder j’ai trouver que "unsigned long int" vas de 0 à 4294967295, mais si je comprend bien d’après le message d’erreur de mon compilateur ça ne marche pas.
En plus ma fonction est un peu longue. Et je pense qu’il existe sûrement une autre fonction qui marche mieux que la mienne...
Dernière modification par AmigaOS ; 05/01/2011 à 22h20.
tu as essayé de remplacer ta fonction par:
en supposant que v ait été initialisé comme ceci par exemple:Code:fwrite(&v,sizeof(unsigned long),1,fichier);
A+Code:unsigned long v = 0x0021D5C4;
Dernière modification par Jack ; 05/01/2011 à 23h51.
ma solution n'est pas portable en raison des problèmes de little et big endian. La preuve, les données seront stockées à l'envers. Si tu travailles sur un PC, donc équipé d'un µprocesseur little endian, il faut modifier mon post précédent en inversant les octets:
pour éviter les problèmes de compatibilité, il faut donc sérialiser les données octet par octet.Code:unsigned long v = ;0xC4D52100;
Avec les déclarations suivantes:Code:p = (unsigned char*)&v; for (i=3;i>=0;i--){ fwrite(p+i,1,1,f); }
A+Code:int i; unsigned char* p;
bonjour,
une autre solution :Envoyé par AmigaOS
le printf n'est pas nécessaire bien sur, c'est juste pour voir si ça marche bien.Code:void conv_print (unsigned long int x, FILE *pf) { int i; for(i=0;i<4;i++) { fputc(x & 0xFF,pf); printf("[%i]=0x%02X\n",i,x & 0xFF); x=x >> 8; } }
La logique est une méthode systématique d’arriver en confiance à la mauvaise conclusion.
Sauf erreur, ta sérialisation n'est pas non plus portable (elle suppose une endianness constante de la machine du compilateur ; si tu passes sur un micro big-endian par exemple, la sérialisation sera différente).
En revanche, il existe des fonctions de conversion d'endianness hton* et ntoh* dont une adaptée aux long : htonl
La conversion s'effectue alors automatiquement vers l'endianness réseau dont je suppose qu'elle est identique à celle adoptée dans le format BMP ? (mais n'en ai pas la certitude).
:'( Plus j'apprends, et plus je mesure mon ignorance
tu fais bien de le préciser
A+
Super, j’ai essayé fwrite, et ça fonctionne !
Au début je l’avait rechercher sur internet, et en avait mal compris la définition.
Je m’y connais pas encore trop en processeur, mais en tout cas le fait que la fonction écrit les données à l’envers est justement ce qu’il me faut, car le BMP est "écrit à l'envers", j’ai oublier de le préciser.ma solution n'est pas portable en raison des problèmes de little et big endian. La preuve, les données seront stockées à l'envers. Si tu travailles sur un PC, donc équipé d'un µprocesseur little endian, il faut modifier mon post précédent en inversant les octets:
Mais j’aimerait comprendre pourquoi mon code ne fonctionnait pas... unsigned long int n’est vraiment pas de 0 à 4294967295 ? Ou ça dépend encore de la machine ?
