Jamais compris d'ailleurs pourquoi le <META HTTP-EQUIV=...> n'a pas
priorité sur la config du serveur.
Jamais compris d'ailleurs pourquoi le <META HTTP-EQUIV=...> n'a pas
priorité sur la config du serveur.
Jamais compris d'ailleurs pourquoi le <META HTTP-EQUIV=...> n'a pas
priorité sur la config du serveur.
On 08/07/2011 17:25, Denis Beauregard wrote:Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
On 08/07/2011 17:25, Denis Beauregard wrote:
Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
On 08/07/2011 17:25, Denis Beauregard wrote:Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
Dans le 1er cas, c'est une décision de l'hébergeur
Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
Dans le 1er cas, c'est une décision de l'hébergeur
Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
Dans le 1er cas, c'est une décision de l'hébergeur
Le 08/07/11 18:16, Pierre Goiffon a écrit :On 08/07/2011 17:25, Denis Beauregard wrote:Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
on a écrit dans le charset non indiqué par défaut par le serveur, le
meta serait bien utile dans les cas où :
- on n'a pas la main sur le serveur (pas de htacces, rien)
- on ne devrait pas s'enquiquiner à faire une page php avec headers
(quand du simple html suffit).
M Boreghar, par exemple, a l'habitude de coder en iso-latin (et depuis
le siècle dernier). Jusqu'alors chez son hébergeur il n'y avait pas de
problème, du moins tant que ce dernier n'a décidé recemment de pourvoir
les headers du serveur avec un charset, que bêtement ce charset ne
convient pas à Boreghar qui ne tient pas à retranscrire ses milliers de
fichiers déjà en ligne (d'autant qu'ils ont déjà tous le bon meta !).
Le 08/07/11 18:16, Pierre Goiffon a écrit :
On 08/07/2011 17:25, Denis Beauregard wrote:
Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
on a écrit dans le charset non indiqué par défaut par le serveur, le
meta serait bien utile dans les cas où :
- on n'a pas la main sur le serveur (pas de htacces, rien)
- on ne devrait pas s'enquiquiner à faire une page php avec headers
(quand du simple html suffit).
M Boreghar, par exemple, a l'habitude de coder en iso-latin (et depuis
le siècle dernier). Jusqu'alors chez son hébergeur il n'y avait pas de
problème, du moins tant que ce dernier n'a décidé recemment de pourvoir
les headers du serveur avec un charset, que bêtement ce charset ne
convient pas à Boreghar qui ne tient pas à retranscrire ses milliers de
fichiers déjà en ligne (d'autant qu'ils ont déjà tous le bon meta !).
Le 08/07/11 18:16, Pierre Goiffon a écrit :On 08/07/2011 17:25, Denis Beauregard wrote:Justement, le serveur doit fournir le jeu de caractères utilisé pour
dire quel est le jeu de caractères de la page, donc c'est un jeu
intermédiaire qui n'a pas à être conservé s'il est redéfini.
Si la page est livrée avec l'information de codage en entête http, quel
intérêt pour le navigateur d'aller lire le codage indiqué en meta et de
le rendre prioritaire ? Quels seraient les cas d'utilisations ??!???
on a écrit dans le charset non indiqué par défaut par le serveur, le
meta serait bien utile dans les cas où :
- on n'a pas la main sur le serveur (pas de htacces, rien)
- on ne devrait pas s'enquiquiner à faire une page php avec headers
(quand du simple html suffit).
M Boreghar, par exemple, a l'habitude de coder en iso-latin (et depuis
le siècle dernier). Jusqu'alors chez son hébergeur il n'y avait pas de
problème, du moins tant que ce dernier n'a décidé recemment de pourvoir
les headers du serveur avec un charset, que bêtement ce charset ne
convient pas à Boreghar qui ne tient pas à retranscrire ses milliers de
fichiers déjà en ligne (d'autant qu'ils ont déjà tous le bon meta !).
Le 07/07/11 07:43, Sergio a écrit :
Jamais compris d'ailleurs pourquoi le <META HTTP-EQUIV=...> n'a pas
priorité sur la config du serveur.
Ben ... ce n'est prévu que si la page est lue
- sur un ordi (y sauvegardée puis relue)
- depuis un serveur n'indiquant pas le charset
(pages perso chez Free, chez Orange, ...)
le navigateur parsant le fichier est alors mis au parfum.
Sans doute pour éviter au serveur d'interpréter (parser ?) tous les
fichiers qu'il distribue ?
Le 07/07/11 07:43, Sergio a écrit :
Jamais compris d'ailleurs pourquoi le <META HTTP-EQUIV=...> n'a pas
priorité sur la config du serveur.
Ben ... ce n'est prévu que si la page est lue
- sur un ordi (y sauvegardée puis relue)
- depuis un serveur n'indiquant pas le charset
(pages perso chez Free, chez Orange, ...)
le navigateur parsant le fichier est alors mis au parfum.
Sans doute pour éviter au serveur d'interpréter (parser ?) tous les
fichiers qu'il distribue ?
Le 07/07/11 07:43, Sergio a écrit :
Jamais compris d'ailleurs pourquoi le <META HTTP-EQUIV=...> n'a pas
priorité sur la config du serveur.
Ben ... ce n'est prévu que si la page est lue
- sur un ordi (y sauvegardée puis relue)
- depuis un serveur n'indiquant pas le charset
(pages perso chez Free, chez Orange, ...)
le navigateur parsant le fichier est alors mis au parfum.
Sans doute pour éviter au serveur d'interpréter (parser ?) tous les
fichiers qu'il distribue ?
Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
suivi au forum des auteurs
[quels entêtes HTTP envoyer avec un fichier donné pour préciser
le type MIME, charset compris]Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Ce que je ferai peut-être dans les prochains mois (mon contrat de
4 ans expire bientôt).
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
M'enfin, pourquoi personne ne suggère comme faire un .htaccess
qui résoudrait ce problème ?
J'ai beaucoup de dossiers dans mon
site et j'ai pu corriger le problème pour un sous-ensemble bien
identifié. Mais il y a peut-être d'autres dossiers où je devrais
ajouter un .htaccess pour m'assurer que tout est bien lu (même si
en théorie, tout est édité avec Seamonkey qui transforme les
lettres accentuées en entités).
P.S. Je sais que la solution est donnée sur une page comme
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
mais je suis surpris que personne n'a donné par réflexe cette
solution.
suivi au forum des auteurs
[quels entêtes HTTP envoyer avec un fichier donné pour préciser
le type MIME, charset compris]
Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Ce que je ferai peut-être dans les prochains mois (mon contrat de
4 ans expire bientôt).
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
M'enfin, pourquoi personne ne suggère comme faire un .htaccess
qui résoudrait ce problème ?
J'ai beaucoup de dossiers dans mon
site et j'ai pu corriger le problème pour un sous-ensemble bien
identifié. Mais il y a peut-être d'autres dossiers où je devrais
ajouter un .htaccess pour m'assurer que tout est bien lu (même si
en théorie, tout est édité avec Seamonkey qui transforme les
lettres accentuées en entités).
P.S. Je sais que la solution est donnée sur une page comme
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
mais je suis surpris que personne n'a donné par réflexe cette
solution.
suivi au forum des auteurs
[quels entêtes HTTP envoyer avec un fichier donné pour préciser
le type MIME, charset compris]Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Ce que je ferai peut-être dans les prochains mois (mon contrat de
4 ans expire bientôt).
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
M'enfin, pourquoi personne ne suggère comme faire un .htaccess
qui résoudrait ce problème ?
J'ai beaucoup de dossiers dans mon
site et j'ai pu corriger le problème pour un sous-ensemble bien
identifié. Mais il y a peut-être d'autres dossiers où je devrais
ajouter un .htaccess pour m'assurer que tout est bien lu (même si
en théorie, tout est édité avec Seamonkey qui transforme les
lettres accentuées en entités).
P.S. Je sais que la solution est donnée sur une page comme
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
mais je suis surpris que personne n'a donné par réflexe cette
solution.
Le 11/07/2011 17:35, Denis Beauregard a écrit :suivi au forum des auteurs
Bonne idée.[quels entêtes HTTP envoyer avec un fichier donné pour préciser
le type MIME, charset compris]Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Ce que je ferai peut-être dans les prochains mois (mon contrat de
4 ans expire bientôt).
Par curiosité, quel hébergeur as-tu ? Tous ceux que j'ai utilisés
jusqu'à présent (Free, Teaser et GalacSys) permettaient de modifier
le .htaccess, et il n'y a guère que chez Wanadoo que j'ai entendu
dire que c'était impossible. Or, même dans ce dernier cas, je pense
qu'il y a moyen de dire si on envoie un fichier audio, une image
ou un document HTML -- au fait, comment font ceux qui envoient du
XHTML ?
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
M'enfin, pourquoi personne ne suggère comme faire un .htaccess
qui résoudrait ce problème ?
Je vois plusieurs raisons à cela :
- tu traînes tes guêtres depuis suffisamment longtemps sur les
groupes php et infosystemes.www pour qu'on ait pensé que tu
le savais déjà ;
- la config par .htaccess est plutôt en charte sur fciw.serveurs
ou à la limite fciw.auteurs que fciw.navigateurs ;
- et bien sûr, si tes pages sont en PHP, un header() est une
solution tout aussi simple, voire plus.
J'ai beaucoup de dossiers dans mon
site et j'ai pu corriger le problème pour un sous-ensemble bien
identifié. Mais il y a peut-être d'autres dossiers où je devrais
ajouter un .htaccess pour m'assurer que tout est bien lu (même si
en théorie, tout est édité avec Seamonkey qui transforme les
lettres accentuées en entités).
Pourquoi ne pas mettre le .htaccess à la racine de ton site, si
tu n'as pas de mélange entre UTF-8 et Latin1 ? D'autant plus qu'il
suffit d'un autre .htaccess dans un sous-sous-sous-répertoire qui
contiendrait exceptionnellement des documents avec un autre jeu de
caractères.
P.S. Je sais que la solution est donnée sur une page comme
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
mais je suis surpris que personne n'a donné par réflexe cette
solution.
Cf. supra.
Le 11/07/2011 17:35, Denis Beauregard a écrit :
suivi au forum des auteurs
Bonne idée.
[quels entêtes HTTP envoyer avec un fichier donné pour préciser
le type MIME, charset compris]
Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Ce que je ferai peut-être dans les prochains mois (mon contrat de
4 ans expire bientôt).
Par curiosité, quel hébergeur as-tu ? Tous ceux que j'ai utilisés
jusqu'à présent (Free, Teaser et GalacSys) permettaient de modifier
le .htaccess, et il n'y a guère que chez Wanadoo que j'ai entendu
dire que c'était impossible. Or, même dans ce dernier cas, je pense
qu'il y a moyen de dire si on envoie un fichier audio, une image
ou un document HTML -- au fait, comment font ceux qui envoient du
XHTML ?
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
M'enfin, pourquoi personne ne suggère comme faire un .htaccess
qui résoudrait ce problème ?
Je vois plusieurs raisons à cela :
- tu traînes tes guêtres depuis suffisamment longtemps sur les
groupes php et infosystemes.www pour qu'on ait pensé que tu
le savais déjà ;
- la config par .htaccess est plutôt en charte sur fciw.serveurs
ou à la limite fciw.auteurs que fciw.navigateurs ;
- et bien sûr, si tes pages sont en PHP, un header() est une
solution tout aussi simple, voire plus.
J'ai beaucoup de dossiers dans mon
site et j'ai pu corriger le problème pour un sous-ensemble bien
identifié. Mais il y a peut-être d'autres dossiers où je devrais
ajouter un .htaccess pour m'assurer que tout est bien lu (même si
en théorie, tout est édité avec Seamonkey qui transforme les
lettres accentuées en entités).
Pourquoi ne pas mettre le .htaccess à la racine de ton site, si
tu n'as pas de mélange entre UTF-8 et Latin1 ? D'autant plus qu'il
suffit d'un autre .htaccess dans un sous-sous-sous-répertoire qui
contiendrait exceptionnellement des documents avec un autre jeu de
caractères.
P.S. Je sais que la solution est donnée sur une page comme
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
mais je suis surpris que personne n'a donné par réflexe cette
solution.
Cf. supra.
Le 11/07/2011 17:35, Denis Beauregard a écrit :suivi au forum des auteurs
Bonne idée.[quels entêtes HTTP envoyer avec un fichier donné pour préciser
le type MIME, charset compris]Dans le 1er cas, c'est une décision de l'hébergeur
Mauvais hébergeur, changer d'hébergeur. ©
Ce que je ferai peut-être dans les prochains mois (mon contrat de
4 ans expire bientôt).
Par curiosité, quel hébergeur as-tu ? Tous ceux que j'ai utilisés
jusqu'à présent (Free, Teaser et GalacSys) permettaient de modifier
le .htaccess, et il n'y a guère que chez Wanadoo que j'ai entendu
dire que c'était impossible. Or, même dans ce dernier cas, je pense
qu'il y a moyen de dire si on envoie un fichier audio, une image
ou un document HTML -- au fait, comment font ceux qui envoient du
XHTML ?
Si ton hébergeur ne met pas à ta disposition un moyen de choisir
les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
mauvais hébergeur et tu devrais en changer le plus tôt possible.
D'autant plus qu'avec Apache, même si tu n'as pas accès au
httpd.conf, il est très facile de contrôler ce que tu veux
au moyens des .htaccess répertoire par répertoire.
M'enfin, pourquoi personne ne suggère comme faire un .htaccess
qui résoudrait ce problème ?
Je vois plusieurs raisons à cela :
- tu traînes tes guêtres depuis suffisamment longtemps sur les
groupes php et infosystemes.www pour qu'on ait pensé que tu
le savais déjà ;
- la config par .htaccess est plutôt en charte sur fciw.serveurs
ou à la limite fciw.auteurs que fciw.navigateurs ;
- et bien sûr, si tes pages sont en PHP, un header() est une
solution tout aussi simple, voire plus.
J'ai beaucoup de dossiers dans mon
site et j'ai pu corriger le problème pour un sous-ensemble bien
identifié. Mais il y a peut-être d'autres dossiers où je devrais
ajouter un .htaccess pour m'assurer que tout est bien lu (même si
en théorie, tout est édité avec Seamonkey qui transforme les
lettres accentuées en entités).
Pourquoi ne pas mettre le .htaccess à la racine de ton site, si
tu n'as pas de mélange entre UTF-8 et Latin1 ? D'autant plus qu'il
suffit d'un autre .htaccess dans un sous-sous-sous-répertoire qui
contiendrait exceptionnellement des documents avec un autre jeu de
caractères.
P.S. Je sais que la solution est donnée sur une page comme
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
mais je suis surpris que personne n'a donné par réflexe cette
solution.
Cf. supra.
le fichier inclus dans
tous ces fichiers appelle l'anti-aspirateur de site
le fichier inclus dans
tous ces fichiers appelle l'anti-aspirateur de site
le fichier inclus dans
tous ces fichiers appelle l'anti-aspirateur de site
je ne sais pas trop ce qu'est un anti-aspirateur de site
cependant ... ne vaudrait-il pas mieux l'avoir dans le .htaccess ?
ne surchargeant dont pas ni les pages ni les accès serveur
te libérant de ce soucis lors de la rédaction de nouvelles pages
<http://www.tutoriaux-excalibur.com/anti-aspirateur.htm>
je ne sais pas trop ce qu'est un anti-aspirateur de site
cependant ... ne vaudrait-il pas mieux l'avoir dans le .htaccess ?
ne surchargeant dont pas ni les pages ni les accès serveur
te libérant de ce soucis lors de la rédaction de nouvelles pages
<http://www.tutoriaux-excalibur.com/anti-aspirateur.htm>
je ne sais pas trop ce qu'est un anti-aspirateur de site
cependant ... ne vaudrait-il pas mieux l'avoir dans le .htaccess ?
ne surchargeant dont pas ni les pages ni les accès serveur
te libérant de ce soucis lors de la rédaction de nouvelles pages
<http://www.tutoriaux-excalibur.com/anti-aspirateur.htm>