Hello Bernard, Le 19/08/2016 à 16:34, Bernard Schoenacker a écrit :
bonjour, j'ai crié trop vite hourra ... ;( voici l'exemple qui pose problème (un simple texte) : http://happy-tux.org/marco/README slt bernard
J'ai fait quelques tests et je pense que c'est plutôt côté serveur qu'il faut intervenir. Je pense que le navigateur se doit d'être passif :) . En utilisant l'URL que tu as précisé, je me suis rendu compte que la réponse du serveur HTTP ne précisait pas de "Content-Type", donc pas de Charset (habituellement, l'un ne va pas sans l'autre :) ) dans la réponse. De fait, cela laisse libre court au navigateur d’interpréter le contenu de la page servie; Certains le font peut-être correctement, d'autres moins. (en l’occurrence avec Firefox 48.0 ou Chromium 37.0, j'ai le même résultat : l'affichage des caractères spéciaux est en échec). Je me suis donc adonné à quelques tests avec un serveur Debian Jessie que j'avais sous la main, délivrant du contenu HTTP avec un Apache. Le même comportement a été observé si on nomme le fichier seulement "README" et dont le contenu est en UTF-8 (pas de "Content-Type" renvoyé). S'il est nommé "README.txt", cela change un peu, car dans ce cas , le "Content-Type: text/plain" est renvoyé au navigateur. *Solution de contournement* , si bien sûr tu as la main sur le serveur concerné; Ça "juste marche" de mon côté : même si personnellement je trouve ça un peu crado, mais faute de mieux ... : # a2enmod headers puis dans un .htaccess dans le dossier concerné :
<Files "README"> Header set Content-Type "text/plain; charset=utf-8" </Files>
Une autre solution passe peut-être par l'ajout de la directive "AddDefaultCharset UTF-8" (fonctionne également dans un .htaccess si le fichier que l'on souhaite consulter est nommé "README.txt") mais j'ai un doute si le fichier est seulement nommé "README" (car Apache ne renvoie pas de "Content-Type" et donc pas de "charset" dans ce cas). Bien penser à recharger la page en vidant le cache associé (CTRL+Shift+R dans le cas Firefox), pour voir si cela a bien eu l'effet escompté. Accessoirement si "Internal Server Error" s'affiche, c'est probablement qu'il manque un module apache, auquel cas, les logs "error" devraient t'en dire plus. En espérant que cela aide :). @+ Christophe.
Hello Bernard,
Le 19/08/2016 à 16:34, Bernard Schoenacker a écrit :
bonjour,
j'ai crié trop vite hourra ... ;(
voici l'exemple qui pose problème (un simple texte) :
http://happy-tux.org/marco/README
slt
bernard
J'ai fait quelques tests et je pense que c'est plutôt côté serveur qu'il
faut intervenir.
Je pense que le navigateur se doit d'être passif :) .
En utilisant l'URL que tu as précisé, je me suis rendu compte que la
réponse du serveur HTTP ne précisait pas de "Content-Type", donc pas de
Charset (habituellement, l'un ne va pas sans l'autre :) ) dans la réponse.
De fait, cela laisse libre court au navigateur d’interpréter le contenu
de la page servie; Certains le font peut-être correctement, d'autres
moins. (en l’occurrence avec Firefox 48.0 ou Chromium 37.0, j'ai le même
résultat : l'affichage des caractères spéciaux est en échec).
Je me suis donc adonné à quelques tests avec un serveur Debian Jessie
que j'avais sous la main, délivrant du contenu HTTP avec un Apache.
Le même comportement a été observé si on nomme le fichier seulement
"README" et dont le contenu est en UTF-8 (pas de "Content-Type" renvoyé).
S'il est nommé "README.txt", cela change un peu, car dans ce cas , le
"Content-Type: text/plain" est renvoyé au navigateur.
*Solution de contournement* , si bien sûr tu as la main sur le serveur
concerné; Ça "juste marche" de mon côté : même si personnellement je
trouve ça un peu crado, mais faute de mieux ... :
# a2enmod headers
puis dans un .htaccess dans le dossier concerné :
<Files "README">
Header set Content-Type "text/plain; charset=utf-8"
</Files>
Une autre solution passe peut-être par l'ajout de la directive
"AddDefaultCharset UTF-8" (fonctionne également dans un .htaccess si le
fichier que l'on souhaite consulter est nommé "README.txt") mais j'ai un
doute si le fichier est seulement nommé "README" (car Apache ne renvoie
pas de "Content-Type" et donc pas de "charset" dans ce cas).
Bien penser à recharger la page en vidant le cache associé (CTRL+Shift+R
dans le cas Firefox), pour voir si cela a bien eu l'effet escompté.
Accessoirement si "Internal Server Error" s'affiche, c'est probablement
qu'il manque un module apache, auquel cas, les logs "error" devraient
t'en dire plus.
Hello Bernard, Le 19/08/2016 à 16:34, Bernard Schoenacker a écrit :
bonjour, j'ai crié trop vite hourra ... ;( voici l'exemple qui pose problème (un simple texte) : http://happy-tux.org/marco/README slt bernard
J'ai fait quelques tests et je pense que c'est plutôt côté serveur qu'il faut intervenir. Je pense que le navigateur se doit d'être passif :) . En utilisant l'URL que tu as précisé, je me suis rendu compte que la réponse du serveur HTTP ne précisait pas de "Content-Type", donc pas de Charset (habituellement, l'un ne va pas sans l'autre :) ) dans la réponse. De fait, cela laisse libre court au navigateur d’interpréter le contenu de la page servie; Certains le font peut-être correctement, d'autres moins. (en l’occurrence avec Firefox 48.0 ou Chromium 37.0, j'ai le même résultat : l'affichage des caractères spéciaux est en échec). Je me suis donc adonné à quelques tests avec un serveur Debian Jessie que j'avais sous la main, délivrant du contenu HTTP avec un Apache. Le même comportement a été observé si on nomme le fichier seulement "README" et dont le contenu est en UTF-8 (pas de "Content-Type" renvoyé). S'il est nommé "README.txt", cela change un peu, car dans ce cas , le "Content-Type: text/plain" est renvoyé au navigateur. *Solution de contournement* , si bien sûr tu as la main sur le serveur concerné; Ça "juste marche" de mon côté : même si personnellement je trouve ça un peu crado, mais faute de mieux ... : # a2enmod headers puis dans un .htaccess dans le dossier concerné :
<Files "README"> Header set Content-Type "text/plain; charset=utf-8" </Files>
Une autre solution passe peut-être par l'ajout de la directive "AddDefaultCharset UTF-8" (fonctionne également dans un .htaccess si le fichier que l'on souhaite consulter est nommé "README.txt") mais j'ai un doute si le fichier est seulement nommé "README" (car Apache ne renvoie pas de "Content-Type" et donc pas de "charset" dans ce cas). Bien penser à recharger la page en vidant le cache associé (CTRL+Shift+R dans le cas Firefox), pour voir si cela a bien eu l'effet escompté. Accessoirement si "Internal Server Error" s'affiche, c'est probablement qu'il manque un module apache, auquel cas, les logs "error" devraient t'en dire plus. En espérant que cela aide :). @+ Christophe.
Bernard Schoenacker
Le Tue, 23 Aug 2016 19:43:35 +0200, Christophe a écrit :
Hello Bernard, Le 19/08/2016 à 16:34, Bernard Schoenacker a écrit :
bonjour, j'ai crié trop vite hourra ... ;( voici l'exemple qui pose problème (un simple texte) : http://happy-tux.org/marco/README slt bernard
J'ai fait quelques tests et je pense que c'est plutôt côté serveur qu'il faut intervenir. Je pense que le navigateur se doit d'être passif :) . En utilisant l'URL que tu as précisé, je me suis rendu compte que la réponse du serveur HTTP ne précisait pas de "Content-Type", donc pas de Charset (habituellement, l'un ne va pas sans l'autre :) ) dans la réponse. De fait, cela laisse libre court au navigateur d’interpréter le contenu de la page servie; Certains le font peut-être correctement, d'autres moins. (en l’occurrence avec Firefox 48.0 ou Chromium 37.0, j'ai le même résultat : l'affichage des caractères spéciaux est en échec). Je me suis donc adonné à quelques tests avec un serveur Debian Jessie que j'avais sous la main, délivrant du contenu HTTP avec un Apache. Le même comportement a été observé si on nomme le fichier seulement "README" et dont le contenu est en UTF-8 (pas de "Content-Type" renvoyé). S'il est nommé "README.txt", cela change un peu, car dans ce cas , le "Content-Type: text/plain" est renvoyé au navigateur. *Solution de contournement* , si bien sûr tu as la main sur le serveur concerné; Ça "juste marche" de mon côté : même si personnellement je trouve ça un peu crado, mais faute de mieux ... : # a2enmod headers puis dans un .htaccess dans le dossier concerné :
<Files "README"> Header set Content-Type "text/plain; charset=utf-8" </Files>
Une autre solution passe peut-être par l'ajout de la directive "AddDefaultCharset UTF-8" (fonctionne également dans un .htaccess si le fichier que l'on souhaite consulter est nommé "README.txt") mais j'ai un doute si le fichier est seulement nommé "README" (car Apache ne renvoie pas de "Content-Type" et donc pas de "charset" dans ce cas). Bien penser à recharger la page en vidant le cache associé (CTRL+Shift+R dans le cas Firefox), pour voir si cela a bien eu l'effet escompté. Accessoirement si "Internal Server Error" s'affiche, c'est probablement qu'il manque un module apache, auquel cas, les logs "error" devraient t'en dire plus. En espérant que cela aide :). @+ Christophe.
bonjour, j'ai essayé en vain slt bernard
Le Tue, 23 Aug 2016 19:43:35 +0200,
Christophe <tech@stuxnet.org> a écrit :
Hello Bernard,
Le 19/08/2016 à 16:34, Bernard Schoenacker a écrit :
> bonjour,
>
> j'ai crié trop vite hourra ... ;(
>
> voici l'exemple qui pose problème (un simple texte) :
>
> http://happy-tux.org/marco/README
>
> slt
> bernard
J'ai fait quelques tests et je pense que c'est plutôt côté serveur
qu'il faut intervenir.
Je pense que le navigateur se doit d'être passif :) .
En utilisant l'URL que tu as précisé, je me suis rendu compte que la
réponse du serveur HTTP ne précisait pas de "Content-Type", donc pas
de Charset (habituellement, l'un ne va pas sans l'autre :) ) dans la
réponse. De fait, cela laisse libre court au navigateur d’interpréter
le contenu de la page servie; Certains le font peut-être
correctement, d'autres moins. (en l’occurrence avec Firefox 48.0 ou
Chromium 37.0, j'ai le même résultat : l'affichage des caractères
spéciaux est en échec).
Je me suis donc adonné à quelques tests avec un serveur Debian Jessie
que j'avais sous la main, délivrant du contenu HTTP avec un Apache.
Le même comportement a été observé si on nomme le fichier seulement
"README" et dont le contenu est en UTF-8 (pas de "Content-Type"
renvoyé). S'il est nommé "README.txt", cela change un peu, car dans
ce cas , le "Content-Type: text/plain" est renvoyé au navigateur.
*Solution de contournement* , si bien sûr tu as la main sur le
serveur concerné; Ça "juste marche" de mon côté : même si
personnellement je trouve ça un peu crado, mais faute de mieux ... :
Une autre solution passe peut-être par l'ajout de la directive
"AddDefaultCharset UTF-8" (fonctionne également dans un .htaccess si
le fichier que l'on souhaite consulter est nommé "README.txt") mais
j'ai un doute si le fichier est seulement nommé "README" (car Apache
ne renvoie pas de "Content-Type" et donc pas de "charset" dans ce
cas).
Bien penser à recharger la page en vidant le cache associé
(CTRL+Shift+R dans le cas Firefox), pour voir si cela a bien eu
l'effet escompté.
Accessoirement si "Internal Server Error" s'affiche, c'est
probablement qu'il manque un module apache, auquel cas, les logs
"error" devraient t'en dire plus.
Le Tue, 23 Aug 2016 19:43:35 +0200, Christophe a écrit :
Hello Bernard, Le 19/08/2016 à 16:34, Bernard Schoenacker a écrit :
bonjour, j'ai crié trop vite hourra ... ;( voici l'exemple qui pose problème (un simple texte) : http://happy-tux.org/marco/README slt bernard
J'ai fait quelques tests et je pense que c'est plutôt côté serveur qu'il faut intervenir. Je pense que le navigateur se doit d'être passif :) . En utilisant l'URL que tu as précisé, je me suis rendu compte que la réponse du serveur HTTP ne précisait pas de "Content-Type", donc pas de Charset (habituellement, l'un ne va pas sans l'autre :) ) dans la réponse. De fait, cela laisse libre court au navigateur d’interpréter le contenu de la page servie; Certains le font peut-être correctement, d'autres moins. (en l’occurrence avec Firefox 48.0 ou Chromium 37.0, j'ai le même résultat : l'affichage des caractères spéciaux est en échec). Je me suis donc adonné à quelques tests avec un serveur Debian Jessie que j'avais sous la main, délivrant du contenu HTTP avec un Apache. Le même comportement a été observé si on nomme le fichier seulement "README" et dont le contenu est en UTF-8 (pas de "Content-Type" renvoyé). S'il est nommé "README.txt", cela change un peu, car dans ce cas , le "Content-Type: text/plain" est renvoyé au navigateur. *Solution de contournement* , si bien sûr tu as la main sur le serveur concerné; Ça "juste marche" de mon côté : même si personnellement je trouve ça un peu crado, mais faute de mieux ... : # a2enmod headers puis dans un .htaccess dans le dossier concerné :
<Files "README"> Header set Content-Type "text/plain; charset=utf-8" </Files>
Une autre solution passe peut-être par l'ajout de la directive "AddDefaultCharset UTF-8" (fonctionne également dans un .htaccess si le fichier que l'on souhaite consulter est nommé "README.txt") mais j'ai un doute si le fichier est seulement nommé "README" (car Apache ne renvoie pas de "Content-Type" et donc pas de "charset" dans ce cas). Bien penser à recharger la page en vidant le cache associé (CTRL+Shift+R dans le cas Firefox), pour voir si cela a bien eu l'effet escompté. Accessoirement si "Internal Server Error" s'affiche, c'est probablement qu'il manque un module apache, auquel cas, les logs "error" devraient t'en dire plus. En espérant que cela aide :). @+ Christophe.
