Fichier binaire contenant 0x1A interprété comme fin de fichier

Bonjour,

Le 19/01/2016 17:25, sam22 a écrit :

Mon problème est le suivant. J'ai trouvé un compilateur C qui fonctionne bien
sous windows 8 (environnement 32/64 bits), c'est DEV-C++.
Malheureusement, je bloque sur un problème lié à la lecture d'un fichier binaire
(donc contenant éventuellement n'importe quel octet, par définition). [...]
J'ai essayé avec les fonctions read, fread, _read, mais
c'est toujours la même chose.

Il faudrait que tu regardes dans le manuel de ton compilateur les
options de open() (ou fopen() selon ce que tu utilises) : il y a
probablement une option pour forcer l'ouverture en mode binaire.

Cette option n'existe plus dans les compilateurs standards, mais
si je me rappelle bien ça pourrait être O_BINARY pour open() ou
"b" pour fopen().

Cordialement,
--
Olivier Miakinen

Le 19 janvier 2016, sam22 a écrit :

Bonjour,
Je suis un petit nouveau, mais ce forum semble efficace!
Mon problème est le suivant. J'ai trouvé un compilateur C qui fonctionne bien
sous windows 8 (environnement 32/64 bits), c'est DEV-C++.
Malheureusement, je bloque sur un problème lié à la lecture d'un fichier binaire
(donc contenant éventuellement n'importe quel octet, par définition). Et lorsque
la suite d'octets du fichier contient un octet de valeur 0x1A (ou Ctrl-Z), il
est interprété comme une fin de fichier et la lecture s'arrête,
malencontreusement. J'ai essayé avec les fonctions read, fread, _read, mais
c'est toujours la même chose. Enervant qu'un fichier ne puisse contenir ce
caractère spécial sans que tout s'arrête. :-(

Les questions sur C, c'est mieux dans fr.comp.lang.c ;-), mais c'est pas
grave.

En C++, c'est :

std::ifstream ifs;
ifs.open ("test.txt", std::ifstream::binary);

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)

Le mardi 19 Janvier 2016 à 17:25 par sam22 :

Bonjour,
Je suis un petit nouveau, mais ce forum semble efficace!
Mon problème est le suivant. J'ai trouvé un compilateur C qui
fonctionne bien sous windows 8 (environnement 32/64 bits), c'est DEV-C++.
Malheureusement, je bloque sur un problème lié à la
lecture d'un fichier binaire (donc contenant éventuellement n'importe
quel octet, par définition). Et lorsque la suite d'octets du fichier
contient un octet de valeur 0x1A (ou Ctrl-Z), il est interprété
comme une fin de fichier et la lecture s'arrête, malencontreusement. J'ai
essayé avec les fonctions read, fread, _read, mais c'est toujours la
même chose. Enervant qu'un fichier ne puisse contenir ce caractère
spécial sans que tout s'arrête. :-(
Auriez-vous une solution, en dehors de Turbo C, qui n'est vraiment pas pratique
sous windows 8 (ce n'est pas un environnement natif, ou alors je n'ai pas su
trouver une version tournant nativement sous ce système) ?
Merci de votre aide, car je ne m'en sors pas!
Bonne soirée
Christian

Bonjour,
Merci pour vos réponses.
Mon compilateur n'est pas prolixe à expliquer les paramètres/options des fonctions, ou alors c'est moi (plus probablement).
Je me suis essayé aux siouxeries de C++, et ... ça marche!!
Merci, j'ai réussi un grand pas, grâce à vous!
Maintenant un prog. en environnement moderne, avec des fichiers aux noms longs, etc, chose que je n'avais jamais connue (je devais tronquer à 8 car., ou faire des choses compliquées (renommages)).
Cordialement
CC

Bonjour,

Le 20/01/2016 à 10:09, sam a écrit dans le message
<bLqdneJnj-9T0wLLnZ2dnUU798ydnZ2d@giganews.com> :

Malheureusement, je bloque sur un problème lié à la lecture d'un
fichier binaire (donc contenant éventuellement n'importe quel octet,
par définition). Et lorsque la suite d'octets du fichier contient un
octet de valeur 0x1A (ou Ctrl-Z), il est interprété comme une fin de
fichier et la lecture s'arrête, malencontreusement. J'ai essayé avec
les fonctions read, fread, _read, mais c'est toujours la même chose.
Enervant qu'un fichier ne puisse contenir ce caractère spécial sans
que tout s'arrête. :-(
[...]

[...]
Je me suis essayé aux siouxeries de C++, et ... ça marche!!

Généralement, on poste le code qui fonctionne, comme ça :
- ça pourra servir à d'autres ;
- si le code comporte un bug, nul doute que quelqu'un te le signalera
(ce n'est pas parce que ça fonctionne avec les tests que tu as
effectués que ça fonctionnera tout le temps) ;
- on verra si c'est du C ou du C++ que tu as utilisé ;
- ça animera un peu ce groupe qui est tombé dans un lourd sommeil
depuis quelques temps.

--
Benoit Izac

Le mardi 19 Janvier 2016 à 17:25 par sam22 :

Bonjour,
Je suis un petit nouveau, mais ce forum semble efficace!
Mon problème est le suivant. J'ai trouvé un compilateur C qui
fonctionne bien sous windows 8 (environnement 32/64 bits), c'est DEV-C++.
Malheureusement, je bloque sur un problème lié à la
lecture d'un fichier binaire (donc contenant éventuellement n'importe
quel octet, par définition). Et lorsque la suite d'octets du fichier
contient un octet de valeur 0x1A (ou Ctrl-Z), il est interprété
comme une fin de fichier et la lecture s'arrête, malencontreusement. J'ai
essayé avec les fonctions read, fread, _read, mais c'est toujours la
même chose. Enervant qu'un fichier ne puisse contenir ce caractère
spécial sans que tout s'arrête. :-(
Auriez-vous une solution, en dehors de Turbo C, qui n'est vraiment pas pratique
sous windows 8 (ce n'est pas un environnement natif, ou alors je n'ai pas su
trouver une version tournant nativement sous ce système) ?
Merci de votre aide, car je ne m'en sors pas!
Bonne soirée
Christian

Bonjour,
OK, ça marche, voici la partie du prog. modifié :

ifstream f (argv[iarg], ios::in | ios::binary);
/* précédemment : fic = open (argv[iarg], O_RDONLY, 0777); */
if (!f.is_open()) /* if (fic == -1) */ {
printf ("e;e;fichier non trouve'n"e;e;);
break;
};
/* on lit membre par membre à cause des problèmes d'alignement dans les structures; la structure n'a plus d'intérêt, je sais */
f.read ((char *)&entete.version, sizeof(entete.version));
f.read ((char *)&entete.head, sizeof(entete.head)); /* 3 caractères d'entete */
f.read ((char *)&entete.nblocs, sizeof(entete.nblocs)); /* nb de blocs */
etc...

Pour un 2ème prog., chargé de l'inverse (écriture du fichier binaire), j'ai essayé l'autre méthode (Olivier Miakinen), avec l'option O_BINARY :

fic = open (ficgen, O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0777); /* ouverture du fichier en écriture */ [/code]

... et ça fonctionne bien aussi!
Encore merci!
Cordialement!
CC

Le mardi 19 Janvier 2016 à 17:25 par sam22 :

Bonjour,
Je suis un petit nouveau, mais ce forum semble efficace!
Mon problème est le suivant. J'ai trouvé un compilateur C qui
fonctionne bien sous windows 8 (environnement 32/64 bits), c'est DEV-C++.
Malheureusement, je bloque sur un problème lié à la
lecture d'un fichier binaire (donc contenant éventuellement n'importe
quel octet, par définition). Et lorsque la suite d'octets du fichier
contient un octet de valeur 0x1A (ou Ctrl-Z), il est interprété
comme une fin de fichier et la lecture s'arrête, malencontreusement. J'ai
essayé avec les fonctions read, fread, _read, mais c'est toujours la
même chose. Enervant qu'un fichier ne puisse contenir ce caractère
spécial sans que tout s'arrête. :-(
Auriez-vous une solution, en dehors de Turbo C, qui n'est vraiment pas pratique
sous windows 8 (ce n'est pas un environnement natif, ou alors je n'ai pas su
trouver une version tournant nativement sous ce système) ?
Merci de votre aide, car je ne m'en sors pas!
Bonne soirée
Christian

Rebonjour,
Il aurait sans doute été plus simple pour moi d'utiliser la "méthode" O_BINARY dans les 2 cas, surtout que je ne maitrise pas vraiment (euphémisme) le C++!
Mais bon, ça m'a donné l'occasion d'en avoir une petite idée, ce qui est déjà beaucoup!
A +
CC
P.S. Je continue à utiliser mes progs perso à partir d'une fenêtre DOS, ce qui me permet de passer des paramètres en ligne de commande! Vieillot, mais tellement efficace!
(c'est ce qui explique les caractères accentués modifiés dans les messages à l'écran).

In article <sdydnadIgamiCz7LnZ2dnUU798ydnZ2d@giganews.com>,
sam22 <nospam_christian.couepel@aliceadsl.fr.invalid> wrote:

Il aurait sans doute été plus simple pour moi d'utiliser la "méthode" O_BINARY
dans les 2 cas, surtout que je ne maitrise pas vraiment (euphémisme) le C++!
Mais bon, ça m'a donné l'occasion d'en avoir une petite idée, ce qui est déjà
beaucoup!

Ouais, tu maitrises pas non plus trop bien le C.

Si tu veux du code qui fonctionne et un poil tout terrain, c'est fopen(3)
l'interface, et utilise "br" ou "bw", ca casse pas trois pattes a un canard.

Le samedi 23 Janvier 2016 à 16:49 par espie :

In article
sam22

Il aurait sans doute été plus simple pour moi d'utiliser la
"méthode" O_BINARY
dans les 2 cas, surtout que je ne maitrise pas vraiment (euphémisme) le
C++!
Mais bon, ça m'a donné l'occasion d'en avoir une petite
idée, ce qui est déjà
beaucoup!

Ouais, tu maitrises pas non plus trop bien le C.

Si tu veux du code qui fonctionne et un poil tout terrain, c'est fopen(3)
l'interface, et utilise "br" ou "bw", ca casse pas trois
pattes a un canard.

Ouais, c'est vrai, je maitrise mieux l'assembleur (surtout pour ARM!)
Mais je ne te permets pas! :-) :-))
J'avais tenté avec fopen (que j'utilise aussi par ailleurs), mais pas de résultat. Si j'avais choisi "e;open"e;, c'est sans doute parce qu'il y a dispos les fonctions associées _read et _write, qui sont censées ne faire aucune conversion des données lues/écrites, et effectivement avec Turbo C, ça fonctionnait tout terrain. A ce niveau-là, aucun problème. Je ne pense pas qu'avec fopen, il y ait _fread, mais bon, si les O_BINARY ou équivalents produisent le même résultat, pourquoi pas, soyons pragmatiques!

Et c'est quoi "br" ou "bw", c'est pour binary read et binary write, sans doute ? Ce sont des fonctions ?

Maintenant, mes 2/3 progs fonctionnent tout terrain, alors je ne sais pas si je vais me compliquer l'existence (prog. pour décrypter/crypter des clés associées à des fichiers cartographiques).
Merci quand-même, et de toute façon!
CC

Bonjour,

Je ne réponds pas aux questions sur les fonctions précédées d'un « _ »,
de toute manière ce serait plus en charte sur fr.comp.lang.c que c++.

Je vais juste répondre à :

Le 24/01/2016 09:35, sam22 répondant à Marc Espie :

Et c'est quoi "br" ou "bw", c'est pour binary read et binary write, sans doute ?
Ce sont des fonctions ?

Non, c'est l'option "b" à rajouter à fopen(), comme je le signalais
déjà dans ma première réponse. Donc "br" ou "rb" au lieu de "r", "br+"
ou "r+b" au lieu de "r+", "bw" ou "wb" au lieu de "w", etc.

J'ai cru comprendre que tu avais du mal à trouver de la doc avec ton
compilateur (mais alors comment as-tu trouvé les fonctions _read et
_write ?) alors tu peux chercher sur la toile :
https://www.google.fr/search?q=man+open
https://www.google.fr/search?q=man+fopen

Le mardi 19 Janvier 2016 à 17:25 par sam22 :

Bonjour,
Je suis un petit nouveau, mais ce forum semble efficace!
Mon problème est le suivant. J'ai trouvé un compilateur C qui
fonctionne bien sous windows 8 (environnement 32/64 bits), c'est DEV-C++.
Malheureusement, je bloque sur un problème lié à la
lecture d'un fichier binaire (donc contenant éventuellement n'importe
quel octet, par définition). Et lorsque la suite d'octets du fichier
contient un octet de valeur 0x1A (ou Ctrl-Z), il est interprété
comme une fin de fichier et la lecture s'arrête, malencontreusement. J'ai
essayé avec les fonctions read, fread, _read, mais c'est toujours la
même chose. Enervant qu'un fichier ne puisse contenir ce caractère
spécial sans que tout s'arrête. :-(
Auriez-vous une solution, en dehors de Turbo C, qui n'est vraiment pas pratique
sous windows 8 (ce n'est pas un environnement natif, ou alors je n'ai pas su
trouver une version tournant nativement sous ce système) ?
Merci de votre aide, car je ne m'en sors pas!
Bonne soirée
Christian

Bonjour,
C'est une longue histoire (quelques années)!
J'utilisais Turbo C de Borland jusqu'à maintenant, sans souci avec XP en tout cas, et les exécutables générés fonctionnaient bien une fois copiés sous windows 7!
J'avais donc tous les renseignements souhaités avec ce Turbo C, et c'est comme ça que j'ai su à l'époque (où l'internet n'était pas si développé), qu'on pouvait utiliser _read et _write pour éviter les conversions dans le cas d'un fichier binaire!
Voilà, j'avais donc toutes les infos utiles avec le précédent compilateur, mais malheureusement, il ne tourne pas sous windows 8, et ses "exe" non plus.
Maintenant, le nouveau (DEV-C**) tourne bien sous windows 8, mais je n'ai pas encore trouvé comment obtenir de l'aide "en ligne".
Bon, notez bien que je ne cherche plus rien, au cas où quelqu'un ne l'aurait pas compris, mais j'essaie de répondre à la demande de Benoit Izac, et de remercier ce forum pour son aide appréciable et appréciée à juste titre, en expliquant un peu comment j'ai réussi, grâce à vous, à faire fonctionner mon bazar!
Bon, je n'ai sans doute pas assez explicité les changements opérés (quelques lignes seulement), ce qui ne permet pas bien d'apprécier le résultat, mais je n'ai pas trop envie de donner ici tout le code (660 lignes), d'autant que ce prog. n'est pas destiné à être mis entre toutes les mains, je pourrais avoir des petits problèmes (!)
J'ai bien compris maintenant l'histoire des "br" et "bw", effectivement, ça casse pas 3 pattes à un canard! Mais je comprends vite quand on m'explique longtemps!
Merci encore de toutes les solutions proposées, je n'ai que l'embarras du choix!
Cordialement
P.S. J'aurais sans doute dû aussi expliciter davantage l'histoire des structures que je n'ai pas pu utiliser comme précédemment (avec Turbo C), à cause de l'alignement automatique effectué par le nouveau compilo sur une frontière de mot, dès qu'il y a un "long" par ex. qui n'est pas aligné (exemple char tab[3], suivi d'un "long". Dans une structure, le long est aligné sur le 4ème octet, malheureusement dans le cas qui me concerne).