[Résolu] Encodage ANSI non pris en compte

Bonjour,
j'ai un problème de mauvais encodage assez pénible à résoudre:
sur cette page lorsque l'on clique sur le bouton more détails (dans le premier bloc de features), le premier paragraphe du texte de la page appelée n'est pas bien encodé (caractère accentués...).

Pourtant j'ai bien enregistré la page en question en ANSI via Notepad mais rien à faire, ça veut pas marcher.
J'ai essayé de copier/coller le 2ème paragraphe à partir de Notepad, même résultat
Cette page ou plutôt ce bout de code (pas d'iframe générée ici) est appelé via Thickbox. Est ce que ça peut venir du jS?
Modifié par Hermann (19 Mar 2009 - 16:47)

Je ne sais pas si ça a à voir mais la page du site est 8859-15 et la thickbox en 8859-1.

Salut,

Aucun encodage n'est spécifié pour cette portion de page dans les en-têtes HTTP, ce qui explique ce comportement.

Par ailleurs, même si c'est hors-sujet, la dégradation en mode sans JavaScript est loin d'être parfaite ici puisque l'utilisateur se retrouve avec une portion de page HTML lorsqu'il clique sur le lien.

Merci Patidou mais je doute que ça vienne de là, ce n'est pas de l'UTF8 de toute façon.

Julien Royer a écrit :
Salut,
Aucun encodage n'est spécifié pour cette portion de page dans les en-têtes HTTP, ce qui explique ce comportement.

Je sais ça mais je n'ai pas la main sur la config du serveur, ça devrait être ajouté plus tard lorsque toutes les pages passeront en UTF8. Y a-t-il un autre moyen de résoudre le problème?

Julien Royer a écrit :
Par ailleurs, même si c'est hors-sujet, la dégradation en mode sans JavaScript est loin d'être parfaite ici puisque l'utilisateur se retrouve avec une portion de page HTML lorsqu'il clique sur le lien.

Je sais, à ce niveau là je dois faire un petit compromis, pas bien dramatique... Ceux qui n'ont pas le JS d'activé devraient s'attendre à un contenu dégradé.
Au départ une iframe était générée via des paramètre passées à l'URL mais il se trouve que ces paramètres posaient problème à un autre paramètre ajouté par le serveur d'application. Malheureusement je n'ai pas la main dessus et mes faibles compétences en JS ne m'ont pas permis de transférer ces paramètres dans le JS.
Modifié par Hermann (17 Mar 2009 - 17:31)

Hermann a écrit :
Je sais ça mais je n'ai pas la main sur la config du serveur, ça devrait être ajouté plus tard lorsque toutes les pages passeront en UTF8. Y a-t-il un autre moyen de résoudre le problème?

A mon avis, les deux solutions disponibles sont les suivantes :
- Spécifier l'encodage dans les en-têtes HTTP de la réponse ; solution déjà évoquée
- Forcer l'interprétation de la réponse HTTP dans un encodage donné au niveau du code JS ; c'est assez risqué en cas de changement d'encodage, et ça demande de modifier le code de la bibliothèque utilisée.

En ce qui concerne la seconde solution, je ne sais plus si cela est possible et comment...
Modifié par Julien Royer (17 Mar 2009 - 18:01)

Julien Royer a écrit :

- Forcer l'interprétation de la réponse HTTP dans un encodage donné au niveau du code JS ; c'est assez risqué en cas de changement d'encodage, et ça demande de modifier le code de la bibliothèque utilisée.

En ce qui concerne la seconde solution, je ne sais plus si cela est possible et comment...

Merci à toi.
Mais à l'origine il doit bien y avoir un problème d'encodage du texte source, puisque le second paragraphe de la première "pop-up" est bien encodé, non?
Modifié par Hermann (17 Mar 2009 - 18:09)

Remarque générale: attention à ne pas confondre «encodé» et «affiché» (ou «interprété»). C'est pas la même affaire. Un fichier ou des données sont bien encodés à partir du moment où un encodage a été utilisé pour enregistrer les données, et que le fichier enregistré représente bien les données dans l'encodage utilisé (en gros, pas de valeur illégale, et pas de données corrompues). Un fichier ou des données bien encodés peuvent être mal affichés (souvent parce que l'encodage des données n'est pas bien déclaré).

Hermann a écrit :
Mais à l'origine il doit bien y avoir un problème d'encodage du texte source, puisque le second paragraphe de la première "pop-up" est bien encodé, non?

Le premier paragraphe contient des valeurs propres à UTF-8 (ex: «é» encodé en UTF-8).
Le second paragraphe contient uniquement des valeurs compatibles ASCII (ex: «é»).

Si tu as cette possibilité et que ça ne devient pas un cauchemar pour la maintenance, écrire les caractères non-compatibles ASCII sous la forme d'entités HTML peut être une bonne idée pour contourner le problème.

Florent V. a écrit :

Si tu as cette possibilité et que ça ne devient pas un cauchemar pour la maintenance, écrire les caractères non-compatibles ASCII sous la forme d'entités HTML peut être une bonne idée pour contourner le problème.

Ah oui c'est vrai j'avais pas pensé à cette solution. Merci