J'ai voulu d=E9panner quelqu'un qui ne r=E9ussissait plus =E0 lire le con=
tenu=20
de fichiers de messagerie instantan=E9e, je soup=E7onne une codification =
comme pour les mails, sur 7 octets, au pire j'aurais essay=E9 pour rien.
Si je lis avec un StreamReader, en fournissant en argument seulement le=20
chemin vers le fichier, j'ai un octet par ci par l=E0 de valide, les=20
autres sont mis =E0 0xfffd.
Si en deuxi=E8me argument j'ajoute Encoding.Default, il y a un net progr=E8=
s=20
: la fen=EAtre Watch, de Visual Studio, me pr=E9sente les m=EAmes graphis=
mes=20
de caract=E8res que EditHexa 8.1 d'Eric Dauteuille.
En revanche, quelque chose m'ennuie : les codes, eux, ne sont pas les=20
m=EAmes, ce qui est quand m=EAme g=EAnant si le but est de faire des=20
op=E9rations sur les bits pour les r=E9assembler d'un octet =E0 l'autre.
Par exemple, pour le premier octet, certes je n'ai plus 0xfffd, mais=20
j'ai 0x017D au lieu de 0X008E.
Le suivant est bien =E0 0X003A, =E7a c'est bon.
Et j'en ai quelques autres comme =E7a un peu plus loin.
J'ai essay=E9 plusieurs Encoding, mais default semble =EAtre celui qui do=
nne=20
les r=E9sultats les moins d=E9lirants, encore que je n'aie pas essay=E9 t=
ous=20
les diff=E9rents UTF. Est-ce par l=E0 qu'il faut chercher ?
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 ?
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 ?
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
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 ?
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 ?
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
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.
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.
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
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" a écrit dans le message de 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
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" <gloops@invalid.zailes.org> a écrit dans le message de
news:%23bAHKjevKHA.3536@TK2MSFTNGP06.phx.gbl...
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
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" a écrit dans le message de 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
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.
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.
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
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.
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.
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
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" a écrit dans le message de groupe de 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.
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" <gloops@invalid.zailes.org> a écrit dans le message de groupe de
discussion : #CUGEiivKHA.5936@TK2MSFTNGP04.phx.gbl...
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.
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" a écrit dans le message de groupe de 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
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 cur 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.
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 cur 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 ...
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 cur 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
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 ...
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 ...
