Bug mystérieux, caractères spéciaux

Bonjour,

Vendredi dernier nous avons eu droit à un mystérieux bug lors d'une mise à jour sur notre site internet.
Étant absente du boulot le vendredi, mon collègue a dû faire lui même un petit ajout sur le template du site (travail sur Dreamweaver cs5.5). Une image toute simple ajouté dans le header.

Mais ce simple ajout à créer tout un bug! Tous les caractères spéciaux (é, à, è, etc.) ont disparue et ont été remplacé par un "?" sur toutes les pages du site.
Le charset en utf-8 n'a pas été touché... Mais du coup impossible de faire revenir automatiquement les caractères... faut faire les changements manuellement! La galère pour un site de plus de 500 pages...

Donc je me demandait si quelqu'un avait déjà rencontré ce genre de bug et saurait ça serait dû à quoi.

Le site a du être développé sur une plateforme open source (exemple eclipse sur linux) et lorsque ton collègue a ouvert le template avec DreamWeaver , celui-ci a briser les caractères spéciaux.
Je ne pourrais pas te dire beaucoup plus que ça, a part que le problème viens de DreamWeaver.
Je te suggère éventuellement de jeter ta licence Dreamweaver à la poubelle.

Merci de te réponse,
À force d'y pensé je soupçonne également Dreamweaver d'en être la cause. Je vais faire quelques recherche voir s'il y a d'autres cas du genre.

Qu'elle galère quand même... plus de 500 pages à réviser...

Bonjour,

Tu peux regarder aussi dans Edit > Preferences > New document. Il y a certaines options à cet endroit concernant l'encoding.

Ouvres aussi ta template et vas dans Modify > Page properties > Title/Encoding pour vérifier si tout est okay.

Pour ce qui est de jeter la licence à la poubelle, c'est juste absurde.
Modifié par Tony Monast (16 Nov 2011 - 19:58)

Tony Monast a écrit :
Pour ce qui est de jeter la licence à la poubelle, c'est juste absurde.

Ça vient du gars qui conseillait, il y a à peine quelques mois, à un débutant de laisser tomber les CSS et d'apprendre d'abord à faire ses mises en page avec des tableaux (sur ce même forum). Donc, non c'est pas absurde, il a une ligne de conduite et des valeurs qu'il défend et il s'y tiens. A notre époque je trouve ça admirable.

En plus tout le monde sait que Dreamweaver ne sait pas gérer l'utf-8.
Modifié par jb_gfx (16 Nov 2011 - 20:10)

Tony Monast a écrit :
Pour ce qui est de jeter la licence à la poubelle, c'est juste absurde.

En effet, c'est complètement absurde! C'est l'objectif ! Je voulais juste dire que je n'aimais pas Dreamweaver. L'expérience de Julie ne fait que confirmer ce que je pensais déjà de Dreamweaver.

jb_gfx a écrit :

Donc, non c'est pas absurde, il a une ligne de conduite et des valeurs qu'il défend et il s'y tiens. A notre époque je trouve ça admirable.

En effet, je n'ai pas un discours creux et sans aucun intérêt. Je donne mon opinion et ceux qui sont en désaccord sont totalement libre de le dire.
Tu devrais prendre exemple sur moi ...

94bri37 a écrit :

Tu devrais prendre exemple sur moi ...

C'est ce que je fais. Tous les ans je me rends au {keynote Apple|fête du PC} pour vanter les mérites de {MS Windows|Parti UMP}.
Modifié par jb_gfx (16 Nov 2011 - 22:03)

Tony, merci pour les pistes, j'ai regarder et rien d'anormal. Un vrai mystère!

Opinion purement subjective... hors de question que je jette ma licence! Jusqu'à maintenant je n'ais jamais eu de problème majeur avec ce logiciel. C'est pas UN bug survenue UNE fois qui va me faire changer de méthode de travail, même si ce bug me fait .

94bri37 a écrit :
Le site a du être développé sur une plateforme open source (exemple eclipse sur linux) et lorsque ton collègue a ouvert le template avec DreamWeaver , celui-ci a briser les caractères spéciaux.

Je ne vois pas de raison d'un tel comportement de Dreamweaver, qui est tout à fait capable de gérer correctement les codages de caractères.

94bri37 a écrit :
Je voulais juste dire que je n'aimais pas Dreamweaver.

Toujours plus de lol.

Bon, méthodo qui va bien:

1. Vérifier avec quel codage les navigateurs lisent la page (menu Affichage > Codage des caractères dans Firefox, par exemple).
2. Vérifier à la fois la présence d'une balise META charset qui va bien, et la présence d'une information de charset dans les en-têtes HTTP. (Si on n'a pas l'habitude de vérifier les en-têtes HTTP d'une réponse, il faut apprendre à le faire, ça fait partie des compétences absolument indispensables en développement web.)

Normalement on devrait avoir de l'UTF-8 partout pour les points 1 et 2.

Ensuite, il faut déterminer si les points d'interrogation qui apparaissent sont:
- des caractères "?" littéraux;
- des caractères spécifiques qui signifient «je ne peux pas afficher ce caractère car je ne le reconnais pas» (le symbole peut être un rectangle vide, un rectangle avec une valeur numérique affichée dedans, un point d'interrogation dans un losange, etc.).

On peut aussi tester si en basculant l'interprétation de la page (via à nouveau le menu Affichage > Codage des caractères dans Firefox ou équivalent dans d'autres navigateurs), notamment en ISO-8859-1, Windows-1252 ou MacRoman, on obtient un affichage correct des caractères problématiques. Si on obtient un affichage correct de ces caractères par exemple en MacRoman, c'est que les données qui aboutissent sur la page -- et dans le cas de pages HTML statiques ou de fichiers PHP simples sont écrites telles quelles dans les fichiers -- sont en MacRoman.

Si pour une raison ou une autre tous les fichiers d'un site ou certains d'entre eux ont été convertis dans un codage non souhaité (par exemple ISO-8859-1), on peut reconvertir les fichiers vers UTF-8. Attention, si la source était en UTF-8 puis a été convertie dans un codage qui propose un jeu de caractères plus restreint, il se peut qu'on ait perdu des caractères au passage. Des outils tels que iconv permettent de faire des conversions en masse. Attention aussi au comportement des éditeurs de code, qui interprètent toujours un fichier avant de l'afficher (c'est à dire que les caractères que l'on voit dans Dreamweaver ou ailleurs sont une interprétation, pas «la vérité»... revoir les notions de base des codages de caractères si ça n'est pas évident).

Enfin, il est possible que suite à une mauvaise manipulation on ait corrompu (et pas juste converti) des données. Dans ce cas, le salut s'appelle 1) sauvegardes et 2) systèmes de gestion de révisions (SVN, Git, etc.). Vu l'ampleur du projet, j'ose espérer que de telles mesures ont été prises?

94bri37 a écrit :
Le site a du être développé sur une plateforme open source (exemple eclipse sur linux) et lorsque ton collègue a ouvert le template avec DreamWeaver , celui-ci a briser les caractères spéciaux.

Je n'avait pas relevé ce point. Mais de toute façon ça ne s'applique pas ici. Le site a été entièrement développé sur Dreamweaver en mode "code" bien entendu. C'est notre outils de travail.

Je penche plus pour l'explication qu'a donné Tony. Je pense que mon collègue n'a peut-être pas les mêmes config. On va vérifier ça pour éviter que le problème ne se reproduise en mon absence. Maintenant il n'ose plus faire la moindre modif!

fvsch: merci pour ta réponse!

fvsch a écrit :
1. Vérifier avec quel codage les navigateurs lisent la page (menu Affichage > Codage des caractères dans Firefox, par exemple).
2. Vérifier à la fois la présence d'une balise META charset qui va bien, et la présence d'une information de charset dans les en-têtes HTTP. (Si on n'a pas l'habitude de vérifier les en-têtes HTTP d'une réponse, il faut apprendre à le faire, ça fait partie des compétences absolument indispensables en développement web.)

Normalement on devrait avoir de l'UTF-8 partout pour les points 1 et 2.

Vérifier et re-vérifier, rien n'a été changé à ce niveau.

fvsch a écrit :
Ensuite, il faut déterminer si les points d'interrogation qui apparaissent sont:
- des caractères "?" littéraux;

Littéralement. Donc tout les accents ont été remplacé par un ? .

Je note pour "iconv". Je vais regardé ça, sait-on jamais.

fvsch a écrit :
Enfin, il est possible que suite à une mauvaise manipulation on ait corrompu (et pas juste converti) des données. Dans ce cas, le salut s'appelle 1) sauvegardes et 2) systèmes de gestion de révisions (SVN, Git, etc.). Vu l'ampleur du projet, j'ose espérer que de telles mesures ont été prises?

1) une sauvegarde est fait à tous les vendredi en fin de journée... dans ce cas précisément, le bug c'est produit justement le vendredi, avant de faire la sauvegarde... et comme j'avais effectué plusieurs mise à jours durant la semaine, du coup on pouvait pas aller chercher les sauvegarde sans perdre les autres mise à jours. Et j'étais absente ce jour-là.

2) Connait pas... je me renseigne sur le sujet. Merci!

code source de la fameuse page si tu peux????