[toto]

Je viens d'acquérir iWeb et ça donne ABSOLUMENT N'IMPORTE QUOI !!! Je suis sidéré ! Par exemple les accents ne passent pas (sortent d'autres caractères), alors je me suis dit qu'il fallait les coder soi-même : non plus ! Rien ne passe une fois le site publié (pas sur l'ordi, certes), est-ce parceque je ne l'ai pas publié sur .mac ? Faudrait prévenir !
J'ai vérifié sur FF, IE, Safari : même résultat en ligne. En plus des boûts de phrases qui sont censés être supprimés et les met dans des endroits imprévus etc. C'est ahurissant !! Je n'ai pourtant aucun problème sur mes autres logiciels et je suis sur powerbook G4, Tiger et tout ce qu'il faut de plus officiel. A n'y rien comprendre ! Une déception effroyable ! Je suis tout de même surpris que personne ne mentionne au moins ces problèmes de codification des accents...http://www.macplus.net/forums/style_images/macplus/folder_post_icons/icon8.gif

[Jippy]

toto, le Aug 12 2006, 18:54, dit :

Je suis tout de même surpris que personne ne mentionne au moins ces problèmes de codification des accents...http://www.macplus.net/forums/style_images/macplus/folder_post_icons/icon8.gif

Tu es peut-être le seul à les avoir ...
Explique clairement ce que tu fais, comment tu le fais et ce que tu obtiens.
Ensuite on avisera !

[toto]

Précisions:

- les "é" donnent "é" en ligne mais pas systématiquement (!!) parfois ils sont correctement affichés !
- les apostrophes ("'") donnent "’"
- un "û" donne "Ã"

Sinon, autre chose, je me suis trompé sur un point : la désorganisation totale du rapport texte-image était due au fait qu'après modif je n'avais pas uploadé les dossiers à nouveau (seulement la page html, or ça ne suffit pas car des données importantes, pas uniquement les photos, se trouvent dans des dossiers...).
Mais tout de même l'édition du texte est un casse-tête dans iweb, si on dépasse des cadres, impossible de visualiser le "hors-cadre" sans effacer du texte, assez ingérable à mon goût...

[toto]

Jippy, le Aug 13 2006, 01:23, dit :

Tu es peut-être le seul à les avoir ...
Explique clairement ce que tu fais, comment tu le fais et ce que tu obtiens.
Ensuite on avisera !

Eh bien il s'agit simplement de commentaires que je rajoute à des photos "exportées vers iweb" d'iphoto. Police par défaut de la page : "cochin - regular". Sinon rien de particulier, j'ajoute un commentaire dans le cadre des photos, là où se trouve leur nom (donc du texte en plus du titre). &Ce qui est curieux encore une fois c'est que l'erreur concernant le "é" n'est pas systématique ! Même pour un même mot ("vélo" par exemple peut être correct ou incorrect).

[Bernardo]

toto, le Aug 13 2006, 01:54, dit :

- les "é" donnent "é" en ligne mais pas systématiquement (!!) parfois ils sont correctement affichés !
- les apostrophes ("'") donnent "’"
- un "û" donne "Ã"

Il s'agit tout simplement de l'encodage. Par défaut, le serveur Apache laisse l'utilisateur choisir son encodage mais des informaticiens zélés s'amusent à paraméter le serveur pour encoder selon un protocole spécifique (isolatin en général). C'est sûrement à cause des Windowsien qui utilisent des logiciel de merde (de Microsoft, je veux dire).

Solution : changer de fournisseur ou demander de rajouter une ligne au serveur Apache pour que ton compte ne soit pas affecté. Tu peux aussi leur demander de rétablir le paramétrage par défaut du serveur Apache mais ils vont sûrement refuser car alors, les pages déjà en place risquent de ne plus fonctionner.

C'est du vécu. J'ai mis plusieurs semaines à obtenir satisfaction. C'était pas pour iWeb, mais pour iCal et Pages, donc j'imagine que c'est la même chose.

A part ça, inutile de hurler au loup sur les forums quand tu as un problème. Explique toi simplement et on cherchera à te dépanner.

[toto]

[quote name='Bernardo' date='Aug 13 2006, 13:37' post='114964']
"Il s'agit tout simplement de l'encodage. Par défaut, le serveur Apache laisse l'utilisateur choisir son encodage mais des informaticiens zélés s'amusent à paraméter le serveur pour encoder selon un protocole spécifique (isolatin en général)."


Merci pour les infos. Je ne suis pas sur serveur Apache (je devrais peut être tenter d'ailleurs pour voir). J'utilise Transmit pour uploader en ftp et mon hébergeur est Cegetel. Effectivement le problème doit être un problème de codage, d'une manière ou d'une autre...

[Bernardo]

toto, les pages Web que tu crées sont interprétée par un serveur qui les affiches. En général, c'est un serveur Apache (sous Mac OS X aussi). Si tes pages sortent correctement sur le mac et mal encodée ailleurs, c'est parce qu'ailleurs, ont force l'encodage. Je ne vois pas pourquoi le client ftp serait responsable... les fichiers que tu as envoyés sont sûrement corrects. C'est leur interprétation là bas qui déconne.

[pfuittt !]

Bernardo, le Aug 13 2006, 18:56, dit :

les fichiers que tu as envoyés sont sûrement corrects. C'est leur interprétation là bas qui déconne.

Ce qui s'affiche de travers est visiblement de l'UTF-8 affiché par un navigateur qui s'attend à voir un encodage à l'ancienne comme de l'iso-8859-1.
Il faudrait voir si dans le head il y a effectivement la balise
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
qui devrait empêcher toute ambiguïté.
Quand l'encodage est précisé dans la balise, le serveur n'est pas censé touiller quoi que ce soit dans l'encodage de la page, il doit la transmettre telle qu'elle est.

[Bernardo]

hr, le Aug 13 2006, 23:35, dit :

Ce qui s'affiche de travers est visiblement de l'UTF-8 affiché par un navigateur qui s'attend à voir un encodage à l'ancienne comme de l'iso-8859-1.
Il faudrait voir si dans le head il y a effectivement la balise
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
qui devrait empêcher toute ambiguïté.
Quand l'encodage est précisé dans la balise, le serveur n'est pas censé touiller quoi que ce soit dans l'encodage de la page, il doit la transmettre telle qu'elle est.

Pour un développeur de site web, effectivement, c'est ce qu'il faut faire. Mais si on veut tout simplement partager un calendrier, faire un export html à partir de pages (c'était mon cas) ou (comme toto) mettre en ligne un site iWeb, on veut que ça marche et puis c'est tout. On ne veut pas trafiquer le code. On veut juste que les hébergeurs configurent leur serveur de manière à ce que ça marche.

[pfuittt !]

Bernardo, le Aug 15 2006, 12:36, dit :

On veut juste que les hébergeurs configurent leur serveur de manière à ce que ça marche.

Si le serveur se contente de transmettre sans rien modifier c'est déjà bien mais ça ne résout pas le problème puisque le navigateur, à l'arrivée, affichera selon sa configuration d'encodage par défaut.

Ce message a été modifié par hr - 15 August 2006 - 02:46 PM.

[toto]

Je réponds à tous à la fois :

Oui il semble assez logique que ce ne soit pas le logiciel d'envoi qui déforme le code mais plutôt le serveur. Il faudrait que je me renseigne pour savoir lequel est employé par Cegetel et ce qui est possible...

Sinon j'ai vérifié, il y a ce qu'il faut dans la balise "head", donc ce n'est pas ça (merci tout de même pour le tuyau, ça peut toujours servir).

Effectivement ça serait peut être bien qu'on se décide soit à standardiser, soit à étendre les compatibilités ou je ne sais quoi qui fasse que ça marche...

@+java script:emoticon('', 'smid_16')

[Bernardo]

toto, le Aug 16 2006, 01:13, dit :

Effectivement ça serait peut être bien qu'on se décide soit à standardiser, soit à étendre les compatibilités ou je ne sais quoi qui fasse que ça marche...

Les pages web créées par iWeb (ou comme je le disais plus haut, Pages, iCal, etc.) publiées sur un serveur Apache non trafiqué s'affichent parfaitement partout... J'ai eu une longue conversation avec les informaticiens de ma fac à cause de ce problème (ils avaient trafiqué le serveur Apache). Je ne suis pas un spécialiste. Je parle juste d'expérience.

[pfuittt !]

toto, le Aug 16 2006, 01:13, dit :

Oui il semble assez logique que ce ne soit pas le logiciel d'envoi qui déforme le code mais plutôt le serveur.

Pour être sûr de ce qui se passe, je ne peux que te conseiller de prendre ton fichier original et le même tel qu'il est renvoyé, et de le charger dans textwrangler (version gratuite de bbedit). Une fois ouvert dans TW, tu le rouvres avec File/Reopen Using Encoding en chosissant différents encodages jusqu'à trouver l'affichage correct. En examinant les cacractères accentués et autres c'est un moyen très sûr et rapide de savoir dans quel encodage est réellement le fichier. Au moins tu sauras à quoi t’en tenir.

[Bernardo]

hr, le Aug 16 2006, 16:19, dit :

Pour être sûr de ce qui se passe, je ne peux que te conseiller de prendre ton fichier original et le même tel qu'il est renvoyé, et de le charger dans textwrangler (version gratuite de bbedit). Une fois ouvert dans TW, tu le rouvres avec File/Reopen Using Encoding en chosissant différents encodages jusqu'à trouver l'affichage correct. En examinant les cacractères accentués et autres c'est un moyen très sûr et rapide de savoir dans quel encodage est réellement le fichier. Au moins tu sauras à quoi t’en tenir.

Et en plus, tu fais de la pub pour TextWrangler, ce qui est une très bonne idée ;-)

[toto]

Pardon je suis distrait, j'ai oublié tout simplement que les accents sont codifiés bizarrement dans la page html même que produit Iweb à partir du texte original ! Il y a donc bel et bien un problème du côté de Iweb, ainsi :

- "é" devient "√©" en html (au lieu de "&eacute;")
- "û" devient "√ª" (au lieu de "&ucirc;")
- "à" devient "√†" (au lieu de "&agrave;")

La codification ne respectant pas html (du moins pas le standard) il est normal que cela soit mal interprété et que ça donne quelque chose qui n'a aucun rapport avec la choucroute.java script:emoticon('', 'smid_16')

[toto]

Et une dernière chose... malgré cet encodage bizarre des caractères accentués, je reprécise bien que la page, tant qu'elle est localisée sur mon ordi, est bien interprétée (la codification "bizarre" dont je viens de parler a donc bel et bien un sens). C'est lorsqu'elle est mise en ligne que ça déconne... Quelqu'un reconnaît-il cette codification ? De quoi s'agit-il ?

[pfuittt !]

toto, le Aug 17 2006, 10:47, dit :

Et une dernière chose... malgré cet encodage bizarre des caractères accentués, je reprécise bien que la page, tant qu'elle est localisée sur mon ordi, est bien interprétée

Je répépépépépépépète, ce n'est absolument pas un encodage bizarre, c'est de l'utf-8 affiché par un navigateur qui s'attend, par exemple, à de l'iso latin 1 et donc se fourvoie. Ça se reconnaît du premier coup d'œil quand tu vois un é qui devient √©, puisque l'utf est le seul système qui encode certains caractères en 2 octets ou plus. Reste à savoir pourquoi le navigateur se plante. Brève explication pour comprendre le fond de l'affaire :

1) L'utf permet d'avoir un code unique pour un caractère donné.

2) L'utf contient tous les caractères et idéogrammes de toutes les langues plus des floppées de symboles de math, de signalisations de toilettes pour hommes et de salles pour langer les bébés dans les aéroports (je rigole pas !), les signes de notations musicales et j'en passe des tonnes plus baroques les uns que les autres et il reste même encore beaucoup de place libre, le tout dans un système unique.

Autrement dit, il n'y a plus besoin d'encodage X pour une langue et Y pour une autre. Si la police utilisée pour l'affichage contient le caractère du code qui se trouve dans la page, l'affichage sera correct.

Une des conséquences est qu'on peut afficher à la fois des idéogrammes japonais, du cyrillique et de l'arabe sans problème dans une même page, l'encodage étant unique. Un certain code représentera toujours le même symbole quelque soit le contexte.

C'est surtout pour cette raison qu'on a inventé l'utf (u comme universel). C'est l'encodage que tout le monde devrait employer maintenant, sauf cas très particulier de compatibilité avec des données existantes comme l'utilisation d'une un base de donnée ancienne en latin-1 (exemple vécu il y a peu…).

Oui mais… mais… Tout ça avec 8 bits ?
En effet, comme son nom l'indique, l'utf-8 est un encodage en 8 bits, mais 8 bits ça ne suffit pas pour encoder un nombre aussi énorme de caractères. Donc l'utf-8 encode certains caractères en un multiple de 8 bits. Il le fait d'une façon très maligne qui évite au logiciel qui interprète le code (par exemple un navigateur) de s'embrouiller en interprétant un caractères codé sur 2 octets comme 2 caractères codés chacun sur 1 octet. C'est de là que vient ton é qui s'affiche en deux caractères √© parce que ton navigateur ne sait pas que c'est de l'utf-8.

J’avais dit « brève explication »… J'espère ne pas avoir fait fuir tout le monde, mais je crois que c'est toujours bon à savoir. Et d’ailleurs si ça ne suffit pas, tout est sur le site http://www.unicode.org/

toto, le Aug 17 2006, 10:47, dit :

La codification ne respectant pas html (du moins pas le standard) il est normal que cela soit mal interprété et que ça donne quelque chose qui n'a aucun rapport avec la choucroute.

Non non, c'est tout à fait correct, il n'est pas indispensable du tout selon la norme d'encoder les caractères non ascii avec des entités genre &eacute; (sauf dans les alt des images et les title des balises). Mais il faut la fameuse balise <meta http-equiv="content-type" content="text/html; charset=utf-8" /> dont je parlais faute de quoi le navigateur ne peut pas savoir quel encodage est employé, ce qui est logique. Tout coder en entités permet de ne pas utiliser d'encodage, mais ce n'est valable que pour les caractères latins et pas tous, loin de là.

Alors de deux choses l'une :
- soit iWeb est un âne bâté parce qu'il code les pages en utf-8 sans mettre la balise et c'est lui le coupable,
- soit iWeb fait les choses proprement et c'est le serveur qui fait quelque chose de franchement louche !

D'où ma suggestion de comparer le contenu de la page telle qu'elle est envoyée et reçue pour savoir où est situé le sac de nœuds.

Si tu as une adresse d'une page qui pose problème je veux bien aller jeter un œil scrutateur.

[toto]

p.1) Je répépépépépépépète, ce n'est absolument pas un encodage bizarre, c'est de l'utf-8 affiché par un navigateur qui s'attend, par exemple, à de l'iso latin 1 et donc se fourvoie.

Ok ok va pour l'utf-8, formidable, mais je n'ai enlevé aucune police de mon ordi, j'ai une version de Tiger tout à fait normalement installéé, et le résultat était le même (eh oui j'ai transformé la page manuellement par remplacements de caractères...) sur IE, Safari, Firefox ! Police absente ? Je vais voir mais c'est étonnant puisque j'utilise celle d'une page par défaut...Mais je vais aller voir le lien que tu donnes voir s'il peut me donner une piste sur le "pourquoi dans mon cas c'est comme ça"... merci.

p. 2) Si tu as une adresse d'une page qui pose problème je veux bien aller jeter un œil scrutateur.
[/quote]

Ah dac, bon alors je remets temporairement en ligne ce qui sort directement d'Iweb. Adresse :
Ma page Web

[toto]

...où l'on voit d'ailleurs que le code source est lui-même modifié (plus utf-8) ! Regardez bien toute la page et vous verrez que parfois l'accent aigu apparait, parfois non, pour une même police ("cochin-regular").

[toto]

Ca y est j'ai compris ! La page, malgré la balise utf-8, n'active pas utf-8 ! Et effectivement, en choisissant l'encodage utf-8 dans le navigateur, la page apparaît correctement. Comment remédier à la sélection d'encodage "ISO-8859-1" à l'ouverture de la page ? Est-ce que ça peut être lié au serveur ?