Aller au contenu

Nudrema

Webmaster Régulier
  • Compteur de contenus

    68
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Nudrema

  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...
  16. Je ne vois pas personnellement ce qu'un en-tête flash a de contraire aux normes. Il est tout à fait possible d'intégrer un objet dans un site, pour peu que l'on propose un contenu alternatif (par exemple une image fixe) pour ceux qui ne peuvent pas afficher ledit objet. La balise <object> a justement été conçue dans ce sens, ce qu'elle contient n'étant affiché que si l'objet ne l'est pas. Ma critique, peut-être un peu trop active je l'avoue, portait elle aussi sur la naïveté du discours, mais surtout sur la distance qu'il y avait entre celui-ci et l'application qui en était faite. Si le discours mûrit et si l'application qui en est faite se rapproche de celui-ci, les critiques (la mienne en premier) n'auront plus lieu d'être. C'est tout ce que j'espère. PS. Songez à mettre une adresse e-mail à disposition sur le site, ça pourra éviter bien des dérappages
  17. Non. C'est pour ça qu'on a inventé les familles génériques serif, sans-serif, monospace, etc.
  18. Attention, Apache fonctionne très bien sous Windows aussi... Et il y a moyen de faire de l'asp sous linux, via Mono (mais je pense qu'il y a quelques limitations, genre on ne peut pas utiliser de VisualBasic). Et on peut utiliser autre chose que Apache comme serveur sur une plate-forme linux ! Haro sur les amalgames foireux et les idées toute faites ! Donc typiquement, si tu as une application qui a besoin de choses spécifiques à Windows (genre générer des fichiers excell ou word via COM sous PHP) tu as besoin de Windows. Sinon, si tu veux développer sous PHP en général, tu as plus de chances de prendre linux, parce que c'est la plate-forme native et de php et de apache.
  19. Non, le PHP-CGI se fera passer le fichier par Apache, et donc il n'y a pas besoin de spécifier le chemin vers l'interpréteur. Plutôt qu'utiliser le module mod_php via la directive LoadModule, tu utiliseras le cgi via la directive Action. Voir la doc pour plus de précisions
  20. Enlever le <embed> * Xhtml et élément object * A Flash Satay
  21. Nudrema

    simplexml (Php5)

    La balise <html>, c'est simplement $racine Si tu veux la balise html, bah tu peux faire $racine['html'] = simplexml_load_file ( $fichierxml ) mais je ne suis pas sûr d'en saisir l'intérêt. Pour rappel on ne peut avoir qu'un élément racine par fichier XML...
  22. Sinon, et si le serveur et le cms le permettent (ce qui n'est pas gagné), il y a toujours moyen de passer un petit coup de tidy sur le fichier uploadé, via un petit hack du cms.
  23. Tant qu'à faire, tu peux alors faire echo('demo'.((int)date('d')+1));
  24. Monique, en XHTML, les scripts ne doivent pas être entourrés de commentaires <!-- -->. La raison en est simple : les moteurs xml sont autorisés (encourragés) à supprimer tous les commentaires sans autre forme de procès.
  25. Nudrema

    Warning ()

    A priori, tu envoies quelque chose avant le <?php (évitez le <?, les shorts-tags sont à déconseiller et ne sont pas toujours activés). Tu inclus cette page dans une autre page ? Tu utilises quel jeu de caractère ? Si tu es en UTF-8, vérifie bien que ton éditeur n'ajoute pas de BOM. Il s'agit de quelques octets qui sont ajoutés au début du fichier pour indiquer l'encodage utilisé. Et comme ils sont en début de fichier, ils sont avant le <?php, et comme PHP n'est pas conçu pour gérer cette BOM, il l'envoie comme n'importe quel contenu. Vérifie aussi que tu n'as pas d'espace et/ou de sauts de lignes avant ton <?php, dans ce fichier ainsi que dans les fichiers qui l'incluent...
×
×
  • Créer...