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,