Anubis

Petit info bète, il serait peut-être plus judicieux d'utiliser htmlspecialchars() que htmlentities(). En effet, htmlentities() transforme tous les caractères étendus en entité HTML, ce qui peut être ennuyeux pour le traitement du PHP. Sinon, je dirais que c'est normal de devoir spécifier à ta fonction PHP un codage UTF-8, il ne pourra pas le deviner tout seul tout simplement parce que PHP est très nul avec les codages de caractères. Alors je dirais juste une chose, il faut faire bien attention, et tester ton code dans tous les cas extrèmes car PHP est une vraie plaie dès qu'il manipule des caractères un peu avancés. M'enfin, je le redis, un bon vieux htmlspecialchars() devrait suffir dans ton cas à retirer les balises HTML de tes attributs et à les transformer en texte simple.

Moi je préfère la méthode de mettre chaque page dans un fichier différent, puis d'inclure les parties communes. Vivant avec une débutante qui maintient un gros site d'information (www.lelynx.org), je remarque qu'il est plus simple pour elle de maintenir chaque page indépendamment. Elle peut alors dans un 2e temps tenir compte des parties communes. Mais je mets au défi quiconque de faire des pages maintenables avec des charsets différents en utilisant une seule page incluant toutes les autres.

C'est marrant, moi j'aurais fait : <a href="http://www.epita.fr">ryrtutsdfur</a> Et d'avance pour ceux qui répondront que cette solution fait que ça ne s'ouvre plus dans une nouvelle fenêtre, je répondrai que la réponse se situe dans cet article.

Le permalien est http://www.genezys.net/blog/2004/09/04/6-p...-coup-de-gueule

Oui je suis toujours membre du hub, même si mon activité actuelle m'empêche d'y participer activement ces derniers temps. Sachez que j'en suis vraiment désolé :-(

Pas de problème ;-) Ce sujet me tient à cur alors j'aime que tout soit bien clair.

J'ajouterais un peu de pédagogie à tout ça... Peut-être ne connais-tu pas le concept de type MIME ? (Dans ce cas, je peux comprendre que tout cela soit très confus pour toi.) Lorsqu'un serveur web envoie un document, il envoie aussi une chaine pour expliquer de quel type est la ressource. Le web ne connaissant pas le concept d'extension comme nos OS, il faut une chaine pour expliquer de quel type est un document. Lorsque l'on envoit un document HTML, il faut préciser un type MIME « text/html » avec par exemple une commande PHP du genre : header('Content-Type: text/html'); Heureusement, les serveurs actuels envoit de manière automatique tous les documents PHP en « text/html ». Par contre pour les documents XHTML, il faudrait normalement changer de type MIME pour envoyer du « application/xhtml+xml ». Il existe 2 solutions : changer les extensions de ses fichiers en .xhtml pour que le serveur web envoit tout seul un type MIME XHTML. C'est bien sûr impossible puisque le site ne serait plus consultable avec Internet Explorer qui ne gère pas ce type MIME. Modifer le type MIME envoyé en PHP avec une commande header comme ci-dessus, mais encore une fois Internet Explorer ne fonctionnera pas. Il faut donc envoyer un type MIME différent selon les en-têtes qu'envoie le navigateur et qui contiennent les type MIME qu'il supporte. Tu trouveras plus d'informations sur cette technique dans ce billet de Cybercodeur

En fait, je ne connais pas de navigateurs incapables de parser le xhtml, par contre, certains ne sont pas encore au courant des dernières normes et ne sont pas capables de le gérer dans sa forme la plus standard. Le problème avec l'XHTML est que la spécification recommande de l'envoyer avec un type MIME dérivant de l'XML, se qui force les navigateurs à vérfier la syntaxe XML du document. Pour XHTML, ce type MIME est application/xhtml+xml. Le soucis est que les navigateurs trop anciens ne sont tout simplement pas prêt à recevoir ce genre de contenu, et voyant un type MIME inconnu, propose tout simplement à l'utilisateur de télécharger le fichier. C'est le cas d'Internet Explorer toutes versions par exemple. Le soucis donc lorsque l'on souhaite faire du XHTML le plus proche possible de la norme est d'envoyer de l'XHTML avec le bon type MIME mais seulement aux navigateurs le supportant. On peut alors envoyer un type MIME non conforme comme text/html ou reformater sa page, selon le niveau de compatibilité que l'on souhaite. Maintenant, il faut savoir que ce genre de pratique est vraiment complexe et qu'il est bien souvent plus simple de se restreindre à l'utilisation d'un bon vieux HTML 4.01 qui lui fonctionne partout. J'utilise personnellement l'envoi de types MIME différent selon les navigateurs, mais j'ai vite laissé tomber les idées de reformatage du contenu qui sont bien trop complexes pour le résultat obtenu.

Quoi j'ai même pas posté dans son thread !? (private joke) Bienvenue Hadrien ! (Pourquoi je dis ça alors que tu es en face de moi )

Moi j'aime bien le terme « Apparence » surtout lorsque chaque lien est une zoulie icône toute mignonne qui donne envie de cliquer dessus Puis quand on voit ce que ça fait, c'est encore plus tout zouli et tout mignon

Google ne connait pas que les entités ASCII, il connait aussi l'ISO-8859-1 et l'UTF-8. Pour ce qui est des autres charsets, il ne les connais pas, tout simplement. En ce qui concerne la liste des entités, le mieux reste encore de chercher son caractère dans les tables d'unicode.org et de placer le caractère sous la forme en incluant le code hexadécimal du caractère. De toute manière, les entités ne sont que des mots associés à ces entités Unicode quelque part dans le navigateur. ÉDITION: Ah bah justement Sylvain, l'ISO-8859-15 fait partie des charsets qui ne sont pas reconnus par Google. Voir http://www.psydk.org/ar_2004-03.php#n72 pour plus d'informations

Merci ;-)

J'ai fait tester l'application par des gros hax0r ;-) et ils n'ont rien trouvé. Je planche en ce moment sur les derniers détails de la release finale qui va bientôt sortir (tous les petits bidules à ajouter )

Merci, je n'osais pas le proposer moi-même

J'avais justement chercher dans la recommandation XML, mais ne trouvant pas explicitement, j'ai renoncer... Là dessus, je ne suis plus d'accord, en tout cas, pas dans le fond. Oui, pour nous, ISO-8859-X a encore une utilité, il est clair que c'est le choix le plus juste pour écrire en langue latine. Maintenant, je pense qu'il faut pousser les considérations un peu plus loin que le simple point de vue technique. Choisir un charset est un choix, et comme tout décision, elle est complexe à prendre et nécessite de peuser le pour et le contre. Je ne pense pas que les webmasters actuels ait toutes les clefs pour se poser ces questions. C'est comme beaucoup de choses, le choix peut sembler donner de la liberté, mais bien souvent il restreint en créant des « gethos ». C'est un des grands problèmes du monde du libre, donner la liberté d'un choix ne veut pas forcément dire aider la personne qui va faire ce choix. Je ne suis pas en train de dire que la liberté est une chose attroce, je dis juste que la liberté est bien souvent difficile à assumer, beaucoup trop pour le commun des mortels, surtout dans des domaines dans lesquels ils ne veulent pas forcément s'investir. Il suffit de comparer le monde Mac et Linux, l'un est rigide, l'autre libre, et l'utilisateur n'est perdu que dans le second. Ce que je veux dire est qu'il est toujours possible de choisir le charset le plus adapté au fichier (ou site web) que l'on écris. Maintenant la liberté de faire ce choix est-elle vraiment primordiale face à une intéropérabilité parfaite entre tous les fichiers ? Encore un choix difficile...

Un bon éditeur capable d'enregistrer en UTF-8 Une pincée de PHP pour modifier les en-têtes Une petite balise <meta> si votre épicier n'a pas de PHP UTF-8 est tout simplement loin d'être l'encodage par défaut. Pour les pages HTML par exemple, Firefox choisira automaitquement un charset iso-8859-1 pour une page web ne le spécifiant pas. Il se trouve que beaucoup de pages web utilise un encodage UTF-8 (parce que l'éditeur de leur auteur l'enregistre de cette manière) mais ne le spécifie pas, soit dans une leur en-tête HTTP, soit dans une balise <meta>. Ce que je peux dire à la suite du développement de mon wiki , c'est que l'UTF-8 est bien géré par tous les navigateurs modernes (même IE6) à partir du moment où il est correctement déclaré. Heureusement, les navigateurs choisissent bien souvent l'encodage UTF-8 pour les documents XML, mais je ne pense pas que ce choix soit une généralité.

Bon allez, je me lance dans mon premier billet avec des vrais morceaux d'arguments dedans. Unicode c'est quoi ? Unicode est la norme qui permet d'écrire tous les langages avec un support informatique. Le but d'Unicode est donc de référencer toutes les écritures, puis de proposer des méthodes pour les stocker sur un ordinateur. Le but en soit d'Unicode est donc clair, trouver un format de stockage qui permet à tous les caractères du monde d'être écrits, ceci en total contradiction avec l'ASCII qui ne permet d'écrire que les caractères américains. Unicode devrait-il être utilisé ? Oui, il est trop souvent nécessaire de supporter plusieurs langages internationaux, notamment dans le cadre d'un outil de publication massivement international (forum de l'ONU), ou dans le cas d'un logiciel massivement international (système d'exploitation). Unicode devrait-il être utilisé tout le temps ? Là c'est plus complexe. D'un côté, on peut trouver ceux qui défendent Unicode en disant que l'intéropérabilité est une doctrine qu'il faut toujours suivre quelqu'en soit le prix et qu'Unicode résout enfin tous les problèmes d'incompatibilité des fichiers en mode texte. De l'autre, on trouve les gens qui décrient les inconvénients d'Unicode. En effet, être capable de stocker tous les caractères de la Terre implique un coùt en terme de place ou de calcul (ou les deux, bien souvent les deux). Unicode aujourd'hui ? Il existe aujourd'hui le système des charsets, chacun permettant d'écrire dans une langue précise pour un moindre coùt (1 octet par caractère). Ceux-ci sont donc majoritairement utilisés sur le web aujourd'hui, même pour des langues très exotiques comme le japonais ou le chinois. Unicode est « réservé » de part sa soit-disant lourdeur aux applications possédant plus de ressources, bien souvent les applications locales d'un ordinateur. Mon avis Mon expérience dans le domaine tent à me faire penser que l'idée des charsets, à la base fort intéressante, n'est finalement pas si bonne. En effet, dans un soucis d'économie de la ressource, il a fallu augmenter la complexité des données (devoir spécifier un charset) tout en conservant une compatibilité ASCII. Cette compatibilité est pour moi une erreur, car bon nombre de gens confondent -- et c'est normal -- l'ASCII avec ces versions améliorées que sont les charsets. Si l'on prend par exemple les protocoles en mode texte d'internet aujourd'hui (ftp, http, smtp), beaucoup n'ont pas cette notion de charset, et s'ils l'ont, beaucoup de clients ne songent pas à l'implémenter. Pourquoi ? Parce que cela « devrait fonctionner tout de suite » sans avoir à ajouter une information supplémentaire (le charset). Or l'erreur la plus souvent et la plus rapidement commise est de croire en une compatibilité ASCII et une utilisation de caractères supplémentaires sans ajout d'informations supplémentaires, les applications ayant fait l'erreur de toujours disposer d'un charset par défaut, sans en avertir l'utilisateur. Cette erreur n'aurait selon moi pas été commise si Unicode était devenu la norme de référence tout de suite, sans passer par des « bidouilles » faites sans un soucis d'intéropérabilité, pleins de charsets que les gens ne comprennent pas et ne savent pas changer. Il faudrait une seule norme, comme à la bonne vieille époque de l'ASCII, une norme que tout le monde utiliserait sans se soucier du reste, et tout fonctionnerait. Alors maintenant c'est décidé, je dis non au charsets, c'est mauvais pour mes fichiers. Avant ils étaient ternes et secs, maintenant avec Unicode et tous ses codages (UTF-8, UCS-2), mes fichiers sont soyeux, lisses et brillants. Unicode c'est bon, mangez-en.

Coucou, je viens juste de m'inscrire sur ce forum suite aux pressions que je subissais de mon entourage blogosphérique. Je suis développeur en général, et en tant que développeur, je suis forcément intéressé par tout ce qui touche au web standard (XHTML, PHP, CSS, etc). Je tiens normalement un blog mais certains savent déjà qu'il n'est pas très utile d'aller le visiter ces derniers temps. Bon bah grand chose d'autre à dite, je cours tout de suite contrbuer aux quelques sujets qui ont retenus mon attention. Bravo pour cette initiative.