Lecture de fichier octets

Le
Gloops
Bonjour tout le monde,

J'ai voulu dépanner quelqu'un qui ne réussissait plus à lire le con=
tenu
de fichiers de messagerie instantanée, je soupçonne une codification =

comme pour les mails, sur 7 octets, au pire j'aurais essayé pour rien.

Si je lis avec un StreamReader, en fournissant en argument seulement le
chemin vers le fichier, j'ai un octet par ci par là de valide, les
autres sont mis à 0xfffd.

Si en deuxième argument j'ajoute Encoding.Default, il y a un net progrè=
s
: la fenêtre Watch, de Visual Studio, me présente les mêmes graphis=
mes
de caractères que EditHexa 8.1 d'Eric Dauteuille.

En revanche, quelque chose m'ennuie : les codes, eux, ne sont pas les
mêmes, ce qui est quand même gênant si le but est de faire des
opérations sur les bits pour les réassembler d'un octet à l'autre.

Par exemple, pour le premier octet, certes je n'ai plus 0xfffd, mais
j'ai 0x017D au lieu de 0X008E.

Le suivant est bien à 0X003A, ça c'est bon.

Et j'en ai quelques autres comme ça un peu plus loin.

J'ai essayé plusieurs Encoding, mais default semble être celui qui do=
nne
les résultats les moins délirants, encore que je n'aie pas essayé t=
ous
les différents UTF. Est-ce par là qu'il faut chercher ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gloops
Le #21316591
C'est juste chez moi que je zozotte ?
Gloops
Le #21320021
Bon ben vous savez quoi, j'obtiens le même résultat sous Javascript v ia
le FileSystemObject.

Il n'y a guère qu'en ressortant un GWBasic d'un fond de tiroir que j'ai
réussi à lire le fichier correctement.

Ce n'est pas ça la bonne réponse, quand même ?
_____________________________________
Gloops a écrit, le 04/03/2010 19:28 :
Bonjour tout le monde,

J'ai voulu dépanner quelqu'un qui ne réussissait plus à lire le c ontenu
de fichiers de messagerie instantanée, je soupçonne une codificatio n
comme pour les mails, sur 7 octets, au pire j'aurais essayé pour rien .

Si je lis avec un StreamReader, en fournissant en argument seulement le
chemin vers le fichier, j'ai un octet par ci par là de valide, les
autres sont mis à 0xfffd.

Si en deuxième argument j'ajoute Encoding.Default, il y a un net prog rès
: la fenêtre Watch, de Visual Studio, me présente les mêmes graph ismes
de caractères que EditHexa 8.1 d'Eric Dauteuille.

En revanche, quelque chose m'ennuie : les codes, eux, ne sont pas les
mêmes, ce qui est quand même gênant si le but est de faire des
opérations sur les bits pour les réassembler d'un octet à l'autre .

Par exemple, pour le premier octet, certes je n'ai plus 0xfffd, mais
j'ai 0x017D au lieu de 0X008E.

Le suivant est bien à 0X003A, ça c'est bon.

Et j'en ai quelques autres comme ça un peu plus loin.

J'ai essayé plusieurs Encoding, mais default semble être celui qui donne
les résultats les moins délirants, encore que je n'aie pas essayé tous
les différents UTF. Est-ce par là qu'il faut chercher ?

Gloops
Le #21334691
Ben, moi qui croyais poser une question au niveau des pâquerettes ...

C'est un peu inquiétant que ça n'inspire pas plus de monde ...
_____________________________________
Gloops a écrit, le 04/03/2010 19:28 :
Bonjour tout le monde,

J'ai voulu dépanner quelqu'un qui ne réussissait plus à lire le c ontenu
de fichiers de messagerie instantanée, je soupçonne une codificatio n
comme pour les mails, sur 7 octets, au pire j'aurais essayé pour rien .

Si je lis avec un StreamReader, en fournissant en argument seulement le
chemin vers le fichier, j'ai un octet par ci par là de valide, les
autres sont mis à 0xfffd.

Si en deuxième argument j'ajoute Encoding.Default, il y a un net prog rès
: la fenêtre Watch, de Visual Studio, me présente les mêmes graph ismes
de caractères que EditHexa 8.1 d'Eric Dauteuille.

En revanche, quelque chose m'ennuie : les codes, eux, ne sont pas les
mêmes, ce qui est quand même gênant si le but est de faire des
opérations sur les bits pour les réassembler d'un octet à l'autre .

Par exemple, pour le premier octet, certes je n'ai plus 0xfffd, mais
j'ai 0x017D au lieu de 0X008E.

Le suivant est bien à 0X003A, ça c'est bon.

Et j'en ai quelques autres comme ça un peu plus loin.

J'ai essayé plusieurs Encoding, mais default semble être celui qui donne
les résultats les moins délirants, encore que je n'aie pas essayé tous
les différents UTF. Est-ce par là qu'il faut chercher ?

Gloops
Le #21334681
Gloops a écrit, le 05/03/2010 12:03 :
Bon ben vous savez quoi, j'obtiens le même résultat sous Javascript via
le FileSystemObject.

Il n'y a guère qu'en ressortant un GWBasic d'un fond de tiroir que j' ai
réussi à lire le fichier correctement.

Ce n'est pas ça la bonne réponse, quand même ?




Parce que si oui alors j'aurais bien une autre question, cette fois au
sujet de la création de fonctions dans GWBasic, mais ... quand je
regarde le nom du newsgroup je me dis qu'il y a comme une hésitation.
Patrice
Le #21335101
D'une part le groupe français n'est pas plus fréquenté que cela.

D'autre part, le problème est qu'il faudrait savoir comment est encodé le
fichier. Ce n'est pas que gw-basic soit seul capable de lire le fichier mais
sans doute que la méthode utilisée pour lire le fichier applique un encodage
qui n'est sans doute pas le bon.
Le même résultat pourrait être obtenu avec un BinaryReader pour lire le
fichier sans ancun encodage. Egalement mes souvenirs sont un peu imprécis,
mais gwbasic toujours dans une fenêtre dos et pourrait utiliser la page de
code 850 pour son affichage...

Ou alors reprendre le problème à l'origine, il n'y a aucune raison que l'on
ne puisse plus lire subitement un "fichier de messagerie instantanée"
(apparemment c'est du xml pour Messenger par exemple donc sans doute
l'ouvrir avec IE pourrait bien marcher).

--
Patrice

"Gloops" news:%
Ben, moi qui croyais poser une question au niveau des pâquerettes ...

C'est un peu inquiétant que ça n'inspire pas plus de monde
Gloops
Le #21337011
Patrice a écrit, le 07/03/2010 13:37 :
Le même résultat pourrait être obtenu avec un BinaryReader pour l ire le
fichier sans ancun encodage.



Ah, voilà qui a l'air de sonner juste :)
Je vais essayer de ce côté.

Parce que effectivement, quand dans une fenêtre je vois une virgule à la
place d'un e accent aigu, je sais que c'est un problème d'encodage, don c
ça signifie qu'on n'affecte pas les bons graphismes aux bons codes de
caractères. Mais c'est quand le code lu n'est pas celui qui est dans le
fichier (vérifié sous Debug ou un éditeur hexadécimal, auxquels j 'ai
tendance à faire confiance), que ça me gêne le plus, même si les
programmes utilisés réussissent à faire apparaître les mêmes gr aphismes
avec ces codes de caractères différents.

Ou alors reprendre le problème à l'origine, il n'y a aucune raison que
l'on ne puisse plus lire subitement un "fichier de messagerie
instantanée" (apparemment c'est du xml pour Messenger par exemple don c
sans doute l'ouvrir avec IE pourrait bien marcher).




Du xml ?
Je ne suis pas nécessairement le plus calé en xml, mais je crois savo ir
que là-dedans on doit voir les noms des champs et leur contenu en texte ,
qu'en tout cas ça doit donner quelque chose de lisible par un humain à
défaut d'être disposé de la manière la plus facile à appréhen der ?

Là, l'encodage proposé était de cet ordre :
Ž:¬då˜O3}¹êF˜ŽÜ,ùãÁFžì”é½V]JV¦oWfo~
(ça vient du newsgroup Word même si le choix du newsgroup en question
peut laisser songeur.)

Il s'avère que la piste du Quoted Printable n'était pas forcément l a
bonne ou alors là on a la transcription de champs numériques, pourquo i pas.

Bref je ne crois pas que je pourrai proposer à l'intéressé quelque chose
qui lui permettra vraiment de lire sa sauvegarde, mais au moins ça m'a
permis de détecter une faille dans mon usage de C#, c'est quelque chose
d'utile à combler.

Bon, BinaryReader, alors, on a dit ...
Je vais aller voir ça.
Gloops
Le #21337501
Gloops a écrit, le 07/03/2010 17:56 :
Bon, BinaryReader, alors, on a dit ...
Je vais aller voir ça.





string fileName = @"msg.txt";
using(BinaryReader sr =
new BinaryReader(File.Open(fileName, FileMode.Open)))
{

char[] c = null;
while (sr.PeekChar() != -1)
{
c = new char[7];
c = sr.ReadChars(7);
Console.WriteLine(c);
}
}

J'ai toujours le même défaut, le premier caractère est lu à 0xFFF D au
lieu de 0x8E.
Patrice
Le #21347901
Au temps pour moi, le BinaryReader utilise également UTF8 par défaut.
L'idéal serait de savoir qu'elle est l'encodage à utiliser pour pouvoir le
préciser dans l'ouverture du fichier... Je dirais peut-être une page de code
850 ?

Sinon je ne vois pas pourqui un fichier de newsgroup deviendrait
soudainement inaccessible. Le lire avec le logiciel de newsgroup
correspondant ne fonctionne plus ?

0x8e devrait afficher quoi ?

Sinon d'après ce que je vois c'est finalement FileStream qui devrait
convenir (mais le problème restera entier pour l'affichage)...

--
Patrice

"Gloops" discussion : #
Gloops a écrit, le 07/03/2010 17:56 :
Bon, BinaryReader, alors, on a dit ...
Je vais aller voir ça.





string fileName = @"msg.txt";
using(BinaryReader sr > new BinaryReader(File.Open(fileName, FileMode.Open)))
{

char[] c = null;
while (sr.PeekChar() != -1)
{
c = new char[7];
c = sr.ReadChars(7);
Console.WriteLine(c);
}
}

J'ai toujours le même défaut, le premier caractère est lu à 0xFFFD au lieu
de 0x8E.
Gloops
Le #21352121
Patrice a écrit, le 09/03/2010 13:19 :
Au temps pour moi, le BinaryReader utilise également UTF8 par défau t.
L'idéal serait de savoir qu'elle est l'encodage à utiliser pour pou voir le
préciser dans l'ouverture du fichier... Je dirais peut-être une pag e de code
850 ?



Ah l'encodage, c'est pour l'affichage ...


Sinon je ne vois pas pourqui un fichier de newsgroup deviendrait
soudainement inaccessible. Le lire avec le logiciel de newsgroup
correspondant ne fonctionne plus ?



C'est vrai que le fil qui a initié la conversation se finit en eau de
boudin, mais maintenant que j'ai soulevé cette question de code ASCII
qui sort à autre chose que ce qu'on voit dans le fichier avec un édit eur
hexadécimal, autant en avoir le cœur net, pour lire les codes des
caractères.


0x8e devrait afficher quoi ?



J'ai mis le "texte" deux messages plus haut, le premier caractère c'est
l'espèce de Z avec un accent au-dessus, qu'en Français on aurait
tendance à appeler accent circonflexe retourné (genre d'accent qu'on
utilise plutôt dans les langues de l'Est mais j'avoue mon ignorance
quant à son nom).
Concrètement : Ž
D'ailleurs, c'est simple, tu presses la touches Alt, tu tapes 142 sur le
pavé numérique, et quand tu lâches la touche Alt tu vois apparaît re le
caractère :)
Ah oui, c'est vrai que l'aspect graphique, lui, dépend de la page de
code affichée pour l'affichage, sauf si j'ai loupé un truc.


Sinon d'après ce que je vois c'est finalement FileStream qui devrait
convenir (mais le problème restera entier pour l'affichage)...



Ah, ben voilà, effectivement, cette fois, on sort bien les bons
caractères, du moins à en juger par les codes.
C'est vrai que l'affichage n'est plus bon, enfin ça c'est une autre
question, c'est bien là qu'intervient la notion d'encodage -on a eu
assez de mal à l'enlever :)

Je me demande si je ne vais pas réviser les histoires de pagecode en
mode console ...

Merci pour cette bonne réponse.
Gloops
Le #21352271
Gloops a écrit, le 09/03/2010 23:43 :
Ah, ben voilà, effectivement, cette fois, on sort bien les bons
caractères, du moins à en juger par les codes.



Au passage, question "subsidiaire" : saurais-tu faire la même chose ave c
le FileSystemObject ?

C'est juste que je risque d'être tenté de faire ça en Javascript, l à
c'est vrai qu'on sort du contexte ...
Publicité
Poster une réponse
Anonyme