Aller au contenu

Nudrema

Webmaster Régulier
  • Compteur de contenus

    68
  • Inscrit(e) le

  • Dernière visite

Réputation sur la communauté

0 Neutre

Pour me contacter

  • Mon Site
    http://
  1. On aura quand même dit 3× d'aller voir l'article d'OpenWeb, hein UltraEdit je sais pas où est le bouton pour sauvegarder, je ne l'ai jamais utilisé... Denis> Je dirais aussi que c'est parce que l'encodage par défaut de nombreux éditeurs est l'iso-8859-1 ou l'un de ses dérivés (windows-1252 ou macroman). Mais l'iso a aussi ses avantages, par exemple le poids de la page sera légèrement inférieur à la même page en utf-8 si les caractères sont essentiellement nos bons vieux caractères occidentaux (en effet les caractères "éêèàùç«»" pour les plus courants sont codés sur un octet en iso-8859-1 et en deux octets en utf-8... mais bon ce sont des économies de bouts de chandelle... Comme le dit Sylvain, il faut aussi vérifier lors de l'upload des fichiers que le ftp est en mode binaire, le mode ascii pouvant réserver quelques surprises avec des fichiers en utf-8...
  2. ElMoustiko, je n'ai pas dit qu'il n'y a pas de 'é' dans UTF-8, j'ai dit qu'il était encodé différemment. (j'ai aussi dit voir article sur openweb) Pour Apache, la vérité est du côté de AddCharset et surtout AddDefaultCharset. Pour l'iso vs utf-8, je ne comprend pas trop comment on peut parler de précision, disons juste que l'utf-8 est plus complet, permet de représenter davantage de caractères que l'iso-8859-1 ou -15, qui eux ne permettent d'en représenter que 256.
  3. Les pconnect sont généralement à éviter car elles ne sont pas forcément fermées à la fin du script comme cela se passe pour mysql_connect. De plus je n'ai jamais été en présence d'un cas nécessitant leur emploi. Pourquoi les utilises-tu plutôt que leur homologue non-permanente.
  4. Le but de définir un jeu de caractères est justement de ne pas avoir besoin de se limiter à l'US-ASCII (ce que tu fais implicitement en utilisant toutes les entités comme é par exemple). Si tu définis ton jeu de caractère de document comme étant iso-8859-1, tu pourras utiliser "telles quelles" les caractères définis dans cet encodage, et tu devras utiliser des entités pour les autres (par exemple les caractères japonais) Si ton autre déclaration est par exemple l'UTF-8, c'est normal que tu aies des petits carrés, car le code du "é" en iso-8859-1, par exemple, ne correspond à rien en UTF-8 (c'est en fait tout simplement invalide). Par contre si tu enregistres ta page en utilisant l'encodage UTF-8 mais que tu l'envoies comme étant du ISO-8859-1, tu auras alors d'autres caractères (les célèbres û par exemple). Voir openweb pour plus d'explications (notamment les exemples de codage binaires d'un caractère en iso-8859-1 et en utf-8) Quant à l'en-tête, je n'ai pas trop compris ta question, mais il est possible que Apache envoie une en-tête par défaut si tu n'en envoies pas. Sinon il est conseillé, voire nécessaire, de spécifier soi-même une en-tête Content-Type, soit via Apache et htaccess si les pages sont statiques, soit via la directive php header() si les pages sont dynamiques.
  5. Pour les valeurs possibles de http-equiv, ce n'est pas dans les spécifications HTML qu'il faut les chercher, mais bien dans la RFC HTTP, puisque "meta http-equiv" a pour but de fournir un équivalent à un en-tête HTTP. En l'occurrence, l'en-tête "charset" n'existe effectivement pas, il faut utiliser "Content-type". Attention aussi à la BOM, car il semblerait qu'elle soit plus sujet à problèmes dans le cas d'internet (surtout avec les documents dynamique, qui, à force d'includes, se retrouvent rapidement avec une demi-douzaine de BOMs... ce qui est tout à fait incorrect. Il est probable aussi que google ne lise pas les en-têtes http mais juste le http-equiv...
  6. Courage, ElMoustiko, vous pouvez arriver à faire de grandes choses avec votre projet... Puis si ça peut te consoler, il semblerait qu'il y ait eu pire que vous depuis
  7. Ah non, une balise <meta> n'a rien à faire dans un fichier XML RSS, tu dois envoyer le pragma: via la fonction header() header('Pragma: no-cache'); (ou alors j'ai pas tout compris, c'est possible aussi) Pour les inconvénients, en fait il n'y en a pas vraiment dans la mesure où les pages en php ne sont normalement pas mises en cache. Sinon par rapport à une solution dans laquelle tu gères le cache http, tu utiliseras davantage de bande passante, et l'affichage des pages sera plus lent à la deuxième vision (vu que la page sera rechargée) Pour le truc dans dotclear, c'est juste pour désactiver une ancienne feature de IE, à savoir les Smart Tags, mais je ne sais pas si c'est vraiment utile de nos jours...
  8. Euh sans vouloir te froisser, perso je trouve que c'est plus facile de retenir "dans le sens des aiguilles d'une montre en commençant à midi" que ton moyen mnémotechnique
  9. Nudrema

    Installer Linux

    euh y'a des distribs linux sur les ftp de skynet.be, pourtant leur modem (la "raie" usb alcatel) est une horreur à installer sous linux
  10. Je crois savoir qu'il existe des plugins de validation css ou html pour le logiciel HtmlKit, pour peu que tu sois sous Windows évidemment. Voir http://www.chami.com/html-kit/plugins/info/htmltidybeta/ par exemple. Sinon il existe diverses implémentation de Tidy, que tu peux utiliser pour valider un document.
  11. C'est une erreur classique : tu as certainement oublié d'"échapper" les URLs de ta page. En fait tu dois remplacer les & par des &, y compris dans les URLs, car le & est un caractère spécial utilisé pour marquer le commencement d'une entité. Le validateur cherche donc une entité, n'en trouve pas (pas de et signale donc l'erreur. Si la régie ne permet pas que tu modifies la source qu'elle met à disposition... point de salut, j'en ai bien peur... Sinon, remplace les & par des & et tout rentrera dans l'ordre.
  12. PHP indique par défaut une date de modification qui est celle à laquelle le fichier est généré (donc maintenant). Mais le fait d'indiquer une date dans le passé n'aura aucun effet sur le cache, car pour celui-ci le navigateur envoie une requête à laquelle on devrait, pour utiliser le cache, répondre un code 304 et ne pas fournir de contenu (car celui-ci n'a pas changé). Il y a alors un gain de bande passante et ce genre de choses qui en découlent. Voir http://blog.dreams4net.com/CachezMoiCa Je pense aussi que le Pragma et le Cache-Control devraient régler ton problème.
  13. Ou alors, tu peux mettre une condition sur le Rewrite (qui devrait avoir sensiblement le même effet que la solution de Dan) : RewriteCond %{REQUEST_URI} !.php3$ RewriteRule ^([a-z0-9]+)\.php3$ index.php?page=$1 [NC][L]
  14. En fait, en XML (ou en XHTML envoyé comme XML), l'élément racine n'est plus l'élément body, mais l'élément html. Ça signifie que l'élément body se comporte en fait comme n'importe quelle div. Il faut donc appliquer la couleur ou l'image de fond sur l'élément html pour être sûr qu'elle aille jusqu'en bas. Souvent, pour une question de compatibilité avec IE et text/html, on remplace alors le style de ce genre : body { background-color: lightblue; } par : html, body { background-color: lightblue; }
  15. Quand il y a trois mesures, c'est que les deux marges horizontales sont égales : margin: 1em 2em 3em margin-top: 1em; margin-left: 2em; margin-right: 2em; margin-bottom: 2em; L'ordre est pareil pour padding, border-color, border-style, etc...
×
×
  • Créer...