Jump to content
Sign in to follow this  
Denis

Configurations serveurs par défaut

Rate this topic

Recommended Posts

Salut troupes

Une petite question qui me turlupine suite à une mésaventure avec le site d'une cliente qui n'acceptait pas certains caractères en iso-8859-1 et qui les acceptait facilement lorsqu'on passait en windows-1252.

Nous travaillions il y a quelques semaines à l'assainissement du code de son site (un site gouvernemental québécois) et nous avions réduit le nombre d'erreurs dans les pages à un nombre minime concernant uniquement des caractères qui n'étaient pas reconnus comme des caractères SGML : des apostrophes non-reconnues, des guillemets, ce genre de trucs. Normalement, ce type d'erreurs survient lorsque les caractères sont importés de Word. Les reprendre dans un éditeur HTML règle habituellement le problème.

Cependant, cette fois-ci, nous avions beau corriger et corriger, les erreurs refusaient obstinément de partir. Ce n'est qu'en forçant un charset windows-1252 à travers le validateur que nous parvenions à obtenir un code valide XHTML 1.0 transitionnel. Faute de comprendre pourquoi, la cliente a passé tout son site sous ce charset au lieu de l'iso-8859-1 que nous avions mis en place au départ et le problème fut réglé. Enfin, je dis pour le moment, parce que je dois vous avouer que depuis, cette petite histoire m'énerve au plus haut point et j'aimerais bien connaître le fin mot de l'histoire :!::wacko:

Ma théorie, c'est que malgré le fait que nous appelions du iso-8859-1 pour les pages, le serveur lui (un serveur microsoft), serait peut-être configuré pour servir du windows-1252 ce qui, considérant les penchants propriétaires du géant de Redmond, ne surprendrait personne... Vous avez une idée du comment et du pourquoi ? Et si ma théorie s'avère fondée, comment peut-on modifier la config du serveur pour lui faire passer de l'iso-8859-1 par défaut ? :huh:

Share this post


Link to post
Share on other sites
...des apostrophes non-reconnues, des guillemets, ce genre de trucs. Normalement, ce type d'erreurs survient lorsque les caractères sont importés de Word. Les reprendre dans un éditeur HTML règle habituellement le problème.

Comme tu le dis, cela règle "habituellement" le problème, mais pas toujours.

Que veux-tu dire exactement par "reprendre" ? En fait, ces caractères doivent être remplacés par les caractères valides (l'apostrophe biduleuse de Word par un simple ' ...)

Cependant, cette fois-ci, nous avions beau corriger et corriger, les erreurs refusaient obstinément de partir. Ce n'est qu'en forçant un charset windows-1252 à travers le validateur que nous parvenions à obtenir un code valide XHTML 1.0 transitionnel.

L'hypothèse qui me semble la plus probable est qu'il subsistait des caractères encodés en windows-1252

Share this post


Link to post
Share on other sites
Comme tu le dis, cela règle "habituellement" le problème, mais pas toujours. Que veux-tu dire exactement par "reprendre" ? En fait, ces caractères doivent être remplacés par les caractères valides (l'apostrophe biduleuse de Word par un simple ' ...)

C'est exactement ce que j'entends par reprendre... les ré-écrire moi-même directement dans l'éditeur HTML pour les remplacer.

L'hypothèse qui me semble la plus probable est qu'il subsistait des caractères encodés en windows-1252

Nope... justement je suis absolument catégorique, ils avaient tous été corrigés parce qu'en testant la même page sur mon propre serveur, la validation se faisait automatiquement. C'Est ce qui m'a permis d'éliminer le doute sur le fichier pour ramener les accusations sur le serveur directement.

Share this post


Link to post
Share on other sites

Tu aurais dû faire une 'moulinette', en php par exemple, pour afficher tous les caractères 'invisibles'.

Il en reste parfois, même de bien caché..

Share this post


Link to post
Share on other sites

Mais puisque je vous dit que la même page sur mon serveur validait ! :D

Share this post


Link to post
Share on other sites

Bon, tu as l'air sûr de ton coup ;)

Alors il est tout à fait possible que le serveur ait été paramétré pour envoyer en en-tête HTTP un encodage par défaut (windows-1252) différent de l'encodage réel du fichier (iso-8859-1).

Si c'est le cas et que l'encodage correct était spécifié par une <meta...>, il est facile de s'en assurer: le validateur HTML W3C valide la page, mais signale un "character Encoding mismatch!"

Le WDG validator en revanche ne signale pas cette erreur. Or il me semble que c'est celui que tu utilises de préférence ?

Share this post


Link to post
Share on other sites
Si c'est le cas et que l'encodage correct était spécifié par une <meta...>, il est facile de s'en assurer: le validateur HTML W3C valide la page, mais signale un "character Encoding mismatch!"

Très bonne idée, c'est vrai que c'Est aussi simple que ça. De mémoire je ne m'en souviens plus, je vérifierai avec elle pour voir si c'est le cas (actuellement, comme son site force du winwows-1252 dans les meta, il n'y a aucun overide).

Le WDG validator en revanche ne signale pas cette erreur. Or il me semble que c'est celui que tu utilises de préférence ?

Tout à fait. Sans vouloir lui faire de pub, le validateur du WDG a le mérite de vérifier plus d'une page à la fois (jusqu'à 50) et s'avère parfois moins permissif que celui du W3C. Par contre, par réflexe, c'est tout de même avec le validateur du W3C que je travaille le plus souvent.

Share this post


Link to post
Share on other sites

Cette réputation de moindre permissivité du validateur WDG m'a toujours laissé songeur. Je ne la conteste pas a priori, mais sur quels tests s'appuie-t-elle ?

Share this post


Link to post
Share on other sites
Cette réputation de moindre permissivité du validateur WDG m'a toujours laissé songeur. Je ne la conteste pas a priori, mais sur quels tests s'appuie-t-elle ?

Honnêtement, je ne sais pas car je n'ai jamais fait l'effort d'analyser la situation à fond. Tout ce que j'ai observé jusqu'à présent, c'est que parfois, le validateur W3C proclame une page comme étant confirme alors que le validateur du WDG relève des erreurs... qui peuvent être corrigées pour obtenir une confirmation de validation dans cet outil, sans impacter négativement le validateur W3C.

Rien de scientifique, mais je promets d'y porter plus attention la prochaine fois pour aller chercher une réponse plus fouillée. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...