Je ne comprends rien au PHP
mais il m'avait bien semblé qu'il ne fallait *absolument RIEN* avant :
<?php
au début du fichier
Je ne comprends rien au PHP
mais il m'avait bien semblé qu'il ne fallait *absolument RIEN* avant :
<?php
au début du fichier
Je ne comprends rien au PHP
mais il m'avait bien semblé qu'il ne fallait *absolument RIEN* avant :
<?php
au début du fichier
Le 23/11/2012 13:58, SAM a écrit :
Je ne comprends rien au PHP
mais il m'avait bien semblé qu'il ne fallait *absolument RIEN* avant :
<?php
au début du fichier
Dans l'absolu, ce n'est pas tout à fait exact.
Le 23/11/2012 13:58, SAM a écrit :
Je ne comprends rien au PHP
mais il m'avait bien semblé qu'il ne fallait *absolument RIEN* avant :
<?php
au début du fichier
Dans l'absolu, ce n'est pas tout à fait exact.
Le 23/11/2012 13:58, SAM a écrit :
Je ne comprends rien au PHP
mais il m'avait bien semblé qu'il ne fallait *absolument RIEN* avant :
<?php
au début du fichier
Dans l'absolu, ce n'est pas tout à fait exact.
les caractères bom, je me demande s'il ne cacadent pas aussi pour la
balise doctype ?
les caractères bom, je me demande s'il ne cacadent pas aussi pour la
balise doctype ?
les caractères bom, je me demande s'il ne cacadent pas aussi pour la
balise doctype ?
Merci à tous pour ces commentaires avisés et instructifs (mais je n'ai pas tout compris...).
J'en retiens :
1. qu'il ne faut pas de BOM dans l'utf-8 pour le php et javascript associé.
2. que le javascript en fichier externalisé peut être appelé depuis body avec un doctype en xhtml si on y met //<![CDATA[ .............//]]> et que les balises <!--............... //--> elles, ne sont plus utiles.
3. que l'affichage du texte dans une page web, c'est toujours un drôle de patakess (voir comment s'affiche les posts de SAM sur mon pc ici : http://cjoint.com/?BKyosocIJ4H ) Etrange ! même en changeant l'encodage des caractères dans les options du navigateur.
Je crois avoir trouvé d'où vient le problème avec mon fichier http://scalpa.info/1.html de test:http://scalpa.info/1.html
Merci à tous pour ces commentaires avisés et instructifs (mais je n'ai pas tout compris...).
J'en retiens :
1. qu'il ne faut pas de BOM dans l'utf-8 pour le php et javascript associé.
2. que le javascript en fichier externalisé peut être appelé depuis body avec un doctype en xhtml si on y met //<![CDATA[ .............//]]> et que les balises <!--............... //--> elles, ne sont plus utiles.
3. que l'affichage du texte dans une page web, c'est toujours un drôle de patakess (voir comment s'affiche les posts de SAM sur mon pc ici : http://cjoint.com/?BKyosocIJ4H ) Etrange ! même en changeant l'encodage des caractères dans les options du navigateur.
Je crois avoir trouvé d'où vient le problème avec mon fichier http://scalpa.info/1.html de test:http://scalpa.info/1.html
Merci à tous pour ces commentaires avisés et instructifs (mais je n'ai pas tout compris...).
J'en retiens :
1. qu'il ne faut pas de BOM dans l'utf-8 pour le php et javascript associé.
2. que le javascript en fichier externalisé peut être appelé depuis body avec un doctype en xhtml si on y met //<![CDATA[ .............//]]> et que les balises <!--............... //--> elles, ne sont plus utiles.
3. que l'affichage du texte dans une page web, c'est toujours un drôle de patakess (voir comment s'affiche les posts de SAM sur mon pc ici : http://cjoint.com/?BKyosocIJ4H ) Etrange ! même en changeant l'encodage des caractères dans les options du navigateur.
Je crois avoir trouvé d'où vient le problème avec mon fichier http://scalpa.info/1.html de test:http://scalpa.info/1.html
Le 24/11/12 14:39, Pascal a écrit :Je crois avoir trouvé d'où vient le problème avec mon fichier
http://scalpa.info/1.html de test:http://scalpa.info/1.html
He Ben NON !
Je tombe sur : http://www.scalpa.info/
et Fx qui me dit :
« *La page n'est pas redirigée correctement*
Le 24/11/12 14:39, Pascal a écrit :
Je crois avoir trouvé d'où vient le problème avec mon fichier
http://scalpa.info/1.html de test:http://scalpa.info/1.html
He Ben NON !
Je tombe sur : http://www.scalpa.info/
et Fx qui me dit :
« *La page n'est pas redirigée correctement*
Le 24/11/12 14:39, Pascal a écrit :Je crois avoir trouvé d'où vient le problème avec mon fichier
http://scalpa.info/1.html de test:http://scalpa.info/1.html
He Ben NON !
Je tombe sur : http://www.scalpa.info/
et Fx qui me dit :
« *La page n'est pas redirigée correctement*
Par ce que, déjà, pour de l'utf-8 déclarer une entête BOM ne sert
strictement à rien et est totalement inutile.
C'est assez lapidaire : si l'on a besoin de mécanisme d'auto-détection
la présence du BOM (prévu et tout à fait valide dans n'importe quel des
codages Unicode : http://www.unicode.org/faq//utf_bom.html#bom4) peut
être fort utile.
La logique de l'argumentaire ne tient pas une minute.
Dans un contexte plus général où tous les codages existants (pas
uniquement ceux liés à Unicode) co-existent (le cas typique d'un
navigateur), l'auto-détection ne marche pas (il ne faut pas oublier que
les BOM Unicode peuvent être considérer comme une suite de caractères
tout à fait valides pour des codages non Unicode).
Quoi qu'il en soit, les navigateurs, même très récents, n'aiment pas du
tout du tout un JS en UTF-8 avec BOM
C'est d'autant plus normal que le BOM pourrait venir en contradiction
avec l'encodage annoncé par les meta-informations du protocole de
transport.
Par ce que, déjà, pour de l'utf-8 déclarer une entête BOM ne sert
strictement à rien et est totalement inutile.
C'est assez lapidaire : si l'on a besoin de mécanisme d'auto-détection
la présence du BOM (prévu et tout à fait valide dans n'importe quel des
codages Unicode : http://www.unicode.org/faq//utf_bom.html#bom4) peut
être fort utile.
La logique de l'argumentaire ne tient pas une minute.
Dans un contexte plus général où tous les codages existants (pas
uniquement ceux liés à Unicode) co-existent (le cas typique d'un
navigateur), l'auto-détection ne marche pas (il ne faut pas oublier que
les BOM Unicode peuvent être considérer comme une suite de caractères
tout à fait valides pour des codages non Unicode).
Quoi qu'il en soit, les navigateurs, même très récents, n'aiment pas du
tout du tout un JS en UTF-8 avec BOM
C'est d'autant plus normal que le BOM pourrait venir en contradiction
avec l'encodage annoncé par les meta-informations du protocole de
transport.
Par ce que, déjà, pour de l'utf-8 déclarer une entête BOM ne sert
strictement à rien et est totalement inutile.
C'est assez lapidaire : si l'on a besoin de mécanisme d'auto-détection
la présence du BOM (prévu et tout à fait valide dans n'importe quel des
codages Unicode : http://www.unicode.org/faq//utf_bom.html#bom4) peut
être fort utile.
La logique de l'argumentaire ne tient pas une minute.
Dans un contexte plus général où tous les codages existants (pas
uniquement ceux liés à Unicode) co-existent (le cas typique d'un
navigateur), l'auto-détection ne marche pas (il ne faut pas oublier que
les BOM Unicode peuvent être considérer comme une suite de caractères
tout à fait valides pour des codages non Unicode).
Quoi qu'il en soit, les navigateurs, même très récents, n'aiment pas du
tout du tout un JS en UTF-8 avec BOM
C'est d'autant plus normal que le BOM pourrait venir en contradiction
avec l'encodage annoncé par les meta-informations du protocole de
transport.
Comme le dis Olivier dans sa réponse, sur des contenus avec uniquement
des scripts latins on peut arriver à se débrouiller sans BOM. Vous le
dites aussi, un BOM peut être une séquence valide.
Mais considérez les probabilités d'un faux positif, si vous avez une
suite logique d'octets qui parait un bon contenu UTF-8 en latin ET que
vous avez un BOM en tête de flux !
J'ai de mon côté travaillé avec des portages de la librairie Rhino de
Mozilla, et l'analyse d'un BOM éventuel avant passage par Rhino permet
d'augmenter considérablement les bons résultats.
je ne comprend pas bien votre argument ? Si le fichier est servit avec
une information de charset dans l'entête http différent du codage réel
du fichier, qu'il y ait bom ou pas ça ne changera pas grand chose
n'est-ce pas ? Au contraire, le navigateur pourrait utiliser le bom pour
se douter que quelque chose ne va pas... (il me semble avoir vu quelque
chose comme ça sur mozilla suite à l'époque, pour lire une page en
utf-16 même si elle est servit avec un codage iso latin-1).
Comme le dis Olivier dans sa réponse, sur des contenus avec uniquement
des scripts latins on peut arriver à se débrouiller sans BOM. Vous le
dites aussi, un BOM peut être une séquence valide.
Mais considérez les probabilités d'un faux positif, si vous avez une
suite logique d'octets qui parait un bon contenu UTF-8 en latin ET que
vous avez un BOM en tête de flux !
J'ai de mon côté travaillé avec des portages de la librairie Rhino de
Mozilla, et l'analyse d'un BOM éventuel avant passage par Rhino permet
d'augmenter considérablement les bons résultats.
je ne comprend pas bien votre argument ? Si le fichier est servit avec
une information de charset dans l'entête http différent du codage réel
du fichier, qu'il y ait bom ou pas ça ne changera pas grand chose
n'est-ce pas ? Au contraire, le navigateur pourrait utiliser le bom pour
se douter que quelque chose ne va pas... (il me semble avoir vu quelque
chose comme ça sur mozilla suite à l'époque, pour lire une page en
utf-16 même si elle est servit avec un codage iso latin-1).
Comme le dis Olivier dans sa réponse, sur des contenus avec uniquement
des scripts latins on peut arriver à se débrouiller sans BOM. Vous le
dites aussi, un BOM peut être une séquence valide.
Mais considérez les probabilités d'un faux positif, si vous avez une
suite logique d'octets qui parait un bon contenu UTF-8 en latin ET que
vous avez un BOM en tête de flux !
J'ai de mon côté travaillé avec des portages de la librairie Rhino de
Mozilla, et l'analyse d'un BOM éventuel avant passage par Rhino permet
d'augmenter considérablement les bons résultats.
je ne comprend pas bien votre argument ? Si le fichier est servit avec
une information de charset dans l'entête http différent du codage réel
du fichier, qu'il y ait bom ou pas ça ne changera pas grand chose
n'est-ce pas ? Au contraire, le navigateur pourrait utiliser le bom pour
se douter que quelque chose ne va pas... (il me semble avoir vu quelque
chose comme ça sur mozilla suite à l'époque, pour lire une page en
utf-16 même si elle est servit avec un codage iso latin-1).
Vous ne vous placez pas du même côté de la barrière.
Vous ne vous placez pas du même côté de la barrière.
Vous ne vous placez pas du même côté de la barrière.