Discussion :

[ctxnop]

Bonjour !
J'ai un problème dont je ne trouve pas de solutions, a vrai dire je ne suis même pas véritablement certain de la cause.

Donc voila, j'ai un fichier texte (encodé d'après notepad++), format windows (donc les retours à la lignes sont "\r\n").
Chaque ligne fait exactement 520 caractères, ("\r\n" exclus), ni plus, ni moins, c'est une condition impérative.
La fonction StreamReader.ReadLine() ne retourne pas ces retous à la lignes, donc je dois obtenir une ligne de 520 caractères.

Je le lit donc avec un code ressemblant à ca

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
 
string filepath = "monfichier.txt";
StreamReader sr = new StreamReader(filepath);
string line = "";
while((line = sr.ReadLine()) != null)
{
    if(line.Length != 520)
    {
        txtReport.Text += "La ligne n'est pas au bon format." + Environment.NewLine;
        continue;
    }
    /*
        Le traitement de la ligne
    */
}

Ca fonctionne très bien sur mon ordi (Windows Vista 32bits, en français).

Seulement voilà, une fois chez le client (Windows 2003 server 64bits, en anglais), en lisant exactement le même fichier (la comparaison binaire ne retourne aucune différence)

Certaines lignes sont détectée comme n'étant pas au bon format, et donc ne faisant pas exactement 520 caractère.
On s'est aperçus que les lignes en question contiennent le caractère "°" (par exemple : "N°123").

Une idée de ce qui ne va pas et surtout, comment corriger ??

[Philippe Vialatte]

Salut,

tu peux éventuellement tracer les lignes lues, mais hje serais pres a parier que c'est un probleme de page de code...

Essaye de jouer avec le parametre encoding du constructeur :
http://msdn.microsoft.com/en-us/libr...57(VS.71).aspx

[ctxnop]

Salut,

tu peux éventuellement tracer les lignes lues, mais hje serais pres a parier que c'est un probleme de page de code...

Essaye de jouer avec le parametre encoding du constructeur :
http://msdn.microsoft.com/en-us/libr...57(VS.71).aspx

Tout d'abord, merci du temps que tu consacre a mon problème.

Qu'entends-tu par "tracer les lignes lues" ?

Pour l'histoire de l'endocage, j'y songe depuis un moment, mais ca me pose un problème. Admettons que je mette l'encodage à ASCII, si jamais le client essaye de lire un fichier encodé UTF-8, il va se passer quoi ? Le but étant normalement de lire un fichier, quelque soit son encodage, sachant que chaque ligne doit faire exactement 520 caractères imprimables.

Je vais tout de même tester, mais malheureusement les testes ne sont pas rapides car je dois générer ma version, l'envoyer au client, attendre qu'il teste, ...

[Philippe Vialatte]

Qu'entends-tu par "tracer les lignes lues" ?

Les ecrire dans un fichier de log ...

Regarde le tuto de lutecefalco sur log4net

http://lutecefalco.developpez.com/tu.../introduction/

Le but étant normalement de lire un fichier, quelque soit son encodage, sachant que chaque ligne doit faire exactement 520 caractères imprimables.

Sauf qu'en fonction de l'encodage, certains caracteres ne seront pas geres, ou geres differement...

[ctxnop]

Les ecrire dans un fichier de log ...

Regarde le tuto de lutecefalco sur log4net

http://lutecefalco.developpez.com/tu.../introduction/



Sauf qu'en fonction de l'encodage, certains caracteres ne seront pas geres, ou geres differement...

Oui je sais bien que certains caractères sont gérés différemment. Mais ca semble assez étrange dans la mesure où le fichier lut à été généré par le client, encodé en ANSI. Donc normalement, tous les caractères du fichiers sont tous ANSI et doivent tous être gérés pareil.

Si jamais le StreamReader considère lire de l'UTF-8, le "°" n'est plus affichable, mais pour autant, notepadd++ continue de me dire que la ligne fait 520 caractères.

Quoi qu'il en soit, j'ai généré une version en spécifiant l'encodage dans le StreamReader, j'attend le retour des clients pour savoir si ca corrige.

[ctxnop]

Bien j'ai enfin le retour des tests des clients, ca fonctionne normalement maintenant que j'ai forcé l'encodage en Encoding.ASCII. J'avais quand même quelques doutes par rapport à certains symptomes étranges.

Mais finalement ces symptomes s'expliquent par le fait que les dates et heures présentes dans le fichier n'étaient pas toujours dans le même format ce qui provoquait des décalages d'index...

Merci bien du coup de main.

[Philippe Vialatte]

de rien, j'ai eu le meme genre de pb a une epoque

[ctxnop]

Moi aussi j'avais déjà eu ce genre de problème, mais là vraiment, rapport à tous les tests et comportements que j'ai pu faire et observer, je pensais vraiment pas que ca n'était qu'une histoire d'encodage. Je me doutait bien que ca avait quelque chose a voir, mais je pensais qu'il y avait autre chose en plus.
Remarque ca a été le cas, puisqu'il y avait le problème des dates formattées n'importe comment.