[Encodage] Lecture d'un fichier

Version imprimable

Je viens de rencontrer un problème bizarre sur la lecture de fichier.

Je souhaite lire le fichier de rapport du logiciel NTBackup; pour m'avertir par mail si une sauvegarde a échoué.

J'ai utilisé la classe TStringList :
Code:

1 2 3 4 FichierLog->LoadFromFile("C:\\journaux\\backup09.log"); for (int Index=0 ; Index < FichierLog->Count ; Index++) if(RetourInfo,FichierLog->Strings[Index].Pos("Ignorés :")) StrLCopy(RetourInfo,FichierLog->Strings[Index].c_str(),MAXSIZE);
Ça ne marche pas 8O

Bon po grave, je le fais avec la bonne veille méthode fopen -> non plus !

A tout hasard, je tente de lire au autre fichier dans ce répertoire (un batch) et à ma grande surprise, ça marche !!!

Par contre quand je copie le contenu du fichier que je colle dans le notepad et que j'enregistre le tout, ce fichier devient lisible.

Si quelqu'un peut m'expliquer, je lui serais très reconnaissant !

Merci d'avance !

16/12/2004, 15h54
Trap D

Salut

Ce fichier Log est peut-être constamment ouvert par un process, et si LoadFromFile demande un accès exclusif au fichier, ça ne marche pas.
Explication non garantie.

Au fait "Ça ne marche pas". Qu'est ce qi ne marche pas exactement ?
16/12/2004, 16h13
GoodSpeed

Merci de ta réponse.

Concernant l'accès, je travail sur une copie du fichier original qui n'est pas verrouiller.

En fait, je n'ai pas d'erreur "propre", le problème est que quand j'essaie de lire mon fichier, j'ai en retour une valeur parasite.

Je suspect un problème sur l'enregistrement, j'ai déjà rencontré ce problème entre les fichiers enregistrés avec Edit sous dos et notepad ...

A l'époque, j'avais résolu mon problème par le copier coller.
16/12/2004, 16h27
Trap D

Salut
Le problème est peut-être celui des retours chariot, regarde avec un éditeur hexa si tu as "\r\n" 0x0D 0x0A (ou le contraire je ne sais jamais) à tes fins de lignes, tu n'as peut-être qu'un seul des deux => problème avec LoadFromFile.
16/12/2004, 16h52
henderson

Salut !

Voir également si un fichier avec une extension .log peut être chargé
en tant que .txt. Il y a peut-être un formatage particulier.
A tester avec le Bloc Notes ou WinWord, ou directement avec un TMemo
ou TRichEdit pour voir le résultat !

Voir également sur le site WOTSIT.com en cas de formatage particulier.
Si le .log y est répertorié alors il devrait y avoir des explications sur ce formatage !

Par exemple, tu peux très bien avoir une suite de chaînes à caractère terminal NUL et
dans ce cas, je ne sais pas si, pour cet exemple, les chaînes seraient bien
différenciées les unes des autres (sans les LF et CR à la fin de chaque chaîne)
Dans ce cas précis tu ne récupèrerait peut-être qu'une seule chaîne.
(Mais... ce que je dis est peut-être idiot ???).

A plus !
16/12/2004, 17h07
GoodSpeed

Bien vu Trap D !

Aprés édition en Hexa, je constat en effet une différence de struture :

Voici en hexa la première ligne du fichier qui marche :

Code:

C9 74 61 74 20 64 65 20 6C 61 20 73 61 75 76 65 67 61 72 64 65 0D 0A

et voici le même ligne du fichier qui ne fonctionne pas

Code:

FF FE C9 00 74 00 61 00 74 00 20 00 64 00 65 00 20 00 6C 00 61 00 20 00 73 00 61 00 75 00 76 00 65 00 67 00 61 00 72 00 64 00 65 00 0D 00 0A 00

Savez vous comment convertir l'encodage des fichiers afin qu'il soit lisible par la méthode LoadFromFile

Je regarde ce que tu viens de me dire henderson

Merci encore
16/12/2004, 17h40
GoodSpeed

En cherchant sur le net, j'ai trouvé la notion concernant l'enregistrement des fichiers.

On parle de fichier enregistré en OEM, ANSI ou en UNICODE ...

ça inspire quelqu'un ?

J'ai trouvé une solution:

J'ouvre le fichier en binaire, puis je supprime les octets en trop :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if ((Fichier = fopen(NomFichier, "r+b"))!= NULL)
    {while (!feof(Fichier))
     {  IntCaractere = fgetc(Fichier);
        if (IntCaractere!= 255 && IntCaractere!= 0 && IntCaractere!= 254 && IntCaractere!= 10)
        {   if (IntCaractere != 13)
                 Ligne = Ligne + (AnsiString)(char)IntCaractere;
            else
           {
  //Traitement sur la ligne          
               Ligne ="";
           }
          }
        }
     }
     fclose(Fichier);
    }

Merci de votre aide !

:coucou:

17/12/2004, 17h35
Greybird

Bonjour,

As-tu essayé de stocker le fichier dans une WideString, puis de convertir cette dernière en AnsiString, via la fonction WideCharToMultiByte ou son inverse ?

Parce que ton code, s'il fonctionne, peut très bien se mettre à tout détruire si par exemple tu tombe sur un caractère euro ou ce genre de chose.

Arnaud
17/12/2004, 17h55
GoodSpeed

Je te confirme que ce code fonctionne trés bien ...

Concernant ta remarque, je suis d'accord avec toi. Cependant le traitement du fichier Unicode que je lis concerne une valeur constante (La chaine "Ignorés :") qui n'aura jamais de caractère particulier.

Si cela ce produit ( un symbole codé sur 2 octets (par ex. €) ) je vais avoir un caractère zarbi , mais comme ma valeur de test n'est pas corrumpu no problème.

Concernant ta question, j'ai testé un truc de ce genre, cela ne fonctionné pas car lorsque j'essayé d'ouvrir le fichier en mode texte, j'avais systèmatiquement une valeur parasite (cf : 1 post )

Merci quand même de ton aide ... :)
17/12/2004, 18h05
Greybird

Bonjour,

J'ai bien pris note du fait que ta résolution suffisait dans ton cas.

Concernant le fait que tu n'y ai pas arrivé en mode texte, je pense que tu n'as pas du utiliser les fonctions spécifiques aux WideChar pour ouvrir le fichier.
Quand à la valeur parasite FF FE elle sert à indiquer l'ordre des deux octets qui constituent le WideChar si je me souviens bien.

Cordialement,

Arnaud
17/12/2004, 18h31
GoodSpeed

Probablement,

Citation:

Quand à la valeur parasite FF FE elle sert à indiquer l'ordre des deux octets qui constituent le WideChar si je me souviens bien.

C'est tout à fait cela, voici un extrait d'un site qui explique l'unicode:

Citation:

Il existe donc dans la norme Unicode un marqueur de l'ordre du flux pour faire cette différence. C'est le BOM (Byte Order Mark) qui vaut 0xFEFF et sera représenté 0xFF 0xFE sur une machine little endian Windows et 0xFE 0xFF sur les machines big endian. Ce marqueur est indispensable pour qu'un fichier texte soit vu comme fichier Unicode

http://www.codeppc.com/evc/articles/unicode.html

Cordialement,