Aller au contenu

Anubis

Actif
  • Compteur de contenus

    18
  • Inscrit(e) le

  • Dernière visite

Réputation sur la communauté

0 Neutre
  1. Anubis

    PHP, mysql et l'utf8

    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.
  2. 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.
  3. 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.
  4. Le permalien est http://www.genezys.net/blog/2004/09/04/6-p...-coup-de-gueule
  5. 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é :-(
  6. Pas de problème ;-) Ce sujet me tient à cur alors j'aime que tout soit bien clair.
  7. 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
  8. 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.
  9. 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 )
  10. Anubis

    Changer de CSS

    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
  11. 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
  12. 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 )
  13. Merci, je n'osais pas le proposer moi-même
  14. 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...
×
×
  • Créer...