Caractères grec utf-8 non visible en local sur Mozilla avec EasyPHP
11 réponses
Dominique Ottello
Bonjour,
Windows XP Home
Easy PHP (Apache 1.3.27 - PHP 4.3.3)
Mozilla 1.6 Fr en navigateur par défaut
Toutes les pages de mon site http://aviatechno.free.fr sont passées par
le validateur w3c en HTLM 4.01 strict et CSS.
La presque totalité déclarent un codage :
<META http-equiv="content-type" content="text/html; charset=iso-8859-1">
et quelques unes :
<META http-equiv="content-type" content="text/html; charset=utf-8">
Une de celles-ci, en codage utf-8, par exemple :
Les unités, Alphabet grec, accessible directement par l'url :
http://aviatechno.free.fr/unites/alphagrec.php
est parfaitement visualisée, avec les caractères grec sous Mozilla 1.6
Fr, Opera 7.23 et Internet Explorer 6.
Suivant le codage des pages, Mozilla change bien d'affichage
(Affichage, jeu de caractères) en fonction du contenu des balises.
Mais, en visualisation locale, via EasyPHP, à la place des caractères
grec, je ne vois qu'un infâme gribouillage et Mozilla ne change pas
automatiquement de codage (Affichage, Jeu de caractères).
Préambule : les fichiers de mon site local et de mon site réel sont
absolument identiques.
J'ai, sous les yeux, Mozilla d'ouvert avec deux onglets :
- 1er en local sur mon site via EasyPHP et Apache
- 2e en distant sur mon site réel http://aviatechno.free.fr
Et bien, la page locale avec balise meta utf-8 ne fait pas changer le
codage de Mozilla qui reste sur ISO-8859-1 alors que la même page réelle
fait passer l'onglet Mozilla en UTF-80
Aurais-je oublié un paramètre dans php.ini ? où dans Apache ? ou alors
simplement dans Mozilla ?
--
= Dominique Ottello = http://www.ottello.net
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
Aurais-je oublié un paramètre dans php.ini ? où dans Apache ? ou alors simplement dans Mozilla ?
C'est du côté de PHP. Par défaut, PHP envoie en ISO-8859-1.
Donc en php, fais header('Content-Type: text/html; charset=UTF-8'); au début de tes scripts en UTF-8.
Car le charset peut être déclaré de 2 façons : par le meta ou dans les entêtes HTTP. Et c'est al 2eme solution qui est prioritaire :
http://www.w3.org/TR/html401/charset.html#h-5.2.2
TOUJOURS indiquer le bon codage dans les entêtes HTTP...
Dominique Ottello
"Pierre Goiffon" écrivait :
http://www.w3.org/TR/html401/charset.html#h-5.2.2
TOUJOURS indiquer le bon codage dans les entêtes HTTP...
Merci. C'était bien ça, il fallait que je surpasse le codage par défaut envoyé dans les entêtes HTTP. -- = Dominique Ottello = http://www.ottello.net Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant
"Pierre Goiffon" <pgoiffon@fr.invalid> écrivait :
http://www.w3.org/TR/html401/charset.html#h-5.2.2
TOUJOURS indiquer le bon codage dans les entêtes HTTP...
Merci.
C'était bien ça, il fallait que je surpasse le codage par défaut envoyé
dans les entêtes HTTP.
--
= Dominique Ottello = http://www.ottello.net
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
TOUJOURS indiquer le bon codage dans les entêtes HTTP...
Merci. C'était bien ça, il fallait que je surpasse le codage par défaut envoyé dans les entêtes HTTP. -- = Dominique Ottello = http://www.ottello.net Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant
Dominique Ottello
Dominique Ottello écrivait :
"Pierre Goiffon" écrivait :
> http://www.w3.org/TR/html401/charset.html#h-5.2.2 > > TOUJOURS indiquer le bon codage dans les entêtes HTTP...
Merci. C'était bien ça, il fallait que je surpasse le codage par défaut envoyé dans les entêtes HTTP.
Bonjour,
Si tout semble bien se passer tant en local qu'en distant, il y a quand même un problème de validation par le w3c, problème que l'on peut voir en regardant le source d'une page dont le header contient un charset=utf-8 et qui donne l'erreur suivante :
<br /> <b>Warning</b>: Cannot modify header information - headers already sent by (output started at /var/www/free.fr/3/4/aviatechno/unites/alphagrec.php:1) in <b>/var/www/free.fr/3/4/aviatechno/inc/entete.php</b> on line <b>2</b><br />
Cela n'a lieu QUE pour les header avec charset utf-8 et pas pour le charset iso-8859-1, alors que TOUTES les entêtes de mes pages sont identiques, à l'exception du charset et du title :
Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et unique fois dans le fichier entete.php.
Donc, je ne comprends absolument pas d'où peut provenir cette erreur.
Auriez-vous quelque voie de recherche ?
Merci. -- = Dominique Ottello = http://www.ottello.net Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant
> http://www.w3.org/TR/html401/charset.html#h-5.2.2
>
> TOUJOURS indiquer le bon codage dans les entêtes HTTP...
Merci.
C'était bien ça, il fallait que je surpasse le codage par défaut envoyé
dans les entêtes HTTP.
Bonjour,
Si tout semble bien se passer tant en local qu'en distant, il y a quand
même un problème de validation par le w3c, problème que l'on peut voir
en regardant le source d'une page dont le header contient un
charset=utf-8 et qui donne l'erreur suivante :
<br />
<b>Warning</b>:
Cannot modify header information - headers already sent by (output
started at /var/www/free.fr/3/4/aviatechno/unites/alphagrec.php:1) in
<b>/var/www/free.fr/3/4/aviatechno/inc/entete.php</b> on line
<b>2</b><br />
Cela n'a lieu QUE pour les header avec charset utf-8 et pas pour le
charset iso-8859-1, alors que TOUTES les entêtes de mes pages sont
identiques, à l'exception du charset et du title :
Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et
unique fois dans le fichier entete.php.
Donc, je ne comprends absolument pas d'où peut provenir cette erreur.
Auriez-vous quelque voie de recherche ?
Merci.
--
= Dominique Ottello = http://www.ottello.net
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
> http://www.w3.org/TR/html401/charset.html#h-5.2.2 > > TOUJOURS indiquer le bon codage dans les entêtes HTTP...
Merci. C'était bien ça, il fallait que je surpasse le codage par défaut envoyé dans les entêtes HTTP.
Bonjour,
Si tout semble bien se passer tant en local qu'en distant, il y a quand même un problème de validation par le w3c, problème que l'on peut voir en regardant le source d'une page dont le header contient un charset=utf-8 et qui donne l'erreur suivante :
<br /> <b>Warning</b>: Cannot modify header information - headers already sent by (output started at /var/www/free.fr/3/4/aviatechno/unites/alphagrec.php:1) in <b>/var/www/free.fr/3/4/aviatechno/inc/entete.php</b> on line <b>2</b><br />
Cela n'a lieu QUE pour les header avec charset utf-8 et pas pour le charset iso-8859-1, alors que TOUTES les entêtes de mes pages sont identiques, à l'exception du charset et du title :
Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et unique fois dans le fichier entete.php.
Donc, je ne comprends absolument pas d'où peut provenir cette erreur.
Auriez-vous quelque voie de recherche ?
Merci. -- = Dominique Ottello = http://www.ottello.net Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant
Thibaut Allender
on 28/07/2004 16:34, Dominique Ottello wrote :
Si tout semble bien se passer tant en local qu'en distant, il y a quand même un problème de validation par le w3c, problème que l'on peut voir en regardant le source d'une page dont le header contient un charset=utf-8 et qui donne l'erreur suivante :
<br /> <b>Warning</b>: Cannot modify header information - headers already sent by (output started at /var/www/free.fr/3/4/aviatechno/unites/alphagrec.php:1) in <b>/var/www/free.fr/3/4/aviatechno/inc/entete.php</b> on line <b>2</b><br />
moi je vois cette erreur directement en allant sur http://aviatechno.free.fr/unites/alphagrec.php
Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et unique fois dans le fichier entete.php.
Donc, je ne comprends absolument pas d'où peut provenir cette erreur. Auriez-vous quelque voie de recherche ?
il y a un retour chariot qui doit trainer avant les variables dans cette page
es-tu certain qu'il n'y a absolument *rien* avant ceci :
Si tout semble bien se passer tant en local qu'en distant, il y a quand
même un problème de validation par le w3c, problème que l'on peut voir
en regardant le source d'une page dont le header contient un
charset=utf-8 et qui donne l'erreur suivante :
<br />
<b>Warning</b>:
Cannot modify header information - headers already sent by (output
started at /var/www/free.fr/3/4/aviatechno/unites/alphagrec.php:1) in
<b>/var/www/free.fr/3/4/aviatechno/inc/entete.php</b> on line
<b>2</b><br />
moi je vois cette erreur directement en allant sur
http://aviatechno.free.fr/unites/alphagrec.php
Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et
unique fois dans le fichier entete.php.
Donc, je ne comprends absolument pas d'où peut provenir cette erreur.
Auriez-vous quelque voie de recherche ?
il y a un retour chariot qui doit trainer avant les variables dans cette
page
es-tu certain qu'il n'y a absolument *rien* avant ceci :
Si tout semble bien se passer tant en local qu'en distant, il y a quand même un problème de validation par le w3c, problème que l'on peut voir en regardant le source d'une page dont le header contient un charset=utf-8 et qui donne l'erreur suivante :
<br /> <b>Warning</b>: Cannot modify header information - headers already sent by (output started at /var/www/free.fr/3/4/aviatechno/unites/alphagrec.php:1) in <b>/var/www/free.fr/3/4/aviatechno/inc/entete.php</b> on line <b>2</b><br />
moi je vois cette erreur directement en allant sur http://aviatechno.free.fr/unites/alphagrec.php
Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et unique fois dans le fichier entete.php.
Donc, je ne comprends absolument pas d'où peut provenir cette erreur. Auriez-vous quelque voie de recherche ?
il y a un retour chariot qui doit trainer avant les variables dans cette page
es-tu certain qu'il n'y a absolument *rien* avant ceci :
moi je vois cette erreur directement en allant sur http://aviatechno.free.fr/unites/alphagrec.php
> Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et > unique fois dans le fichier entete.php. > > Donc, je ne comprends absolument pas d'où peut provenir cette erreur. > Auriez-vous quelque voie de recherche ?
il y a un retour chariot qui doit trainer avant les variables dans cette page
es-tu certain qu'il n'y a absolument *rien* avant ceci :
Je vais re-re-re-vérifier, mais je suis sûr que non.
Quelques temps après.....
Trouvé !
C'est là que le mode hexadécimal d'UltraEdit est vraiment utile.
Le fichier contenant l'entête sus-mentionnée et déclarant un charset=utf-8 est un fichier qui, bien sûr, pour supporter ce type de codage est écrit en unicode, donc avec des caractères codés sur 16 bits.
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa : 3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00 3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
J'ai donc séparé mes fichiers codés unicode en deux parties : Une partie entête codée en ascii 8bits et appelant en include la deuxième partie qui, elle, est bien codée en unicode.
Et c'est là que les conversions de transcodage incluses dans UltraEdit font merveille.
Les deux fichiers incriminés : alphabet grec et unités mécaniques viennent d'être scindés en deux parties (transparent pour l'utilisateur) et ne donnent plus d'erreur.
CQFD et merci à UltraEdit.
-- = Dominique Ottello = http://www.ottello.net Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant
moi je vois cette erreur directement en allant sur
http://aviatechno.free.fr/unites/alphagrec.php
> Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et
> unique fois dans le fichier entete.php.
>
> Donc, je ne comprends absolument pas d'où peut provenir cette erreur.
> Auriez-vous quelque voie de recherche ?
il y a un retour chariot qui doit trainer avant les variables dans cette
page
es-tu certain qu'il n'y a absolument *rien* avant ceci :
Je vais re-re-re-vérifier, mais je suis sûr que non.
Quelques temps après.....
Trouvé !
C'est là que le mode hexadécimal d'UltraEdit est vraiment utile.
Le fichier contenant l'entête sus-mentionnée et déclarant un
charset=utf-8 est un fichier qui, bien sûr, pour supporter ce type de
codage est écrit en unicode, donc avec des caractères codés sur 16 bits.
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa :
3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00
3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
J'ai donc séparé mes fichiers codés unicode en deux parties :
Une partie entête codée en ascii 8bits et appelant en include la
deuxième partie qui, elle, est bien codée en unicode.
Et c'est là que les conversions de transcodage incluses dans UltraEdit
font merveille.
Les deux fichiers incriminés : alphabet grec et unités mécaniques
viennent d'être scindés en deux parties (transparent pour l'utilisateur)
et ne donnent plus d'erreur.
CQFD et merci à UltraEdit.
--
= Dominique Ottello = http://www.ottello.net
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
moi je vois cette erreur directement en allant sur http://aviatechno.free.fr/unites/alphagrec.php
> Dans TOUTES mes pages l'instruction header() n'existe qu'une seule et > unique fois dans le fichier entete.php. > > Donc, je ne comprends absolument pas d'où peut provenir cette erreur. > Auriez-vous quelque voie de recherche ?
il y a un retour chariot qui doit trainer avant les variables dans cette page
es-tu certain qu'il n'y a absolument *rien* avant ceci :
Je vais re-re-re-vérifier, mais je suis sûr que non.
Quelques temps après.....
Trouvé !
C'est là que le mode hexadécimal d'UltraEdit est vraiment utile.
Le fichier contenant l'entête sus-mentionnée et déclarant un charset=utf-8 est un fichier qui, bien sûr, pour supporter ce type de codage est écrit en unicode, donc avec des caractères codés sur 16 bits.
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa : 3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00 3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
J'ai donc séparé mes fichiers codés unicode en deux parties : Une partie entête codée en ascii 8bits et appelant en include la deuxième partie qui, elle, est bien codée en unicode.
Et c'est là que les conversions de transcodage incluses dans UltraEdit font merveille.
Les deux fichiers incriminés : alphabet grec et unités mécaniques viennent d'être scindés en deux parties (transparent pour l'utilisateur) et ne donnent plus d'erreur.
CQFD et merci à UltraEdit.
-- = Dominique Ottello = http://www.ottello.net Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant
Dominique Ottello
Dominique Ottello écrivait :
Les deux fichiers incriminés : alphabet grec et unités mécaniques viennent d'être scindés en deux parties (transparent pour l'utilisateur) et ne donnent plus d'erreur.
Plus d'erreur sur les navigateurs, mais erreur sur le validateur w3c, juste à la "jointure" des deux fichiers :
Line 108, column 0: character data is not allowed here
???<div class="fl80pc">
Alors, j'ai rusé en incluant ces caractères "non autorisés ici" dans un commentaire html qui commence avant l'include codé unicode par echo "<!-- Commentaire "; et se termine au début du fichier include par -->.
Et maintenant, c'est valide HTML 4.01 Strict. -- Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi Site aéronautique :http://dominique.ottello.free.fr (Avec frames) http://aviatechno.free.fr (Sans frames et en PHP) Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Les deux fichiers incriminés : alphabet grec et unités mécaniques
viennent d'être scindés en deux parties (transparent pour l'utilisateur)
et ne donnent plus d'erreur.
Plus d'erreur sur les navigateurs, mais erreur sur le validateur w3c,
juste à la "jointure" des deux fichiers :
Line 108, column 0: character data is not allowed here
???<div class="fl80pc">
Alors, j'ai rusé en incluant ces caractères "non autorisés ici" dans un
commentaire html qui commence avant l'include codé unicode par
echo "<!-- Commentaire "; et se termine au début du fichier include par
-->.
Et maintenant, c'est valide HTML 4.01 Strict.
--
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Site aéronautique :http://dominique.ottello.free.fr (Avec frames)
http://aviatechno.free.fr (Sans frames et en PHP)
Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Les deux fichiers incriminés : alphabet grec et unités mécaniques viennent d'être scindés en deux parties (transparent pour l'utilisateur) et ne donnent plus d'erreur.
Plus d'erreur sur les navigateurs, mais erreur sur le validateur w3c, juste à la "jointure" des deux fichiers :
Line 108, column 0: character data is not allowed here
???<div class="fl80pc">
Alors, j'ai rusé en incluant ces caractères "non autorisés ici" dans un commentaire html qui commence avant l'include codé unicode par echo "<!-- Commentaire "; et se termine au début du fichier include par -->.
Et maintenant, c'est valide HTML 4.01 Strict. -- Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi Site aéronautique :http://dominique.ottello.free.fr (Avec frames) http://aviatechno.free.fr (Sans frames et en PHP) Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Pierre Goiffon
"Dominique Ottello" a écrit dans le message de news:
Le fichier contenant l'entête sus-mentionnée et déclarant un charset=utf-8 est un fichier qui, bien sûr, pour supporter ce type de codage est écrit en unicode, donc avec des caractères codés sur 16 bits.
Non, on ne code pas un fichier en Unicode. On utilise UTF-8, UTF-16 ou autre... Il y a différence entre character set et encoding scheme en Unicode.
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa : 3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00 3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
J'ai donc séparé mes fichiers codés unicode en deux parties : Une partie entête codée en ascii 8bits et appelant en include la deuxième partie qui, elle, est bien codée en unicode.
Si c'est de l'us-ascii, et donc le jeux de caractères 7 bits universel, alors pas de prb pour l'UTF-8.
"Dominique Ottello" <air.intakes@fra.fr.invalid> a écrit dans le
message de news:39hfg0psfkh9viap2hrle2vqi0khpohtdp@4ax.com
Le fichier contenant l'entête sus-mentionnée et déclarant un
charset=utf-8 est un fichier qui, bien sûr, pour supporter ce type de
codage est écrit en unicode, donc avec des caractères codés sur 16
bits.
Non, on ne code pas un fichier en Unicode. On utilise UTF-8, UTF-16 ou
autre... Il y a différence entre character set et encoding scheme en
Unicode.
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa :
3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00
3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si
vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
J'ai donc séparé mes fichiers codés unicode en deux parties :
Une partie entête codée en ascii 8bits et appelant en include la
deuxième partie qui, elle, est bien codée en unicode.
Si c'est de l'us-ascii, et donc le jeux de caractères 7 bits universel,
alors pas de prb pour l'UTF-8.
"Dominique Ottello" a écrit dans le message de news:
Le fichier contenant l'entête sus-mentionnée et déclarant un charset=utf-8 est un fichier qui, bien sûr, pour supporter ce type de codage est écrit en unicode, donc avec des caractères codés sur 16 bits.
Non, on ne code pas un fichier en Unicode. On utilise UTF-8, UTF-16 ou autre... Il y a différence entre character set et encoding scheme en Unicode.
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa : 3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00 3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
J'ai donc séparé mes fichiers codés unicode en deux parties : Une partie entête codée en ascii 8bits et appelant en include la deuxième partie qui, elle, est bien codée en unicode.
Si c'est de l'us-ascii, et donc le jeux de caractères 7 bits universel, alors pas de prb pour l'UTF-8.
Marc Mongenet
Pierre Goiffon wrote:
"Dominique Ottello" a écrit dans le message de news:
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa : 3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00 3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
Manifestement en UTF-16 puisqu'il y a 16 bits par caractère.
Marc Mongenet
Pierre Goiffon wrote:
"Dominique Ottello" <air.intakes@fra.fr.invalid> a écrit dans le
message de news:39hfg0psfkh9viap2hrle2vqi0khpohtdp@4ax.com
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa :
3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00
3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si
vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
Manifestement en UTF-16 puisqu'il y a 16 bits par caractère.
"Dominique Ottello" a écrit dans le message de news:
Un fichier "normal", codé 8 bits ascii commence par <? soit, en hexa : 3C 3F et, le même fichier mais codé unicode commence par : FFFE 3C00 3F00 ; il y a donc bien deux octets qui sont envoyés avant <?php.
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
Manifestement en UTF-16 puisqu'il y a 16 bits par caractère.
Marc Mongenet
Dominique Ottello
"Pierre Goiffon" écrivait :
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
C'est bien un BOM (Byte order Mark).
> J'ai donc séparé mes fichiers codés unicode en deux parties : > Une partie entête codée en ascii 8bits et appelant en include la > deuxième partie qui, elle, est bien codée en unicode.
Si c'est de l'us-ascii, et donc le jeux de caractères 7 bits universel, alors pas de prb pour l'UTF-8.
En fin de compte, tous en archivant les fichiers Unicode (on ne sait jamais ...), j'ai recodé en 8 bits, remis un charset iso-8859-1 et déclaré tous les caractères "litigieux" sous forme de chaîne ampersand : &Apha; Β, Γ Δ .... Ω...
Cela semble fonctionner correctement, tout du moins sur ma machine Windows XP Home, avec Mozilla 1.6 fr, Opera 7.23 et IE6, tant en local qu'en distant.
Si le coeur vous en dis, merci de vérifier, par exemple sur : http://aviatechno.free.fr/unites/alphagrec.php
-- = Dominique Ottello = http://www.ottello.net Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si
vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
C'est bien un BOM (Byte order Mark).
> J'ai donc séparé mes fichiers codés unicode en deux parties :
> Une partie entête codée en ascii 8bits et appelant en include la
> deuxième partie qui, elle, est bien codée en unicode.
Si c'est de l'us-ascii, et donc le jeux de caractères 7 bits universel,
alors pas de prb pour l'UTF-8.
En fin de compte, tous en archivant les fichiers Unicode (on ne sait
jamais ...), j'ai recodé en 8 bits, remis un charset iso-8859-1 et
déclaré tous les caractères "litigieux" sous forme de chaîne ampersand :
&Apha; Β, Γ Δ .... Ω...
Cela semble fonctionner correctement, tout du moins sur ma machine
Windows XP Home, avec Mozilla 1.6 fr, Opera 7.23 et IE6, tant en local
qu'en distant.
Si le coeur vous en dis, merci de vérifier, par exemple sur :
http://aviatechno.free.fr/unites/alphagrec.php
--
= Dominique Ottello = http://www.ottello.net
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
Ca ressemble à un BOM. Si vous êtes en UTF-8, vous pouvez le supprimer... Si vous êtes en UTF-16... Utilisez plutôt UTF-8 :)
C'est bien un BOM (Byte order Mark).
> J'ai donc séparé mes fichiers codés unicode en deux parties : > Une partie entête codée en ascii 8bits et appelant en include la > deuxième partie qui, elle, est bien codée en unicode.
Si c'est de l'us-ascii, et donc le jeux de caractères 7 bits universel, alors pas de prb pour l'UTF-8.
En fin de compte, tous en archivant les fichiers Unicode (on ne sait jamais ...), j'ai recodé en 8 bits, remis un charset iso-8859-1 et déclaré tous les caractères "litigieux" sous forme de chaîne ampersand : &Apha; Β, Γ Δ .... Ω...
Cela semble fonctionner correctement, tout du moins sur ma machine Windows XP Home, avec Mozilla 1.6 fr, Opera 7.23 et IE6, tant en local qu'en distant.
Si le coeur vous en dis, merci de vérifier, par exemple sur : http://aviatechno.free.fr/unites/alphagrec.php
-- = Dominique Ottello = http://www.ottello.net Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant
