Tiens, j'aurais cru que sur une question pareille tout avait =E9t=E9 dit =
=2E..
Na=EFve pens=E9e.
J'alimente une RichTextBox avec un fichier texte =E0 l'ouverture de mon=20
formulaire, le code commence par :
Encoding enc =3D Encoding.UTF7;
using (StreamReader sr =3D new StreamReader(ofd.FileName, enc))
Le choix de UTF7 a =E9t=E9 arbitraire, il d=E9coule d'un t=E2tonnement : =
c'est=20
la seule valeur qui me permet de voir les caract=E8res accentu=E9s. Le=20
probl=E8me, c'est que si j'ai un "e dans l'o", =E7a m'affiche un graphism=
e=20
certes =E9l=E9gant, mais qui n'a rien =E0 voir avec un e ni un o et encor=
e=20
moins l'un dans l'autre.
En s=E9lectionnant le fran=E7ais dans la propri=E9t=E9 Language du formul=
aire je=20
ne m'attends gu=E8re =E0 ce que =E7a r=E9solve la question, mais =E0 tout=
es fins=20
utiles je pr=E9cise que j'ai essay=E9 quand m=EAme.
Ah, d'ailleurs curieusement, au niveau du formulaire je n'ai pas su=20
trouver Culture et UICulture, Dieu sait pourtant que j'ai d=E9j=E0 jou=E9=
avec =E7a.
Il me semblait bien que le choix d'un jeu de caract=E8res doit pouvoir se=
=20
faire en fonction de la culture, de la langue =E0 afficher, or dans les=20
valeurs de l'=E9num=E9ration Encoding, la seule chose qui puisse un peu=20
=E9voquer une culture c'est BigEndian et encore en n'=E9tant pas all=E9 v=
oir=20
de trop pr=E8s ce que =E7a veut dire.
Est-ce qu'il y a un autre boulon =E0 serrer, ailleurs ?
Comme =E7a avant d'avoir vraiment creus=E9 j'ai l'impression d'avoir fait=
ce=20
qu'il faut au niveau de l'ouverture de fichier, on sait sur combien de=20
bits est cod=E9 chaque caract=E8re, mais que maintenant il s'agirait que =
le=20
contr=F4le de RichTextBox puisse afficher =E7a avec les bons graphismes. =
J'aurais donc tendance =E0 chercher davantage dans les propri=E9t=E9s de =
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gloops
Bon, on dirait que j'ai à présent un élément de réflexion à a jouter.
J'ai réalisé un deuxième enregistrement, qui inclut les mêmes don nées qu'hier, plus autre chose. Le e dans l'o aurait dû apparaître exactem ent de la même manière. Or, cette fois il apparaît correctement.
Il n'est donc pas à exclure que ce qui a causé problème se situe au niveau du programme qui a écrit les fichiers, plutôt qu'au niveau de celui que j'écris pour les lire.
A moins que quelqu'un ait quelque chose à ajouter sur la question ...
Le choix par tâtonnement du jeu de caractères était-il la bonne app roche ? _____________________________________ Gloops a écrit, le 02/02/2009 01:12 :
Bonjour tout le monde,
Tiens, j'aurais cru que sur une question pareille tout avait été di t ... Naïve pensée.
J'alimente une RichTextBox avec un fichier texte à l'ouverture de mon formulaire, le code commence par :
Encoding enc = Encoding.UTF7; using (StreamReader sr = new StreamReader(ofd.FileName, enc))
Le choix de UTF7 a été arbitraire, il découle d'un tâtonnement : c'est la seule valeur qui me permet de voir les caractères accentués. Le problème, c'est que si j'ai un "e dans l'o", ça m'affiche un graphi sme certes élégant, mais qui n'a rien à voir avec un e ni un o et enc ore moins l'un dans l'autre.
En sélectionnant le français dans la propriété Language du form ulaire je ne m'attends guère à ce que ça résolve la question, mais à to utes fins utiles je précise que j'ai essayé quand même.
Ah, d'ailleurs curieusement, au niveau du formulaire je n'ai pas su trouver Culture et UICulture, Dieu sait pourtant que j'ai déjà joué avec ça.
Il me semblait bien que le choix d'un jeu de caractères doit pouvoir se faire en fonction de la culture, de la langue à afficher, or dans les valeurs de l'énumération Encoding, la seule chose qui puisse un peu évoquer une culture c'est BigEndian et encore en n'étant pas allé voir de trop près ce que ça veut dire.
Est-ce qu'il y a un autre boulon à serrer, ailleurs ? Comme ça avant d'avoir vraiment creusé j'ai l'impression d'avoir fa it ce qu'il faut au niveau de l'ouverture de fichier, on sait sur combien de bits est codé chaque caractère, mais que maintenant il s'agirait qu e le contrôle de RichTextBox puisse afficher ça avec les bons graphismes . J'aurais donc tendance à chercher davantage dans les propriétés d e RichTextBox. Ai-je tort ?
Bon, on dirait que j'ai à présent un élément de réflexion à a jouter.
J'ai réalisé un deuxième enregistrement, qui inclut les mêmes don nées
qu'hier, plus autre chose. Le e dans l'o aurait dû apparaître exactem ent
de la même manière. Or, cette fois il apparaît correctement.
Il n'est donc pas à exclure que ce qui a causé problème se situe au
niveau du programme qui a écrit les fichiers, plutôt qu'au niveau de
celui que j'écris pour les lire.
A moins que quelqu'un ait quelque chose à ajouter sur la question ...
Le choix par tâtonnement du jeu de caractères était-il la bonne app roche ?
_____________________________________
Gloops a écrit, le 02/02/2009 01:12 :
Bonjour tout le monde,
Tiens, j'aurais cru que sur une question pareille tout avait été di t ...
Naïve pensée.
J'alimente une RichTextBox avec un fichier texte à l'ouverture de mon
formulaire, le code commence par :
Encoding enc = Encoding.UTF7;
using (StreamReader sr = new StreamReader(ofd.FileName, enc))
Le choix de UTF7 a été arbitraire, il découle d'un tâtonnement : c'est
la seule valeur qui me permet de voir les caractères accentués. Le
problème, c'est que si j'ai un "e dans l'o", ça m'affiche un graphi sme
certes élégant, mais qui n'a rien à voir avec un e ni un o et enc ore
moins l'un dans l'autre.
En sélectionnant le français dans la propriété Language du form ulaire je
ne m'attends guère à ce que ça résolve la question, mais à to utes fins
utiles je précise que j'ai essayé quand même.
Ah, d'ailleurs curieusement, au niveau du formulaire je n'ai pas su
trouver Culture et UICulture, Dieu sait pourtant que j'ai déjà joué avec
ça.
Il me semblait bien que le choix d'un jeu de caractères doit pouvoir se
faire en fonction de la culture, de la langue à afficher, or dans les
valeurs de l'énumération Encoding, la seule chose qui puisse un peu
évoquer une culture c'est BigEndian et encore en n'étant pas allé voir
de trop près ce que ça veut dire.
Est-ce qu'il y a un autre boulon à serrer, ailleurs ?
Comme ça avant d'avoir vraiment creusé j'ai l'impression d'avoir fa it ce
qu'il faut au niveau de l'ouverture de fichier, on sait sur combien de
bits est codé chaque caractère, mais que maintenant il s'agirait qu e le
contrôle de RichTextBox puisse afficher ça avec les bons graphismes .
J'aurais donc tendance à chercher davantage dans les propriétés d e
RichTextBox. Ai-je tort ?
Bon, on dirait que j'ai à présent un élément de réflexion à a jouter.
J'ai réalisé un deuxième enregistrement, qui inclut les mêmes don nées qu'hier, plus autre chose. Le e dans l'o aurait dû apparaître exactem ent de la même manière. Or, cette fois il apparaît correctement.
Il n'est donc pas à exclure que ce qui a causé problème se situe au niveau du programme qui a écrit les fichiers, plutôt qu'au niveau de celui que j'écris pour les lire.
A moins que quelqu'un ait quelque chose à ajouter sur la question ...
Le choix par tâtonnement du jeu de caractères était-il la bonne app roche ? _____________________________________ Gloops a écrit, le 02/02/2009 01:12 :
Bonjour tout le monde,
Tiens, j'aurais cru que sur une question pareille tout avait été di t ... Naïve pensée.
J'alimente une RichTextBox avec un fichier texte à l'ouverture de mon formulaire, le code commence par :
Encoding enc = Encoding.UTF7; using (StreamReader sr = new StreamReader(ofd.FileName, enc))
Le choix de UTF7 a été arbitraire, il découle d'un tâtonnement : c'est la seule valeur qui me permet de voir les caractères accentués. Le problème, c'est que si j'ai un "e dans l'o", ça m'affiche un graphi sme certes élégant, mais qui n'a rien à voir avec un e ni un o et enc ore moins l'un dans l'autre.
En sélectionnant le français dans la propriété Language du form ulaire je ne m'attends guère à ce que ça résolve la question, mais à to utes fins utiles je précise que j'ai essayé quand même.
Ah, d'ailleurs curieusement, au niveau du formulaire je n'ai pas su trouver Culture et UICulture, Dieu sait pourtant que j'ai déjà joué avec ça.
Il me semblait bien que le choix d'un jeu de caractères doit pouvoir se faire en fonction de la culture, de la langue à afficher, or dans les valeurs de l'énumération Encoding, la seule chose qui puisse un peu évoquer une culture c'est BigEndian et encore en n'étant pas allé voir de trop près ce que ça veut dire.
Est-ce qu'il y a un autre boulon à serrer, ailleurs ? Comme ça avant d'avoir vraiment creusé j'ai l'impression d'avoir fa it ce qu'il faut au niveau de l'ouverture de fichier, on sait sur combien de bits est codé chaque caractère, mais que maintenant il s'agirait qu e le contrôle de RichTextBox puisse afficher ça avec les bons graphismes . J'aurais donc tendance à chercher davantage dans les propriétés d e RichTextBox. Ai-je tort ?
Jérémy Jeanson
Bonjours Gloops,
Le tâtonnement n'est peut pas ce qui se fait de mieux dans le genre, mais on vas dire que ça forge le caractère ;)
Plus sérieusement, UTF8 t'offrira une plus grande souplesse et un encodage de nombreux jeux de caractère. Il permet notamment la compatibilité avec un grand nombre de cultures (dont les culture asiatique par exemple). -- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjours Gloops,
Le tâtonnement n'est peut pas ce qui se fait de mieux dans le genre,
mais on vas dire que ça forge le caractère ;)
Plus sérieusement, UTF8 t'offrira une plus grande souplesse et un
encodage de nombreux jeux de caractère. Il permet notamment la
compatibilité avec un grand nombre de cultures (dont les culture
asiatique par exemple).
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Le tâtonnement n'est peut pas ce qui se fait de mieux dans le genre, mais on vas dire que ça forge le caractère ;)
Plus sérieusement, UTF8 t'offrira une plus grande souplesse et un encodage de nombreux jeux de caractère. Il permet notamment la compatibilité avec un grand nombre de cultures (dont les culture asiatique par exemple). -- Jérémy JEANSON MCP http://www.jjeanson.fr
Gloops
Jérémy Jeanson a écrit, le 02/02/2009 16:27 :
Bonjours Gloops,
Le tâtonnement n'est peut pas ce qui se fait de mieux dans le genre, mais on vas dire que ça forge le caractère ;)
Plus sérieusement, UTF8 t'offrira une plus grande souplesse et un encodage de nombreux jeux de caractère.
Histoire d'en avoir le cur net (tiens, à propos de , j'espère q u'ici il passera proprement), je viens de réessayer UTF8 : ça m'affiche des petits carrés à la place des caractères accentués. Alors, j'ai re mis UTF7.
En définitive, il faut quand même s'aligner sur le choix du programme expéditeur.
> Il permet notamment la
compatibilité avec un grand nombre de cultures (dont les culture asiatique par exemple).
Ah, les petites Asiatiques ;)
Oui si je me rappelle bien c'est le UTF8 qui permet d'assurer le support d'Unicode, en attribuant plus de place de stockage à chaque caractère . Je n'ai pas révisé avant de dire ça, j'espère ne pas dire une bê tise plus grosse que moi.
Jérémy Jeanson a écrit, le 02/02/2009 16:27 :
Bonjours Gloops,
Le tâtonnement n'est peut pas ce qui se fait de mieux dans le genre,
mais on vas dire que ça forge le caractère ;)
Plus sérieusement, UTF8 t'offrira une plus grande souplesse et un
encodage de nombreux jeux de caractère.
Histoire d'en avoir le cur net (tiens, à propos de , j'espère q u'ici
il passera proprement), je viens de réessayer UTF8 : ça m'affiche des
petits carrés à la place des caractères accentués. Alors, j'ai re mis UTF7.
En définitive, il faut quand même s'aligner sur le choix du programme
expéditeur.
> Il permet notamment la
compatibilité avec un grand nombre de cultures (dont les culture
asiatique par exemple).
Ah, les petites Asiatiques ;)
Oui si je me rappelle bien c'est le UTF8 qui permet d'assurer le support
d'Unicode, en attribuant plus de place de stockage à chaque caractère .
Je n'ai pas révisé avant de dire ça, j'espère ne pas dire une bê tise
plus grosse que moi.
Le tâtonnement n'est peut pas ce qui se fait de mieux dans le genre, mais on vas dire que ça forge le caractère ;)
Plus sérieusement, UTF8 t'offrira une plus grande souplesse et un encodage de nombreux jeux de caractère.
Histoire d'en avoir le cur net (tiens, à propos de , j'espère q u'ici il passera proprement), je viens de réessayer UTF8 : ça m'affiche des petits carrés à la place des caractères accentués. Alors, j'ai re mis UTF7.
En définitive, il faut quand même s'aligner sur le choix du programme expéditeur.
> Il permet notamment la
compatibilité avec un grand nombre de cultures (dont les culture asiatique par exemple).
Ah, les petites Asiatiques ;)
Oui si je me rappelle bien c'est le UTF8 qui permet d'assurer le support d'Unicode, en attribuant plus de place de stockage à chaque caractère . Je n'ai pas révisé avant de dire ça, j'espère ne pas dire une bê tise plus grosse que moi.
Jérémy Jeanson
Bonjour Gloops,
As tu penser, tout simplement de faire un encodage de tes String avant de parler d'encodage du fichier? Je n'ai jamais trop fais attention, car en général les String sont fournies par mes applications, mais qui sait, la solution peut être là. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour Gloops,
As tu penser, tout simplement de faire un encodage de tes String avant
de parler d'encodage du fichier? Je n'ai jamais trop fais attention, car
en général les String sont fournies par mes applications, mais qui sait,
la solution peut être là.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
As tu penser, tout simplement de faire un encodage de tes String avant de parler d'encodage du fichier? Je n'ai jamais trop fais attention, car en général les String sont fournies par mes applications, mais qui sait, la solution peut être là. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Gloops
Ou peut-être après, puisqu'il s'agit de lecture ...
J'imagine qu'il faut bien ouvrir le fichier, avant d'y lire une chaîne. Et alors après, la chaîne, je fais quoi dessus ?
_____________________________________________ Jérémy Jeanson a écrit, le 04/02/2009 13:57 :
Bonjour Gloops,
As tu penser, tout simplement de faire un encodage de tes String avant de parler d'encodage du fichier? Je n'ai jamais trop fais attention, ca r en général les String sont fournies par mes applications, mais qui sait, la solution peut être là.
Ou peut-être après, puisqu'il s'agit de lecture ...
J'imagine qu'il faut bien ouvrir le fichier, avant d'y lire une chaîne.
Et alors après, la chaîne, je fais quoi dessus ?
_____________________________________________
Jérémy Jeanson a écrit, le 04/02/2009 13:57 :
Bonjour Gloops,
As tu penser, tout simplement de faire un encodage de tes String avant
de parler d'encodage du fichier? Je n'ai jamais trop fais attention, ca r
en général les String sont fournies par mes applications, mais qui sait,
la solution peut être là.
Ou peut-être après, puisqu'il s'agit de lecture ...
J'imagine qu'il faut bien ouvrir le fichier, avant d'y lire une chaîne. Et alors après, la chaîne, je fais quoi dessus ?
_____________________________________________ Jérémy Jeanson a écrit, le 04/02/2009 13:57 :
Bonjour Gloops,
As tu penser, tout simplement de faire un encodage de tes String avant de parler d'encodage du fichier? Je n'ai jamais trop fais attention, ca r en général les String sont fournies par mes applications, mais qui sait, la solution peut être là.
