j'ai installé un CMS à cette adresse : http://lilo.taonix.net
Le charset du site est encodé en utf-8, mais gecko n'interprète
apparement pas ce codage. J'ai des caractères accentués non
interprétés. Cela me fait dire que cela vient de gecko car avec
Konqueror je n'ai pas ce problème.
J'ai pourtant ajouté cette ligne dans la config de mon serveur apache :
AddCharset UTF-8 .utf8 .php
J'ai résolu le problème en forçant l'encodage dans le virtualhost d'apache : AddDefaultCharset UTF-8
Ce qui n'explique pas pourquoi le : AddCharset UTF-8 .utf8 .php
ne marchait pas ... Il aurait du écraser la valeur mise dans AddDefaultCharset pour ces deux extensions de fichier.
C'est censé être implémenté depuis Apache 1.3
Je me demande si par hazard cela ne marchera *que* pour les fichiers avec double extensions, comme .html.utf8 Je sais que mes tests avec apache ne semblait pas respecter la doc, .utf8.html ne donnant pas la même chose que .html.utf8, alors que la doc précise que c'est censé être traité à l'identique.
Frédéric Logier wrote:
J'ai résolu le problème en forçant l'encodage dans le virtualhost
d'apache :
AddDefaultCharset UTF-8
Ce qui n'explique pas pourquoi le :
AddCharset UTF-8 .utf8 .php
ne marchait pas ... Il aurait du écraser la valeur mise dans
AddDefaultCharset pour ces deux extensions de fichier.
C'est censé être implémenté depuis Apache 1.3
Je me demande si par hazard cela ne marchera *que* pour les fichiers
avec double extensions, comme .html.utf8
Je sais que mes tests avec apache ne semblait pas respecter la doc,
.utf8.html ne donnant pas la même chose que .html.utf8, alors que la doc
précise que c'est censé être traité à l'identique.
J'ai résolu le problème en forçant l'encodage dans le virtualhost d'apache : AddDefaultCharset UTF-8
Ce qui n'explique pas pourquoi le : AddCharset UTF-8 .utf8 .php
ne marchait pas ... Il aurait du écraser la valeur mise dans AddDefaultCharset pour ces deux extensions de fichier.
C'est censé être implémenté depuis Apache 1.3
Je me demande si par hazard cela ne marchera *que* pour les fichiers avec double extensions, comme .html.utf8 Je sais que mes tests avec apache ne semblait pas respecter la doc, .utf8.html ne donnant pas la même chose que .html.utf8, alors que la doc précise que c'est censé être traité à l'identique.
Patrick
>> Puisque c'est une page générée par php, il devrait suffire de rajouter un « header("Content-Type: text/html; charset=utf-8"); » en toute première ligne, non ?
J'ai résolu le problème en forçant l'encodage dans le virtualhost d'apache : AddDefaultCharset UTF-8
Le vrai correctif IMNSHO c'est au niveau de l'application: c'est dingue le nombre d'applications qui ne générent pas correctement un Content-Type avec le charset et qui le mettent plutôt en meta dans le HTML en croyant que cela va fonctionner.
Parce que là, le AddDefaultCharset va dire que tout est de l'UTF8, sauf précision explicite d'une application, et donc ca va coincer de nouveau un jour ou un autre. Et pour vos pages statiques, à moins qu'elles soient en UTF8 aussi, vous allez avoir un souci, je pense.
Cf notamment http://www.cert.org/advisories/CA-2000-02.htm et http://www.w3.org/TR/REC-html40/conform.html
Patrick.
>> Puisque c'est une page générée par php, il devrait suffire de rajouter
un « header("Content-Type: text/html; charset=utf-8"); » en toute
première ligne, non ?
J'ai résolu le problème en forçant l'encodage dans le virtualhost
d'apache :
AddDefaultCharset UTF-8
Le vrai correctif IMNSHO c'est au niveau de l'application: c'est dingue
le nombre d'applications qui ne générent pas correctement un Content-Type
avec le charset et qui le mettent plutôt en meta dans le HTML en croyant
que cela va fonctionner.
Parce que là, le AddDefaultCharset va dire que tout est de l'UTF8, sauf
précision explicite d'une application, et donc ca va coincer de nouveau
un jour ou un autre.
Et pour vos pages statiques, à moins qu'elles soient en UTF8 aussi, vous
allez avoir un souci, je pense.
Cf notamment http://www.cert.org/advisories/CA-2000-02.htm
et http://www.w3.org/TR/REC-html40/conform.html
>> Puisque c'est une page générée par php, il devrait suffire de rajouter un « header("Content-Type: text/html; charset=utf-8"); » en toute première ligne, non ?
J'ai résolu le problème en forçant l'encodage dans le virtualhost d'apache : AddDefaultCharset UTF-8
Le vrai correctif IMNSHO c'est au niveau de l'application: c'est dingue le nombre d'applications qui ne générent pas correctement un Content-Type avec le charset et qui le mettent plutôt en meta dans le HTML en croyant que cela va fonctionner.
Parce que là, le AddDefaultCharset va dire que tout est de l'UTF8, sauf précision explicite d'une application, et donc ca va coincer de nouveau un jour ou un autre. Et pour vos pages statiques, à moins qu'elles soient en UTF8 aussi, vous allez avoir un souci, je pense.
Cf notamment http://www.cert.org/advisories/CA-2000-02.htm et http://www.w3.org/TR/REC-html40/conform.html
Patrick.
Patrick
>>> J'ai résolu le problème en forçant l'encodage dans le virtualhost d'apache : AddDefaultCharset UTF-8
Bonne idée. Merci de nous en avoir fait part, cela pourra servir à d'autres.
Il y a une petite doc explicative ici qui concerne mon CMS mais qui fonctionne pour tout site utilisant l'UTF-8 qui devrait se généraliser :
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette page. C'est à l'application de générer un en-tête HTTP Content-Type avec le charset. Elle essaye bien de le faire en faisant un META alors pourquoi ne le ferait elle pas réellement et proprement ?
Dans de tels problèmes, le coupable n'est pas la configuration Apache pour moi, mais l'application.
Patrick.
>>> J'ai résolu le problème en forçant l'encodage dans le virtualhost
d'apache :
AddDefaultCharset UTF-8
Bonne idée. Merci de nous en avoir fait part, cela pourra servir à
d'autres.
Il y a une petite doc explicative ici qui concerne mon CMS mais qui
fonctionne pour tout site utilisant l'UTF-8 qui devrait se généraliser :
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette
page. C'est à l'application de générer un en-tête HTTP Content-Type avec
le charset. Elle essaye bien de le faire en faisant un META alors
pourquoi ne le ferait elle pas réellement et proprement ?
Dans de tels problèmes, le coupable n'est pas la configuration Apache
pour moi, mais l'application.
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette page. C'est à l'application de générer un en-tête HTTP Content-Type avec le charset. Elle essaye bien de le faire en faisant un META alors pourquoi ne le ferait elle pas réellement et proprement ?
Dans de tels problèmes, le coupable n'est pas la configuration Apache pour moi, mais l'application.
Patrick.
Jean-Marc Desperrier
Patrick wrote:
Le vrai correctif IMNSHO c'est au niveau de l'application: c'est dingue le nombre d'applications qui ne générent pas correctement un Content-Type avec le charset et qui le mettent plutôt en meta dans le HTML en croyant que cela va fonctionner.
C'est certainement plus sûr pour éviter toute dépendance sur la config du serveur.
Parce que là, le AddDefaultCharset va dire que tout est de l'UTF8, sauf précision explicite d'une application, et donc ca va coincer de nouveau un jour ou un autre.
D'où le AddCharset qui est un outils plus efficace.
Et pour vos pages statiques, à moins qu'elles soient en UTF8 aussi, vous allez avoir un souci, je pense.
Mais elle peuvent être alternativement utf-8 ou autre chose, elles-aussi. .htaccess permet dans ce cas de préciser, et même au coup par coup si besoin. A condition d'être autorisé par la config serveur ...
Un truc peut-être d'utiliser .utf.html/.iso8859.html suivant les pages et la négociation pour qu'apache renvoit sur la page quand on accéde simplement à l'url .html, mais gare au client qui n'envoit pas un accept UTF-8, et où la négociation échouera.
Patrick wrote:
Le vrai correctif IMNSHO c'est au niveau de l'application: c'est dingue
le nombre d'applications qui ne générent pas correctement un Content-Type
avec le charset et qui le mettent plutôt en meta dans le HTML en croyant
que cela va fonctionner.
C'est certainement plus sûr pour éviter toute dépendance sur la config
du serveur.
Parce que là, le AddDefaultCharset va dire que tout est de l'UTF8, sauf
précision explicite d'une application, et donc ca va coincer de nouveau
un jour ou un autre.
D'où le AddCharset qui est un outils plus efficace.
Et pour vos pages statiques, à moins qu'elles soient en UTF8 aussi, vous
allez avoir un souci, je pense.
Mais elle peuvent être alternativement utf-8 ou autre chose, elles-aussi.
.htaccess permet dans ce cas de préciser, et même au coup par coup si
besoin. A condition d'être autorisé par la config serveur ...
Un truc peut-être d'utiliser .utf.html/.iso8859.html suivant les pages
et la négociation pour qu'apache renvoit sur la page quand on accéde
simplement à l'url .html, mais gare au client qui n'envoit pas un accept
UTF-8, et où la négociation échouera.
Le vrai correctif IMNSHO c'est au niveau de l'application: c'est dingue le nombre d'applications qui ne générent pas correctement un Content-Type avec le charset et qui le mettent plutôt en meta dans le HTML en croyant que cela va fonctionner.
C'est certainement plus sûr pour éviter toute dépendance sur la config du serveur.
Parce que là, le AddDefaultCharset va dire que tout est de l'UTF8, sauf précision explicite d'une application, et donc ca va coincer de nouveau un jour ou un autre.
D'où le AddCharset qui est un outils plus efficace.
Et pour vos pages statiques, à moins qu'elles soient en UTF8 aussi, vous allez avoir un souci, je pense.
Mais elle peuvent être alternativement utf-8 ou autre chose, elles-aussi. .htaccess permet dans ce cas de préciser, et même au coup par coup si besoin. A condition d'être autorisé par la config serveur ...
Un truc peut-être d'utiliser .utf.html/.iso8859.html suivant les pages et la négociation pour qu'apache renvoit sur la page quand on accéde simplement à l'url .html, mais gare au client qui n'envoit pas un accept UTF-8, et où la négociation échouera.
Frédéric Logier
On Wed, 22 Oct 2003 16:41:29 +0200, Patrick wrote:
J'ai résolu le problème en forçant l'encodage dans le virtualhost d'apache : AddDefaultCharset UTF-8
Bonne idée. Merci de nous en avoir fait part, cela pourra servir à d'autres.
Il y a une petite doc explicative ici qui concerne mon CMS mais qui fonctionne pour tout site utilisant l'UTF-8 qui devrait se généraliser :
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette page. C'est à l'application de générer un en-tête HTTP Content-Type avec le charset. Elle essaye bien de le faire en faisant un META alors pourquoi ne le ferait elle pas réellement et proprement ?
Que manque t-il dans le source du tikiwiki pour le faire proprement ?
On Wed, 22 Oct 2003 16:41:29 +0200, Patrick wrote:
J'ai résolu le problème en forçant l'encodage dans le virtualhost
d'apache :
AddDefaultCharset UTF-8
Bonne idée. Merci de nous en avoir fait part, cela pourra servir à
d'autres.
Il y a une petite doc explicative ici qui concerne mon CMS mais qui
fonctionne pour tout site utilisant l'UTF-8 qui devrait se généraliser :
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette
page. C'est à l'application de générer un en-tête HTTP Content-Type avec
le charset. Elle essaye bien de le faire en faisant un META alors
pourquoi ne le ferait elle pas réellement et proprement ?
Que manque t-il dans le source du tikiwiki pour le faire proprement ?
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette page. C'est à l'application de générer un en-tête HTTP Content-Type avec le charset. Elle essaye bien de le faire en faisant un META alors pourquoi ne le ferait elle pas réellement et proprement ?
Que manque t-il dans le source du tikiwiki pour le faire proprement ?
Patrick
>>> Il y a une petite doc explicative ici qui concerne mon CMS mais qui fonctionne pour tout site utilisant l'UTF-8 qui devrait se généraliser :
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette page. C'est à l'application de générer un en-tête HTTP Content-Type avec le charset. Elle essaye bien de le faire en faisant un META alors pourquoi ne le ferait elle pas réellement et proprement ?
Que manque t-il dans le source du tikiwiki pour le faire proprement ?
Je ne suis pas sûr de comprendre la question, mais ce que devraient faire tous les logiciels de ce type c'est, plutôt que de mettre le charset dans une balise META incluse dans le document HTML, générer l'en-tête HTTP correct, à savoir: Content-Type: text/html; charset=.... plutôt que Content-Type: text/html
Patrick.
>>> Il y a une petite doc explicative ici qui concerne mon CMS mais qui
fonctionne pour tout site utilisant l'UTF-8 qui devrait se généraliser
:
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette
page. C'est à l'application de générer un en-tête HTTP Content-Type
avec le charset. Elle essaye bien de le faire en faisant un META alors
pourquoi ne le ferait elle pas réellement et proprement ?
Que manque t-il dans le source du tikiwiki pour le faire proprement ?
Je ne suis pas sûr de comprendre la question, mais ce que devraient faire
tous les logiciels de ce type c'est, plutôt que de mettre le charset dans
une balise META incluse dans le document HTML, générer l'en-tête HTTP
correct, à savoir:
Content-Type: text/html; charset=....
plutôt que
Content-Type: text/html
Je ne suis pas d'accord avec les conseils qui sont indiqués dans cette page. C'est à l'application de générer un en-tête HTTP Content-Type avec le charset. Elle essaye bien de le faire en faisant un META alors pourquoi ne le ferait elle pas réellement et proprement ?
Que manque t-il dans le source du tikiwiki pour le faire proprement ?
Je ne suis pas sûr de comprendre la question, mais ce que devraient faire tous les logiciels de ce type c'est, plutôt que de mettre le charset dans une balise META incluse dans le document HTML, générer l'en-tête HTTP correct, à savoir: Content-Type: text/html; charset=.... plutôt que Content-Type: text/html
