Choix du jeu de caractères

Le
Gloops
Bonjour tout le monde,

Tiens, j'aurais cru que sur une question pareille tout avait été dit =

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 graphism=
e
certes élégant, mais qui n'a rien à voir avec un e ni un o et encor=
e
moins l'un dans l'autre.

En sélectionnant le français dans la propriété Language du formul=
aire je
ne m'attends guère à ce que ça résolve la question, mais à tout=
es 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é v=
oir
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 fait=
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 que =
le
contrôle de RichTextBox puisse afficher ça avec les bons graphismes. =

J'aurais donc tendance à chercher davantage dans les propriétés de =

RichTextBox. Ai-je tort ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gloops
Le #18559401
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
Le #18559891
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
Gloops
Le #18578071
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 cœur 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
Le #18578661
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
Gloops
Le #18593801
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à.


Publicité
Poster une réponse
Anonyme