[C++] Lecture/écriture à la fin d'un fichier PDF

Version imprimable

22/09/2006, 11h26
JµL!eN

[C++] Lecture/écriture à la fin d'un fichier PDF

Bonjour,
je souhaiterais pouvoir écrire à la fin d'un fichier PDF après la ligne

Citation:

%%EOF quand on ouvre le PDF dans un éditeur texte

afin de pouvoir y rajouter des informations. Je souhaiterais aussi pouvoir accéder de nouveau à ces informations et les relire.
Je ne pense pas qu'il soit nécessaire d'utiliser une quelconque bibliothèque gérant le PDF pour faire ça, mais si quelqu'un a une idée, je suis preneur.
Merci
22/09/2006, 12h36
gege2061

Bonjour,

Si tu connais les spécifications du format PDF, y a pas besoin de bibliothèque, ce n'est qu'un simple fichier texte.
Dans ce cas : :faq: Comment écrire à la suite d'un fichier existant ? et Comment faire pour lire un fichier ligne par ligne ? ;)
22/09/2006, 17h05
JµL!eN

Merci pour la réponse:

Citation:

#include <fstream>

void AjouterUneLigne()
{
// std::ios_base::out est automatiquement ajouté par le
// constructeur de std::ofstream
std::ofstream file( "fichier.pdf", std::ios_base::app );
file << "Une ligne\n";
}

int main()
{
// création du fichier et écriture d'une ligne
AjouterUneLigne();
// ouverture du fichier existant et rajout d'une nouvelle ligne
AjouterUneLigne();
// "fichier.txt" contient 2 lignes
}

cette portion de code fonctionne effectivement très bien pour l'écriture en fin de fichier, je l'avais d'ailleurs essayé, et elle convient parfaitement.
Mais il y a un mais, il vient de la seconde portion de code:

Citation:

#include <string>
#include <fstream>
#include <iostream>

int main()
{
// le constructeur de ifstream permet d'ouvrir un fichier en lecture
std::ifstream fichier( "fichier.pdf" );

if ( fichier ) // ce test échoue si le fichier n'est pas ouvert
{
std::string ligne; // variable contenant chaque ligne lue

// cette boucle s'arrête dès qu'une erreur de lecture survient
while ( std::getline( fichier, ligne ) )
{
// afficher la ligne à l'écran
std::cout << ligne << std::endl;
}
}
system("pause");
}

Si on ouvre un fichier pdf, il ne le lira apparement pas jusqu'au bout, puisque chez moi je ne retrouve pas les 2 lignes rajoutées à la fin, sur la sortie standard. Y-aurait il un autre moyen de récupérer ces 2 lignes?
22/09/2006, 17h22
rigobert

Citation:

Code:

if ( fichier ) // ce test échoue si le fichier n'est pas ouvert

En es-tu vraiment sûr ?

Ce ne serait pas plutôt ça :

Citation:

Code:

if ( fichier.is_open() ) // ce test échoue si le fichier n'est pas ouvert

?

Ensuite je pense que ta méthode (textuelle) pour relire le fichier n'est pas bonne, les PDF n'étant à mon humble avis certainement pas des fichiers textes...
22/09/2006, 17h42
JµL!eN

pour le coup du

Citation:

std::ifstream fichier( "fichier.pdf" );

'std::ifstream' renvoit '0' si le fichier n'est pas trouvé, donc ça ne pose pas de problème pour le test. Mais si l'utilisation du '.is_open()' est mieux ... (j'ai recopié directement l'exemple donné).

Pour l'ouverture du fichier en mode 'text', ce n'est peut-être pas la meilleure, j'ai l'impression qu'il y a des séquences d'échappement, car il sonne 2 ou 3 fois lorsque j'exécute le programme de lecture, c'est peut-être ça qui coince, il suffirait d'une mauvaise séquence pour empêcher la lecture complête du fichier.

Faudrait peut-être que je regarde du côté d'un accès à partir de la fin du fichier?

Je me place en fin de fichier, je remonte dans celui-ci en stockant les lignes jusqu'au %%EOF, je m'arrête et je remet les lignes dans le bon ordre.
Comment verrais-tu ça ?
22/09/2006, 18h00
gege2061

Citation:

Envoyé par rigobert

Ensuite je pense que ta méthode (textuelle) pour relire le fichier n'est pas bonne, les PDF n'étant à mon humble avis certainement pas des fichiers textes...

Si, bon y a quelques portions sous forme binaire (surement pour les images) mais la grande majorité c'est du texte, et dans le cas présent ce n'est pas génant (au pire y a des tags, obj et endobj je crois, qui précise ce genre de bloque, suffit de réouvrir le fichier en mode binaire à ce momment et de le refermer après mais ça me parrait un peu lourd si c'est juste pour atteindre la fin du fichier !)
22/09/2006, 18h10
rigobert

Citation:

Envoyé par JµL!eN

pour le coup du

Citation:

std::ifstream fichier( "fichier.pdf" );

'std::ifstream' renvoit '0' si le fichier n'est pas trouvé, donc ça ne pose pas de problème pour le test

Ca m'étonnerait, c'est un constructeur : aucune valeur ne peut être retournée.

Citation:

Envoyé par rigobert

Ensuite je pense que ta méthode (textuelle) pour relire le fichier n'est pas bonne

En d'autres termes, il faut le faire en binaire.

Mais que cherches-tu à faire au juste avec les PDFs ?

Es-tu sûr d'avoir consacré suffisamment de temps à l'étape de conception avant de te lancer dans le codage ?

Citation:

Envoyé par gege2061

Si, bon y a quelques portions sous forme binaire (surement pour les images) mais la grande majorité c'est du texte, et dans le cas présent ce n'est pas génant

Voici les 256 premiers octets d'un PDF ne contenant aucune image :
Code:

1 2 3 4 5 6 7 %PDF-1.4 %âãÏÓ 5 0 obj <</Filter/FlateDecode/Length 672>>stream xœ*UËnÚ@½ÊÆÝ´J¢&éfUJ*dìñkPv1¥óRÙUe) tÓkÕßË™;—,*Ë–g®Ï¹ç¾Æ+g%|ááòEyn€§øþ(šÓ…í'‘9Yéý4Fß¿äN3õ…ùÂY$=‘žÈ:}&E jâúH>V5¼ÝÑ=eÔ¥þUþàÜä•~Ëpø4¯Ó5ÓHP4è41#j ð”¡8¡÷t Ôˆ¦p\£?/©1=ˆiãN
Je suis un peu sceptique sur le fait que "la grande majorité c'est du texte" ... ;)

Citation:
Envoyé par rigobert
Voici les 256 premiers octets d'un PDF ne contenant aucune image :
Code:

1 2 3 4 5 6 7 %PDF-1.4 %âãÏÓ 5 0 obj <</Filter/FlateDecode/Length 672>>stream xœ*UËnÚ@½ÊÆÝ´J¢&éfUJ*dìñkPv1¥óRÙUe) tÓkÕßË™;—,*Ë–g®Ï¹ç¾Æ+g%|ááòEyn€§øþ(šÓ…í'‘9Yéý4Fß¿äN3õ…ùÂY$=‘žÈ:}&E jâúH>V5¼ÝÑ=eÔ¥þUþàÜä•~Ëpø4¯Ó5ÓHP4è41#j ð”¡8¡÷t Ôˆ¦p\£?/©1=ˆiãN
Je suis un peu sceptique sur le fait que "la grande majorité c'est du texte" ... ;)
:triste: Y a le tag obj pour signaler la portion en mode binaire après il existe surement autre chose que les images.

Je te laisse t'amuser à lire la document de référence, y a même des exemples de fichier :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 %PDF−1.4 1 0 obj << /Type /Catalog /Outlines 2 0 R /Pages 3 0 R >> endobj 2 0 obj << /Type /Outlines /Count 0 >> endobj 3 0 obj << /Type /Pages /Kids [4 0 R] /Count 1 >> endobj
Et ce qui est génant dans les données binaires c'est qu'il peut y avoir des caractères nuls (je passe sur les fins de ligne qui ne sont pas interprétées), donc si tu récupère une chaîne de caractères, elle sera "conquée" (j'ai pas encore eu le temps d'inspecter le code de la classe string mais dans tous les cas du aura le problème avec la fonction std::string::c_str()). Ici ça n'a pas d'importance puisque qu'on ne les utilise pas.

J'espère ne pas avoir pris trop de racourci cette fois ci ;)

22/09/2006, 20h12
rigobert

Citation:

Envoyé par gege2061

Y a le tag obj pour signaler la portion en mode binaire après il existe surement autre chose que les images.

Après un rapide coup d'oeil à la doc (1236 pages !), il y a effectivement bien plus que les images comme données binaires : des filtres de codage (généralement de compression, et qui incluent la compression d'image d'ailleurs, mais ça peut être aussi du cryptage) peuvent être appliqués aux objets, et notamment aux objets textuels. Ce qui fait quà l'arrivée il n'y a plus grand chose de lisible en ASCII.

Reste que même en parsant le fichier objet par objet, ça reste peu évident de trouver les paires obj/endobj en mode texte lorsqu'elles encadrent des data binaires.

Quant à lire le fichier ligne par ligne sans en analyser le contenu, on n'en parle même pas...

Mais ... tu avais raison : c'est structurellement un format textuel, ce que j'ignorais :oops:. Voilà c'est dit ;) !
23/09/2006, 00h55
Luc Hermitte

Le test "if (fichier)" teste d'autres choses que le is_open(). Après une ouverture cela ne fait peut-être pas de différence, ailleurs, le is_open() n'a plus grand intérêt.
Je n'utilise jamais les is_fail() / is_open() / eof() / ... Jamais eu besoin d'une telle précision dans mes traitements de haut niveau. Verbeux, et potentiellement pénible à refactorer pour pas grand chose.

Sinon, le flag binaire utilisé dans les ouvertures des fichiers sert à signaler si des traitements particuliers doivent être réalisés : typiquement, des interprétations de sauts de lignes, de fin de fichiers , etc.
Dans un cas pareil, je serais tente de partir vers binaire. Justement à cause des données non chaînes.
23/09/2006, 14h23
JµL!eN
Merci pour ces réponses,
Je pense que l'on est un peu loin de la question de départ, mais elle n'était pas forcément claire.

Citation:

Ca m'étonnerait, c'est un constructeur : aucune valeur ne peut être retournée.

Effectivement, c'est 'fichier' qui est à '0' si aucun fichier n'est trouvé (c'est ce qui peut arriver lorsqu'on écrit trop vite), mais ça ne répond pas au problème de lecture/écriture.
Je reprécise donc l'interrogation de départ:
- je souhaite me placer à fin du fichier pdf après %%EOF
- ajouter des lignes de texte lisible du style :
  type: "article"
  title: "titre de l'article"
  authors: "Auteur1 and Auteur2"
  year: "2006"
  ...
- pouvoir accéder à ces nouvelles données pour y effectuer des modifications
Le but étant de rajouter /modifier des informations à des fichiers pdf qui se trouvent sur mon disque (à l'aide d'un programme ;-)) sans le dénaturer (il reste quand même lisible) afin de faire de la recherche par mots clés, du tri ...
23/09/2006, 15h05
gege2061

Citation:

Envoyé par JµL!eN

Je pense que l'on est un peu loin de la question de départ, mais elle n'était pas forcément claire

Je ne pense pas, pour faire ce que tu souhaite il faut bien que tu te pose la question du mode d'ouverture à utiliser.

@rigobert : tu as eu le courrage de lire la doc 8O ça explique pourquoi tu peux te retrouver avec quasiment que des données binaires !
23/09/2006, 15h18
JµL!eN
Oui c'est vrai, le mode d'ouverture est important, et j'entrevois 2 manières pour lire et écrire dans ce fichier:
1. en mode 'binaire', en parcourant le fichier jusqu'au code représentant %%EOF
2. en mode 'text', en partant de la fin du fichier (fseek), en lisant ligne par ligne , ou caractère par caractère, jusqu'à la ligne contenant %%EOF
Je vais essayer de voir ce que donne la seconde, elle me parait plus 'simple' à faire, enfin je me fais peut-être des idées.

Je me disais bien que le mode texte était bon, je viens d'essayer la méthode que j'avais décrite juste au dessus, en partant de la fin du fichier, voici le bout de code :
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 45 #include <cstdio> #include <cstdlib> #include <iostream> #include <vector> using namespace std; int main () { FILE * pFile; vector<char> buffer; int count = -1; bool result = true; char c; pFile = fopen ("fichier.pdf","r"); while (result) { fseek(pFile, count, SEEK_END); c = fgetc(pFile); buffer.push_back(c); if (c=='%') result = false; count -= 1; } fclose(pFile); vector<char>::iterator idx = buffer.begin(); for( idx = buffer.end(); idx != buffer.begin()-1; idx-- ) cout << *idx; system("pause"); return 0; }
En plus j'utilise <vector>, alors j'adore ;-) Cela fonctionne assez bien, en fait je m'étais trompé pour le %%EOF, il se peut qu'il n'y en ait pas qu'un dans le fichier pdf, certains dont je dispose en ont plusieurs (bizarre mais bon).

Il ne me manque plus qu'un petit test pour vérifier que les caractères que je récupère avant le % sont bien FOE, et le tour serait joué ?

Si vous avez des remarques et commentaires, ou un code plus élégant, je suis toujours preneur.

24/09/2006, 01h25
Luc Hermitte

Pourquoi ne pas ouvrir en append pour l'écriture ?
Ta lecture ne me parait pas efficace. Et si tu bufferises, pour la lecture tu devras ouvrir en non binaire.

Ton algo de parcours me parait louche. Surtout dans la gestion du compteur.

Utilise rbegin et rend.

Il faut tester le résultat du getc avant de l'empiler. Rien ne dit que la lecture soit OK.

Et si tu as un %eof dans ta zone à toi ? Ca va pas le faire => tout lire pour s'arréter au premier => ouverture binaire.
24/09/2006, 16h06
JµL!eN

Le but du programme que je souhaite faire est le suivant:
pouvoir ajouter/modifier/supprimer des données à la fin d'un fichier PDF, après le dernier des %%EOF, il est à noter que je maîtrise ce que je rajoute dans le sens où je rajoute des clés (title= ; author= ; ...) et des valeurs ("the title of the article" ; "Author1 and Author2"; ... ), mais pas de commandes PDF.

Le mode append fonctionne si le fichier pdf ne contient pas de données, et si je souhaite en ajouter. Mais il me faut quand même trouver la fin du fichier pour effacer/modifier les données.

Effectivement je pourrais utiliser le rbegin et rend pour le parcours inverse, mais j'ai fait au plus rapide, les optimisations je les ferais plus tard.

Quant à la vérification des données, j'ai essayé sur plusieurs fichier pdf et cela me donne les résultats escomptés, mais il est vrai que le test doit être plus consistant et ne pas se baser sur une simple vérification du caractère '%' , mais c'est un premier jet, il faut que je continue un peu avant d'être complêtement satisfait du résultat. Là où effectivement cela pourrait poser problème c'est si dans une valeur, le caractère '%' est trouvé, mais le test doit être plus complet.

Sur les conseils de Luc (si je peux l'appeler comme ça), j'ai remplacé les indices de mon parcours inverse bizarre par des indices plus usuels : rbegin() et rend().

J'ai aussi remplacé le simple test du '%' par un test plus complet qui ne demande qu'à être amélioré et simplifié.

Le comportement du programme a l'air correct, mais j'ai fait seulement quelques tests, il ne demande qu'à être éprouvé, si vous trouvez des cas pour lesquels cela bug, je suis preneur, idem pour le test du '%'.

Voici le code :

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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
 
#include <cstdio>
#include <cstdlib>
#include <iostream>
#include <vector>
 
using namespace std;
 
int main ()
{
  FILE * pFile;
 
  vector<char> buffer;
 
  int count = -1;  
  bool result = true;
 
  char c;
  char test_eof[4];
 
  int n=0;
 
  pFile = fopen ("fichier.pdf","r");   
 
  while (result)
  {
      fseek(pFile, count, SEEK_END);
      c = fgetc(pFile);
//      printf("%d",count);
      if (c=='%')
         {   
             n =  buffer.size(); 
             if (n > 3)
                {   
//                   printf("%d\n", n);
                   for (int i=0; i<3; i++)
                      {
                          test_eof[i]=buffer[n-i-1];
//                          cout << i << " " << buffer[n-i-1] << "\n";
                      }
                      test_eof[3]='\0';
                   if (strcmp(test_eof,"EOF") == 0)
                       {
                           result = false;
//                           printf("\nYES\n");
                       }
                   else
                       {
                           buffer.push_back(c);
                       }
//                   printf("\n%s\n", test_eof);
                }
         }
      else
         {
//             printf("%c", c);
             buffer.push_back(c);
         }    
      count -= 1;
  }
 
  fclose(pFile);
 
  vector<char>::reverse_iterator reverse_idx;
 
  printf("contenu du fichier:\n");
  for( reverse_idx = buffer.rbegin()+3; reverse_idx != buffer.rend(); reverse_idx++ )    
     cout << *reverse_idx;
 
  system("pause");
  return 0;
}

J'attend vos remarques
@+

25/09/2006, 22h20
Luc Hermitte

Citation:

Envoyé par JµL!eN

Sur les conseils de Luc (si je peux l'appeler comme ça)

Le contraire serat malheureux :)

Citation:

Le comportement du programme a l'air correct, mais j'ai fait seulement quelques tests, il ne demande qu'à être éprouvé, si vous trouvez des cas pour lesquels cela bug, je suis preneur, idem pour le test du '%'.

Sur un fichier invalide (qui n'est pas un pdf valide qui ne contient donc pas ce que tu recherches), je ne sais pas trop comment cela va finir. Il faudrait tester ton count par rapport à la taille du fichier.

Par contre ta lecture me parait complètement inefficace.
Quitte à partir de la fin, je l'aurai fait par blocs. Au détail que cela change divers petits détails.

<pinaillages>
D'un point de vue qualité, en C++ on préfère réaliser des déclarations initialisantes (et qui contruisent dans le cas des objets) plutôt que le déboublement que l'on a en C. Certains conseillent même de déclarer "const" les variables locales qui ne varient en fait pas.

La recherche sur "%eof" doit pouvoir s'améliorer sans avoir besoin d'avoir à recopier 4 caractères à chaque lecture.

Tu dois pouvoir réserver, à l'avance, de la mémoire pour le vecteur. Si tu n'as pas vraiment idée que la taille max moyenne de la zone que tu rajoutes, tu peux partir sur la taille du fichier.
</>
25/09/2006, 22h56
JµL!eN

Bonsoir, Luc, (je ne savais pas si on pouvait se tutoyer ;-))

Citation:

Sur un fichier invalide (qui n'est pas un pdf valide qui ne contient donc pas ce que tu recherches), je ne sais pas trop comment cela va finir. Il faudrait tester ton count par rapport à la taille du fichier.

Généralement je préfère lire des fichiers pdf valides, ça facilite la lecture ;-) blague à part c'est vrai que si le fichier est pourri, la lecture le sera aussi!

Citation:

Par contre ta lecture me parait complètement inefficace.

Je trouvais que ça marchait bien, sauf effectivement pour les fichiers pdf invalides.

Citation:

Quitte à partir de la fin, je l'aurai fait par blocs. Au détail que cela change divers petits détails.

Là je ne vois pas trop ce que tu entends par 'blocs', je ne cherche pas à trouver tous les '%%EOF' du fichier mais seulement le dernier, mais si tu as un exemple sous la main, je veux bien tester.

Citation:

Tu dois pouvoir réserver, à l'avance, de la mémoire pour le vecteur. Si tu n'as pas vraiment idée que la taille max moyenne de la zone que tu rajoutes, tu peux partir sur la taille du fichier.

Pour la mémoire, c'est vrai, je ne m'en préoccupe pas trop, je pensais que 'vector.push_back(qqch)' s'en chargeait, mais je me trompe peut-être. Mais allouer une chaine de caratères de la taille du fichier (comme limite) est une solution.

Citation:

La recherche sur "%eof" doit pouvoir s'améliorer sans avoir besoin d'avoir à recopier 4 caractères à chaque lecture.

Je pense avoir vu quelque chose pour améliorer le traitement sur la chaine, faut que je regarde si ça marche bien avec 'vector'.

Je vais essayer de traverser le fichier en mode binaire, mais je pense que pour détecter la chaîne '%%EOF', en fin de fichier, ce sera difficile. Mais je vais tester quand même, pour qu'on ne dise pas que je suis réfractaire aux idées des autres ;-)

Citation:

Envoyé par JµL!eN

Bonsoir, Luc, (je ne savais pas si on pouvait se tutoyer ;-))

Sur le net, j'ai vraiment du mal avec le vouvoyement. Ca fait trop bizarre.

Citation:

Généralement je préfère lire des fichiers pdf valides, ça facilite la lecture ;-) blague à part c'est vrai que si le fichier est pourri, la lecture le sera aussi!

Je disais juste ça pour éviter le coredump.

Citation:

Là je ne vois pas trop ce que tu entends par 'blocs', je ne cherche pas à trouver tous les '%%EOF' du fichier mais seulement le dernier, mais si tu as un exemple sous la main, je veux bien tester.

Ben par bloc de 512 ou autre qui soit efficace sur ton systême. Je ne suis pas un pro des optims fichiers, mais j'en suis toujours resté au fait que la lecture caractère par caractère n'était pas efficace. Par contre, pour lire par blocs, il va falloir renverser ce que tu lis, ou faire des push_front.
Hum... je vois que deque ne sait pas les faire par bloc :? Du coup il faudrait une liste de vecteurs (une deque gérée à la main quoi) avec une fonction spécialisée pour la recherche. cool. :(
En pseudo code pondu en direct, et buggué, cela donnerait:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 std::list<std::vector<char> > buffers; int buf_size = 512; for( int pos = file_length - buf_size ; buf_size != 0 ; buf_size -= min(512,pos), pos -= buf_size) // va certainement planter => faire un while { buffers.push_front(std::vector<char>()); buffers.front().resize(buf_size); if(! file . read( &buffers.front()[0], buf_size)) break; if ( found(buffers) ) break; }
Citation:

Pour la mémoire, c'est vrai, je ne m'en préoccupe pas trop, je pensais que 'vector.push_back(qqch)' s'en chargeait, mais je me trompe peut-être. Mais allouer une chaine de caratères de la taille du fichier (comme limite) est une solution.

C'est juste pour éviter une 10aines d'allocations.

Citation:

Je pense avoir vu quelque chose pour améliorer le traitement sur la chaine, faut que je regarde si ça marche bien avec 'vector'.

Pour optimiser, je crains qu'il faille implémenter ta propre fonction de recherche un peu particulière : un strcmp qui utilise un -- au lieu d'un des deux ++.

26/09/2006, 00h11
JµL!eN

Je ne cherchais pas à faire quelque chose d'aussi compliqué que ça (deque ou liste de vector).

Pour la lecture, comme je sais que ce que je dois chercher se trouve plus près de la fin que du début (en général), pourquoi ne pas lire le fichier à partir de la fin directement? Partir du début serait un traitement général. Je peux lire à partir de la fin en mode binaire, en faisant gaffe à la taille de mon fichier.

Citation:

Citation:

Pour la mémoire, c'est vrai, je ne m'en préoccupe pas trop, je pensais que 'vector.push_back(qqch)' s'en chargeait, mais je me trompe peut-être. Mais allouer une chaine de caratères de la taille du fichier (comme limite) est une solution.

C'est juste pour éviter une 10aines d'allocations.

L'allocation se faisait pour chaque caractère qui devait être lu, il n'y a pas d'allocation en trop; l'affectation par le '.push_back' (donc l'allocation) se fait normalement ? Il y a tout au plus 3 ou 4 allocations de trop pour 'EOF' ou '%EOF' ;-)

Je regarderais le code que tu as esquissé plus tard (ou plus tôt ;-) ). Je regarderais aussi la lecture binaire en partant de la fin. Je n'arrive pas à voir comment parvenir à déchiffrer '%EOF' en binaire, peut-être parce qu'il est tard ;-)

@+
26/09/2006, 01h36
Luc Hermitte

A partir de la fin caractère par caractère, je crains que tu fasses plus d'accès disques que nécessaire. D'où que j'évoquais la bufferisation.

"Accès binaire" porte moyennement bien son nom. "raw" aurait peut-être été meilleur, je ne sais pas.
L'ouveture binaire signifie juste que certains caractères ne seront plus interprétés. Et que donc, cela sera à toi de savoir comment est codée une fin de ligne, ...
"%%eof" reste "%%eof". C'est toujours la même chaine qu'il faut chercher.

Fuseau horaire GMT +2. Il est actuellement 18h28.