[Résolu] Apostrophe non valide

Bonsoir,

En regardant au validateur du W3C quelques pages dynamiques, je m'apercois que des apostrophes posent problème.

En les effacant et recopiant directement dans la base MySQL, tout redevient valide.

Je pense que c'est le fait de copier-coller du texte depuis word dans un formulaire (formulaire de la console d'administration du site en question).

Si c'est ça, comment y remédier ? Je ne vois pas là... Mais peut-être que je fais fausse route ?

D'ailleurs, je m'apercois que le validateur valide désormais les caractères accentués (non codés en html) ?
Modifié par Yhann (02 Mar 2005 - 08:46)

oui, en ISO, il faut un apostrophe droit. Or, word fait les apostrophes arrondis. Colle le texte de Word sur BlocNote, sélectionne un apostrophe et Edition/Remplacer, et colle l'apostrophe Word sur le premier champ, et tape un ' dans le second et clique sur Remplacer tout

Enfin bref

Salut Anthony,

Ce n'est pas moi qui procède aux mises à jour, et tout cela me semble compliqué. Et pour ne rien arranger, l'utilisateur veut absolument utiliser Word.

Je pourrais demander à la personne de modifier quelques réglages dans Word (c'est possible) mais c'est ennuyeux.

En fait, je pensais surtout à une solution côté site internet lui-même. Peut-être un changement d'apostrophe avec PHP, mais là, on quitte le domaine des CSS...

Et pour ce qui est des accents ? Pourquoi sont-ils validés maintenant par le W3C ? Alors qu'avant, il fallait que je les remplace par leur équivalent HTML ?

Dure journée aujourd'hui...

Personnellement, j'utilise ’ (right single quotation) pour les apostrophes. Le problème à coder avec Word est qu'il transforme (préférences?) automatiquement les apostrophes et les guillemets. Une solution serait de sauver en "plain text". L'encodage doit être ISO-8859-1(5) ou utf-8. Toujours est-il que coder avec Word est une très mauvaise idée.

En fait, le modo ne code pas avec Word, mais écris avec pour profiter entre autre du correcteur d'orthographe, puis fait un copier-coller dans l'interface web d'administration du site. Il ne s'agit pas de code, mais de texte bien français qui alimente une base sql.

Pour ce qui est des accents : que faut-il privilégier comme codage, comment faites-vous ?
Modifié par Yhann (01 Mar 2005 - 21:28)

En fait, mes 2 sites de référence n'utilisent pas le même encodage :

OpenWeb : charset=utf-8
Alsacreation : charset=iso-8859-1

Salut Yhann,

As-tu regardé dans la F.A.Q. Il y a une question à ce sujet.

http://forum.alsacreations.com/faq/#item36
Modifié par Merkel (01 Mar 2005 - 21:40)

Merci Merkel. Effectivement, je n'avais pas lu le sujet corespondant dans la FAQ . Surtout le lien pointant vers un POST sur le sujet.

J'utilise l'iso-8859-1, qui après mes lectures précédentes, me semble le mieux convenir. Sauf que certaines de mes pages ne seront pas valides xhtml strict à cause de caractères spéciaux insérés dynamiquement, et que je ne maîtrise pas.

C'est quand même vraiment gênant. Je ne sais pas comment faire.

En fait, à bien y réfléchir, il semble possible (à moins que ce cas est été prévu et dans ce cas, je veux bien savoir comment ) de rendre invalide n'importe quel site xhtml strict en insérant dans le message de commentaire (blog par exemple), ou tout autre endroit où il est possible de poster, un caractère non conforme. C'est bien ça ? Alors, faut-il en tenir compte, ou pas ? Et dans ce dernier cas, est-il honnête de placer un texte "valide xhtml" si a tout moment le site peut ne plus l'être ?

Je sais que je suis du genre à me poser souvent trop de question, mais là, ça me perturbe, d'autant que tous les sites dynamiques que j'ai fait sont donc concernés, et peuvent donc ne plus être valide xhtml après une mise à jour du contenu d'un article par la personne chargée de l'administration.

Dur dur...
Modifié par Yhann (01 Mar 2005 - 22:21)

Tu ne sais pas quoi faire ? Pourtant, un peu plus haut, anthony t'as proposé une solution en PHP. Lorsque tu insère les données dans mySql, j'imagine que tu passe par une requête SQL appelée par PHP ? Tu pourrais donc remplacer le ou les caractères nuisibles AVANT d'insérer les données dans la base de données. Pour ce qui est des caractères déjà dans ta base, tu peux utiliser une requête SQL sur tous les enregistrements avec une fonction sql de remplacement de caractère. Un peu de googling, tu devras faire, mon fils.

Amen

Oui, c'est la solution. Mais il ne faut pas le faire uniquement pour l'apostrophe, et du coup, pour ne pas oublier un caractère, il vaudrait mieux procéder dans l'autre sens, en vérifiant que chaque caractère fait partie du jeux de caractères autorisé. Cela me semble lourd, non ?

Mais tu as raison, c'est sûrement l'unique solution.

Je venais d'éditer mon précédent post quand tu as envoyé le tient, Merkel.

Pour rebondir sur mon précédent, donc, est-ce comme cela que vous procédez, ou ne faites-vous pas attention aux saisies des utilisateurs ?

Merci pour vos précédentes réponses, en tout cas.

Ca peut être lourd, oui, si à chaque affichage, tu convertis les caractères incriminés. C'est pourquoi tu dois le faire lors de l'insertion des données afin d'avoir un texte purifié et béni par les dieux dans ta base. Il peut aussi s'avérer moins long de tolérer un jeu de caractères (a-z,A-Z,0-9,àéèê etc..) plutôt que de rechercher ceux qui ne sont pas tolérés.

Pour ce qui est du problème lié aux sites (x)html et où on retrouve certaines parties gérées par un utilisateur, via un outils souvent imparfait au niveau du respect sémantique et (x)html, évidemment, ca casse souvent le travail effectué au niveau du respect des standards. Je souffre du même problème, des sites se voulant (x)html, mais avec des communiqués et des articles sales. Pour le moment, j'ai pris une décision. Je préfère permettre aux clients de créer et modifier des articles facilement, en leur donnant la liberté de formatter le texte aussi simplement que dans Word, plutôt qu'avoir un site 100% standard mais exigeant au client une connaissance du langage (x)html ou de bbcodes compliqués. J'attends impatiemment que les outils Wysiwyg online s'améliorent. Pour des sites persos, je préfère ne pas utiliser ce genre d'outils, donc le code reste propre.

Je terminerais avec cette citation improvisée de moi-même : "Vouloir produire un site respectant les standards avec un Wysiwyg online, c'est comme vouloir coiffer une vedette avec une tondeuse à gazon. Ca marche, mais ca va saigner..."
Modifié par Merkel (01 Mar 2005 - 22:56)

Stephan a écrit :

Personnellement, j'utilise ’ (right single quotation) pour les apostrophes. Le problème à coder avec Word est qu'il transforme (préférences?) automatiquement les apostrophes et les guillemets. Une solution serait de sauver en "plain text". L'encodage doit être ISO-8859-1(5) ou utf-8. Toujours est-il que coder avec Word est une très mauvaise idée.

Je ne comprend pas là. J'ai écrit l'entité et le forum a transformé. Je recommence.

Donc, j'utilise &*rsquo; (sans l'astérisque)

Depuis quand le forum interprète les entités ?

Même en écrivant &*amp;&*rsquo; (sans les astérisques), si je prévisualise deux fois, retour à la case départ.

Yhann a écrit :
En fait, à bien y réfléchir, il semble possible (à moins que ce cas est été prévu et dans ce cas, je veux bien savoir comment ) de rendre invalide n'importe quel site xhtml strict en insérant dans le message de commentaire (blog par exemple), ou tout autre endroit où il est possible de poster, un caractère non conforme. C'est bien ça ?

Dotclear est un bon exemple ici : les contenus saisis (billets et commentaires) sont corrigés avant d'être ajoutés à la BD pour effectuer les susbstitutions nécessaires.

Sinon, le problème de l'apostrophe avec Word vient de l'utilisation d'un codage de caractère (charset) propre à Microsoft (windows-1252) qui est compatible avec Unicode (le jeu de caractères validant pour HTML) SAUF pour une poignée de caractères pour lesquels Microsoft utilise des positions incorrectes dans Unicode. L'apostrophe est de ceux-là, mais aussi la ligature oe, le point de suspension, les tirets cadratins et demi cadratins, le sigle TM, divers guillemets anglais, etc.
Ta fonction de conversion windows-1252 --> Unicode doit donc couvrir l'ensemble de ces caractères. Voir http://openweb.eu.org/articles/caracteres_illegaux/ pour la liste.

---
Je vis alors la grande prostituée de Babylone, et sur son front était écrit le chiffre de la Bête: windows-1252, Apocalypse selon Saint Jean, XIII-2
Modifié par Laurent Denis (02 Mar 2005 - 06:16)

<pollution />

Jésus lui disait en effet : « Esprit mauvais, sors de cet homme ! » Et il lui demandait : « Quel est ton nom ? » L’homme lui répond : « Je m’appelle Légion, car nous sommes beaucoup. » Et ils suppliaient Jésus avec insistance de ne pas les chasser en dehors du pays. Or, il y avait là, du côté de la colline, un grand troupeau de porcs qui cherchait sa nourriture. Alors, les esprits mauvais supplièrent Jésus : « Envoie-nous vers ces porcs, et nous entrerons en eux. » Il le leur permit.

Merci à tous pour vos réponses (bien que je ne comprenne pas bien la dernière... )

Je vais donc procéder de la sorte, en corrigent les caractères non conformes avant l'entrée en base de données.

Merci à Laurent pour le lien vers les caractères illégaux, très utile effectivement.

Merci encore.

Puis-je ajouter que HTML Tidy corrige ce genre de problèmes (CP1252 -> ISO 8859-1, mauvais code produit par Word, etc.) très bien et automatiquement ?