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 ?
