Discussion :

[GoodSpeed]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

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 !

[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 ?

[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.

[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.

[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 !

[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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[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 ?

[GoodSpeed]

J'ai trouv� une solution:

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

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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 !

[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

[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 ...

[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

[GoodSpeed]

Probablement,

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:

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,