Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement ASP.Net Lecture et affichage d'un fichier texte

Lecture et affichage d'un fichier texte

5 réponses
Avatar
Guillaume JAY
Dans le code-behind :
Je remplis une variable avec un streamreader
Dim str as streamreader("toto.Txt")
t=str.readtoend

puis, dans mon html, j'ai mis
un
<%=t%>
Tout fonctionne..... SAUF que les accents disparaissent dés le
remplissage de T.

Je peux faire quoi ?
(le serveur est en IIS6, windows server 2003 VF)

Guillaume
Signaler un problème avec ce contenu

5 réponses

Supprimer
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
Avatar
Paul Bacelar
"Guillaume JAY" wrote in message
news:
Dans le code-behind :
Je remplis une variable avec un streamreader
Dim str as streamreader("toto.Txt")
t=str.readtoend

puis, dans mon html, j'ai mis
un
<%=t%>
Tout fonctionne..... SAUF que les accents disparaissent dés le
remplissage de T.

Je peux faire quoi ?
(le serveur est en IIS6, windows server 2003 VF)

Guillaume



Erreur1

Vous chargez votre fichier texte dans une chaîne sans vous souciez du type
d'encodage que votre fichier utilise.

Voir le paramètre d'encodage de "StreamReader"



Erreur2

Vous copiez votre string dans du HTML sans la convertir dans un encodage
compatible avec le char-set spécifié dans l'en-tête de la page HTML.

Voir le paramètre d'encodage de "String.ToString()"





En résumé, vous ne perdez que les accents et c'est déjà bien beau que vous
gardiez le reste.


--
Paul Bacelar
Avatar
Guillaume JAY
On Thu, 3 Mar 2005 01:51:25 +0100, "Paul Bacelar"
wrote:
Je peux faire quoi ?
(le serveur est en IIS6, windows server 2003 VF)
Guillaume


Erreur1
Vous chargez votre fichier texte dans une chaîne sans vous souciez du type
d'encodage que votre fichier utilise.
Voir le paramètre d'encodage de "StreamReader"



Eh bien, j'ai essayé ASCII, UTF8, et Unicode, et rien n'a marché.

La, je viens d'utiliser le filesystemobject/textstream, et ca marche
trés bien (juste eu à remplacer les vbcrlf par des <BR>)

Mais bon, je me doute bien que streamreader, c'est mieux, mais je
n'arrive pas à le faire marcher.

Vous copiez votre string dans du HTML sans la convertir dans un encodage
compatible avec le char-set spécifié dans l'en-tête de la page HTML.
Voir le paramètre d'encodage de "String.ToString()"



Quand a ça, j'ai aucun probléme d'affichage, sans donc utiliser
string.tostring (d'ailleurs, je ne trouve pas d'encodage dans mon
entete de page). Est ce que ca peut poser un souci avec des
navigateurs "non-francophones" ?

Guillaume
Avatar
Paul Bacelar
"Guillaume JAY" wrote in message
news:
On Thu, 3 Mar 2005 01:51:25 +0100, "Paul Bacelar"
wrote:
>> Je peux faire quoi ?
>> (le serveur est en IIS6, windows server 2003 VF)
>> Guillaume
>Erreur1
>Vous chargez votre fichier texte dans une chaîne sans vous souciez du


type
>d'encodage que votre fichier utilise.
>Voir le paramètre d'encodage de "StreamReader"

Eh bien, j'ai essayé ASCII, UTF8, et Unicode, et rien n'a marché.

La, je viens d'utiliser le filesystemobject/textstream, et ca marche
trés bien (juste eu à remplacer les vbcrlf par des <BR>)

Mais bon, je me doute bien que streamreader, c'est mieux, mais je
n'arrive pas à le faire marcher.

>Vous copiez votre string dans du HTML sans la convertir dans un encodage
>compatible avec le char-set spécifié dans l'en-tête de la page HTML.
>Voir le paramètre d'encodage de "String.ToString()"

Quand a ça, j'ai aucun probléme d'affichage, sans donc utiliser
string.tostring (d'ailleurs, je ne trouve pas d'encodage dans mon
entete de page). Est ce que ca peut poser un souci avec des
navigateurs "non-francophones" ?

Guillaume



Le fait que cela marche avec votre machine de test ne veut pas dire que
votre application Web fonctionnera correctement sur la majorité des
configurations.

Essayez de maîtriser vos sorties et pas de pousser vers la reponse HTTP des
chaînes de caractères n'importe comment.

Pour le <BR>, c'est juste l'escaping d'une chaîne vers du HTML, comme les
accents et d'autres qui doivent être converties au format HTML.


--
Paul Bacelar
Avatar
Guillaume JAY
On Fri, 4 Mar 2005 01:57:10 +0100, "Paul Bacelar"
wrote:

"Guillaume JAY" wrote in message
news:
Essayez de maîtriser vos sorties et pas de pousser vers la reponse HTTP des
chaînes de caractères n'importe comment.



C'est bien mon intention, c'est pour ca que j'ai posé ma
question sur l'usage de streamreader. Tout ce que j'ai essayé avec SR
n'a pas reussi a charger mon fichier correctement.

Pour le <BR>, c'est juste l'escaping d'une chaîne vers du HTML, comme les
accents et d'autres qui doivent être converties au format HTML.



Oui, je le sais bien, je ne l'ai pas fait au hasard.

Guillaume
Avatar
Simon Mourier [MS]
Il y a deux choses à ne pas confondre:

1) l'encoding réel, c'est à dire le format binaire des données,
correspondant à un ensemble de caractères. Ca définit une correspondance
entre des octets et des caractères humains
2) la déclaration de l'encoding, utilisée par les X applications à travers
les données passent. Elle peut-être explicite ou implicite, en fonction de
plein de paramètres

les problèmes arrivent quand 1) et 2) ne sont pas cohérents. Moins
lsdéclarations sont explicites, et plus on a de problèmes en général.

Quelques encoding classiques (je simplifie):

* ASCII: 1 caractère = 1 octet (0-127), quasiment inutilisable, fait pour
les américains
* ANSI: ASCII + codepage: 1 caractère = 1 octet. La correspondance au dessus
de 127 (le codepage) est fonction de "l'environnement" (= fonction des
regionals settings de l'application sous Windows). Moi j'ai un codepage
Windows-1252 (surensemble de ISO latin = iso-8859-1) donc je comprends
l'octet 0xE9 comme le caractère 'é', mais si j'installe
* UNICODE: 1 caractère = X octets avec X >=2. La correspondance est
universelle, établie par le comité UNICODE (www.unicode.org). Donc les mêmes
octets représentent les mêmes caractères partout dans le monde
* UTF-8: 1 caractère = X octets avec X >=1. Fonctionnellement identique à
UNICODE mais moins bavard. C'est globalement le meilleur encoding à utiliser
à mon avis, qu'on fasse de l'international ou pas.

Pour déclarer l'encoding, on a quelques méthodes:
1) le byte order mark (BOM): quelques octets (2, 3) au début du flux
(quelque soit le flux) qui indiquent qu'on est en ANSI, en UTF-8, ou en
UNICODE
2) en HTTP: le header "content-type" (visible avec un analyseur réseau)
3) en HTML le <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
CHARSET=utf-8">. Avant que ce META n'existe, on pouvait utilise l'encoding
HTML qui n'a rien à voir avec le reste (celui qui dit que 'é'=&eacute;). Lui
fonctionne avec ASCII ce qui peut être pratique, mais aujourd'hui, inutile.
4) en XML le <?xml version="1.0" encoding="utf-8"?>
etc...

Et quand rien n'est déclaré, c'est à l'application utilisatrice, fonction
des RFCs, des défauts, de l'application, de l'OS, ou de l'age du capitaine,
de déterminer l'encoding.
Maintenant, toute les applications ne supportent pas non plus toutes les
déclarations. Par exemple, Visual Studio 6.0 ne supportait pas le BOM, et si
on ouvrait un fichier avec un BOM, on pouvait voir 2 ou 3 caractères
bizarres. NOTEPAD depuis Windows 2000 (je crois) supporte le BOM, y compris
en écriture (save as...).
Internet Explorer pour déterminer l'encoding d'une page va utiliser 1, 2, et
3, 3 (le HTML) étant prioritaire. Netscape 4 avait des soucis si 2 et 3
n'étaient pas cohérents (il transformait tout en petits carrés), ...

Donc, le problème général n'est pas simple.

Dans votre cas, vous avez plusieurs éléments:
1) l'encoding de votre fichier. Quel est-t-il? A-t-il un BOM? Si il contient
du HTML, contient-t-il un META charset?, etc... Si vous lisiez d'une base de
données, ce serait la même question
2) le streamreader qui lit le fichier. le streamReader peut détecter le BOM.
Mais si vous n'en avez pas, ou si le streamreader n'est pas bien utilisé,
alors il va prendre des défauts de type ANSI. Par exemple, si votre fichier
est enUTF-8 sans BOM => problème
3) l'encoding du fichier .ASCX ou .ASPX. Il peut déterminer la façon dont le
flux sera renvoyé au client
4) l'encoding de réponse déclaré dans l'entête de la directive page : <%@
Page ResponseEncoding="utf-8" %> par exemple. Ceci va conditionner 2). Est
il cohérent avec tout le reste?
5) l'encoding de réponse déclaré par défaut dans le web.config si la
directive n'est pas spécifiée dans la page.
<configuration>
<system.web>
<globalization
fileEncoding="utf-8" // correspond à l'encoding des fichiers ASCX
ASPX
requestEncoding="utf-8" // correspond au POSTs des browsers
clients
responseEncoding="utf-8" // correspond à l'encoding dans les
header HTTP
/>
</system.web>
</configuration>6) avez vous dans le flux global renvoyé un META charset?
est-il cohérent avec tout le reste?

Mon conseil est le suivant: quand on fait du .NET, le plus pratique c'est de
tout mettre en UTF-8 avec BOM. Il y a quelques années c'était plus risqué
car toutes les applications ne le supportaient pas, mais aujourd'hui, ca ne
pose normalement plus de problèmes.

Simon.

"Guillaume JAY" a écrit dans le message de
news:
On Thu, 3 Mar 2005 01:51:25 +0100, "Paul Bacelar"
wrote:
Je peux faire quoi ?
(le serveur est en IIS6, windows server 2003 VF)
Guillaume


Erreur1
Vous chargez votre fichier texte dans une chaîne sans vous souciez du type
d'encodage que votre fichier utilise.
Voir le paramètre d'encodage de "StreamReader"



Eh bien, j'ai essayé ASCII, UTF8, et Unicode, et rien n'a marché.

La, je viens d'utiliser le filesystemobject/textstream, et ca marche
trés bien (juste eu à remplacer les vbcrlf par des <BR>)

Mais bon, je me doute bien que streamreader, c'est mieux, mais je
n'arrive pas à le faire marcher.

Vous copiez votre string dans du HTML sans la convertir dans un encodage
compatible avec le char-set spécifié dans l'en-tête de la page HTML.
Voir le paramètre d'encodage de "String.ToString()"



Quand a ça, j'ai aucun probléme d'affichage, sans donc utiliser
string.tostring (d'ailleurs, je ne trouve pas d'encodage dans mon
entete de page). Est ce que ca peut poser un souci avec des
navigateurs "non-francophones" ?

Guillaume