Bonjour,
Un quizz comprend trois fichiers: questions.php, liste données.txt,
corrige.php
une question contient un numero, l'adresse d'une image, son vrai nom, et
deux faux noms soit 5 données dans une ligne d'enregistrement (les 3
noms seront affichés ds un ordre différent ), lignes numérotées de 1 à
XX dans un fichier texte (facile à compléter)
le programme "question" va donc chercher une ligne d'enregistrement dans
un ordre aléatoire et affiche l'image et les trois propositions....
mais je me suis aperçu que les données contenant (sans doute) un
caractère accentué n'étaient pas affichées.
( http://autourdalos.fr/html/quizz1q.php?Fnm=fleurs_septembre.txt )
J'ai vérifié la correspondance des encodages, tant dans le fichier
question que dans le fichier txt (en 8859-1 avec notepad) mais je
n'obtiens rien. (pareil pour le corrigé ... et pour les autres mois)
Un coup de main serait le bienvenu !! Merci à l'avance
Alain
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Voici qqs morceaux du code de la page question.php
=================================================================
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
for ($i=1;$i<$nb;$i++) {
#Lire quelques caractères s'arrête avant s'il rencontre \n ou la fin du
fichier !
$ligne[$i] = fgets($inF, 4096);
$donneesligne=explode(';',$ligne[$i]);
$numligne[$i]=$donneesligne[0];
# si rencontre la ligne choisie , indice(1 à 10 ) les 4 données
# $imgligne[1] : image pour la 1ère question, $nvligne: bonne reponse,
$nf et $nff: mauvaises réponses
if ($numligne[$i]==$origine){
$imgligne1=$donneesligne[1];
$nvligne1=htmlspecialchars($donneesligne[2], ENT_QUOTES);
$nfligne1=htmlspecialchars($donneesligne[3], ENT_QUOTES);
$nffligne1=htmlspecialchars($donneesligne[4], ENT_QUOTES);
}
else if ($numligne[$i]==$origine+$ajout){
$imgligne2=$donneesligne[1];
$nvligne2=htmlspecialchars($donneesligne[2], ENT_QUOTES);
$nfligne2=htmlspecialchars($donneesligne[3], ENT_QUOTES);
$nffligne2=htmlspecialchars($donneesligne[4], ENT_QUOTES);
}
............................................
Pour le passage à UTF-8, l'idéal est de tout convertir avec notepad++ comme suggéré.
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas UFT-8 tout court.
Un autre truc à savoir : le serveur et la copie locale ne sont pas identiques pour ce qui est de la gestion des accents. En d'autres mots, cela peut marcher comme il faut sur son ordi et pas sur le serveur. Donc, relire toutes les pages.
Cette vérification est utile, mais une fois les problèmes d'encodage résolus, tant dans l'affichage du site (je renouvelle au passage le conseil de passer en HTML5/CSS3, plus à la page, plus simples que 4.x et offrant plus de possibilités) que dans les fonctions PHP, ça devrait rouler.
Pour le passage à UTF-8, l'idéal est de tout convertir avec
notepad++ comme suggéré.
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté
de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut
choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas
UFT-8 tout court.
Un autre truc à savoir : le serveur et la copie locale ne sont
pas identiques pour ce qui est de la gestion des accents. En
d'autres mots, cela peut marcher comme il faut sur son ordi et
pas sur le serveur. Donc, relire toutes les pages.
Cette vérification est utile, mais une fois les problèmes d'encodage
résolus, tant dans l'affichage du site (je renouvelle au passage le
conseil de passer en HTML5/CSS3, plus à la page, plus simples que 4.x et
offrant plus de possibilités) que dans les fonctions PHP, ça devrait
rouler.
Pour le passage à UTF-8, l'idéal est de tout convertir avec notepad++ comme suggéré.
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas UFT-8 tout court.
Un autre truc à savoir : le serveur et la copie locale ne sont pas identiques pour ce qui est de la gestion des accents. En d'autres mots, cela peut marcher comme il faut sur son ordi et pas sur le serveur. Donc, relire toutes les pages.
Cette vérification est utile, mais une fois les problèmes d'encodage résolus, tant dans l'affichage du site (je renouvelle au passage le conseil de passer en HTML5/CSS3, plus à la page, plus simples que 4.x et offrant plus de possibilités) que dans les fonctions PHP, ça devrait rouler.
Otomatic
Eric Demeester écrivait :
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas UFT-8 tout court.
Parce que cette entête BOM ajoute des caractères « parasites » sur une ou plusieurs pages HTML (générées par PHP), comme “” ou, la génération des pages donne une erreur du style Warning: Cannot modify header information - headers already sent by …
Il y a une très grande probabilité pour qu'un ou plusieurs de vos fichiers ait été sauvegardé avec une entête BOM, en anglais Byte Order Mark, qui est - théoriquement - utilisée comme marqueur pour indiquer que le texte est codé en UTF-8, UTF-16 ou UTF-32 et dans quel ordre sont les octets d'un caractère UTF-16 ou UTF-32.
Pour UTF-16, le BOM est une séquence de deux octets FE FF au début de la chaîne codée, pour indiquer que les caractères codés suivants utilisent l'ordre poids fort en dernier (big-endian) ; ou FF FE pour indiquer l'ordre poids faible en dernier (little-endian). Alors qu'UTF-8 n'a aucun problème d'ordre des octets, un BOM codé en UTF-8 peut être mis pour identifier un fichier comme UTF-8, mais ce n'est pas recommandé puisque ce BOM ne sert à rien, l'ordre des octets étant fixe en UTF-8.
Si on utilise un éditeur de texte (ou autre logiciel éditeur hexadécimal) qui permet de voir le fichier sous forme hexadécimale, c'est à dire avec une suite d'octets qui en représente le contenu, on peut voir si il y a des caractères supplémentaires (BOM) au début du fichier.
Par exemple, en vue héxadécimale, le début d'un fichier.php normal est :
On voit bien que trois octets sont insérés au début du fichier : EF BB BF, c'est l'entête BOM. La plupart du temps, ces trois octets sont vus comme caractères : “” dans la fenêtre du navigateur ce qui permet de déterminer qu'il s'agit bien d'une entête BOM.
Il faut toujours vérifier, lorsque l'on sauvegarde un fichier modifié, que le logiciel donne une option “Sans BOM” ou que celle-ci fait partie des Réglages ou Préférences du logiciel.
Lorsque l'on édite/modifie un fichier, bien faire attention aux options ou préférences dudit logiciel :
Pas de transcodage automatique Le fichier sauvegardé doit garder son codage d'origine, par exemple pas de transcodage automatique ASCII -> UTF8 Pas d'ajout d'entête BOM si celle-ci n'existait pas
Faire aussi attention aux logiciels de téléchargement et de transfert de fichiers (FTP) qui ne doivent, en aucune manière, modifier quoi que ce soit.
Beaucoup de logiciels Windows (incluant Notepad) ajoutent un BOM aux fichiers UTF-8 si on n'y prend pas garde. C'est pourquoi il est recommandé d'utiliser Notepad++ (Gratuit : http://notepad-plus.sourceforge.net/fr/site.htm) qui indique, en bas de page, dans la barre d'état, diverses informations dont le codage du fichier :
ANSI ANSI as UTF-8 (C'est la version UTF-8 sans BOM) UTF-8 (C'est la version UTF-8 avec BOM) etc.
et qui permet, via le menu Encodage, de convertir d'un codage vers un autre.
Ainsi, si on se retrouve, sans le vouloir, avec les caractères “”, il suffit d'ouvrir, avec Notepad++ le fichier incriminé, de changer le codage via le menu Encodage . -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont forcément raison. Coluche
Eric Demeester <eric.REMOVETHIS@mailody.org> écrivait :
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté
de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut
choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas
UFT-8 tout court.
Parce que cette entête BOM ajoute des caractères « parasites » sur une
ou plusieurs pages HTML (générées par PHP), comme “” ou, la
génération des pages donne une erreur du style Warning: Cannot modify
header information - headers already sent by …
Il y a une très grande probabilité pour qu'un ou plusieurs de vos
fichiers ait été sauvegardé avec une entête BOM, en anglais Byte Order
Mark, qui est - théoriquement - utilisée comme marqueur pour indiquer
que le texte est codé en UTF-8, UTF-16 ou UTF-32 et dans quel ordre sont
les octets d'un caractère UTF-16 ou UTF-32.
Pour UTF-16, le BOM est une séquence de deux octets FE FF au début de la
chaîne codée, pour indiquer que les caractères codés suivants utilisent
l'ordre poids fort en dernier (big-endian) ; ou FF FE pour indiquer
l'ordre poids faible en dernier (little-endian). Alors qu'UTF-8 n'a
aucun problème d'ordre des octets, un BOM codé en UTF-8 peut être mis
pour identifier un fichier comme UTF-8, mais ce n'est pas recommandé
puisque ce BOM ne sert à rien, l'ordre des octets étant fixe en UTF-8.
Si on utilise un éditeur de texte (ou autre logiciel éditeur
hexadécimal) qui permet de voir le fichier sous forme hexadécimale,
c'est à dire avec une suite d'octets qui en représente le contenu, on
peut voir si il y a des caractères supplémentaires (BOM) au début du
fichier.
Par exemple, en vue héxadécimale, le début d'un fichier.php normal est :
On voit bien que trois octets sont insérés au début du fichier : EF BB
BF, c'est l'entête BOM. La plupart du temps, ces trois octets sont vus
comme caractères : “” dans la fenêtre du navigateur ce qui permet de
déterminer qu'il s'agit bien d'une entête BOM.
Il faut toujours vérifier, lorsque l'on sauvegarde un fichier modifié,
que le logiciel donne une option “Sans BOM” ou que celle-ci fait partie
des Réglages ou Préférences du logiciel.
Lorsque l'on édite/modifie un fichier, bien faire attention aux options
ou préférences dudit logiciel :
Pas de transcodage automatique
Le fichier sauvegardé doit garder son codage d'origine, par exemple
pas de transcodage automatique ASCII -> UTF8
Pas d'ajout d'entête BOM si celle-ci n'existait pas
Faire aussi attention aux logiciels de téléchargement et de transfert de
fichiers (FTP) qui ne doivent, en aucune manière, modifier quoi que ce
soit.
Beaucoup de logiciels Windows (incluant Notepad) ajoutent un BOM aux
fichiers UTF-8 si on n'y prend pas garde. C'est pourquoi il est
recommandé d'utiliser Notepad++ (Gratuit :
http://notepad-plus.sourceforge.net/fr/site.htm) qui indique, en bas de
page, dans la barre d'état, diverses informations dont le codage du
fichier :
ANSI
ANSI as UTF-8 (C'est la version UTF-8 sans BOM)
UTF-8 (C'est la version UTF-8 avec BOM)
etc.
et qui permet, via le menu Encodage, de convertir d'un codage vers un
autre.
Ainsi, si on se retrouve, sans le vouloir, avec les caractères “”, il
suffit d'ouvrir, avec Notepad++ le fichier incriminé, de changer le
codage via le menu Encodage .
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas UFT-8 tout court.
Parce que cette entête BOM ajoute des caractères « parasites » sur une ou plusieurs pages HTML (générées par PHP), comme “” ou, la génération des pages donne une erreur du style Warning: Cannot modify header information - headers already sent by …
Il y a une très grande probabilité pour qu'un ou plusieurs de vos fichiers ait été sauvegardé avec une entête BOM, en anglais Byte Order Mark, qui est - théoriquement - utilisée comme marqueur pour indiquer que le texte est codé en UTF-8, UTF-16 ou UTF-32 et dans quel ordre sont les octets d'un caractère UTF-16 ou UTF-32.
Pour UTF-16, le BOM est une séquence de deux octets FE FF au début de la chaîne codée, pour indiquer que les caractères codés suivants utilisent l'ordre poids fort en dernier (big-endian) ; ou FF FE pour indiquer l'ordre poids faible en dernier (little-endian). Alors qu'UTF-8 n'a aucun problème d'ordre des octets, un BOM codé en UTF-8 peut être mis pour identifier un fichier comme UTF-8, mais ce n'est pas recommandé puisque ce BOM ne sert à rien, l'ordre des octets étant fixe en UTF-8.
Si on utilise un éditeur de texte (ou autre logiciel éditeur hexadécimal) qui permet de voir le fichier sous forme hexadécimale, c'est à dire avec une suite d'octets qui en représente le contenu, on peut voir si il y a des caractères supplémentaires (BOM) au début du fichier.
Par exemple, en vue héxadécimale, le début d'un fichier.php normal est :
On voit bien que trois octets sont insérés au début du fichier : EF BB BF, c'est l'entête BOM. La plupart du temps, ces trois octets sont vus comme caractères : “” dans la fenêtre du navigateur ce qui permet de déterminer qu'il s'agit bien d'une entête BOM.
Il faut toujours vérifier, lorsque l'on sauvegarde un fichier modifié, que le logiciel donne une option “Sans BOM” ou que celle-ci fait partie des Réglages ou Préférences du logiciel.
Lorsque l'on édite/modifie un fichier, bien faire attention aux options ou préférences dudit logiciel :
Pas de transcodage automatique Le fichier sauvegardé doit garder son codage d'origine, par exemple pas de transcodage automatique ASCII -> UTF8 Pas d'ajout d'entête BOM si celle-ci n'existait pas
Faire aussi attention aux logiciels de téléchargement et de transfert de fichiers (FTP) qui ne doivent, en aucune manière, modifier quoi que ce soit.
Beaucoup de logiciels Windows (incluant Notepad) ajoutent un BOM aux fichiers UTF-8 si on n'y prend pas garde. C'est pourquoi il est recommandé d'utiliser Notepad++ (Gratuit : http://notepad-plus.sourceforge.net/fr/site.htm) qui indique, en bas de page, dans la barre d'état, diverses informations dont le codage du fichier :
ANSI ANSI as UTF-8 (C'est la version UTF-8 sans BOM) UTF-8 (C'est la version UTF-8 avec BOM) etc.
et qui permet, via le menu Encodage, de convertir d'un codage vers un autre.
Ainsi, si on se retrouve, sans le vouloir, avec les caractères “”, il suffit d'ouvrir, avec Notepad++ le fichier incriminé, de changer le codage via le menu Encodage . -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont forcément raison. Coluche
Olivier Miakinen
Le 02/09/2014 11:13, Otomatic répondait à Éric Demeester :
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas UFT-8 tout court.
Je ne sais pas si cette nouvelle tentative d'explication sera ou non couronnée de succès, d'autant que je vais ajouter mon grain de sel aux explications très claires d'Otomatic...
Parce que cette entête BOM ajoute des caractères « parasites » sur une ou plusieurs pages HTML (générées par PHP), comme “” ou, la génération des pages donne une erreur du style Warning: Cannot modify header information - headers already sent by …
Oui et oui. Je précise que ces caractères “” ne sont visibles sous cette forme que si l'on lit le fichier comme si c'était du Latin-1 ou équivalent. Ils sont invisibles si on le lit en tant qu'UTF-8, mais néanmoins présents (et potentiellement nuisibles).
Il y a une très grande probabilité pour qu'un ou plusieurs de vos fichiers ait été sauvegardé avec une entête BOM, en anglais Byte Order Mark, qui est - théoriquement - utilisée comme marqueur pour indiquer que le texte est codé en UTF-8, UTF-16 ou UTF-32 et dans quel ordre sont les octets d'un caractère UTF-16 ou UTF-32.
Pour UTF-16, le BOM est une séquence de deux octets FE FF au début de la chaîne codée, pour indiquer que les caractères codés suivants utilisent l'ordre poids fort en dernier (big-endian) ; ou FF FE pour indiquer l'ordre poids faible en dernier (little-endian). Alors qu'UTF-8 n'a aucun problème d'ordre des octets, un BOM codé en UTF-8 peut être mis pour identifier un fichier comme UTF-8, mais ce n'est pas recommandé puisque ce BOM ne sert à rien, l'ordre des octets étant fixe en UTF-8.
J'ajoute que le BOM en UTF-8 est d'autant plus inutile que UTF-8 est très facile à reconnaître : je n'ai entendu parler de confusion possible que dans le cas d'un fichier en chinois de 4 octets.
Si on utilise un éditeur de texte (ou autre logiciel éditeur hexadécimal) qui permet de voir le fichier sous forme hexadécimale, c'est à dire avec une suite d'octets qui en représente le contenu, on peut voir si il y a des caractères supplémentaires (BOM) au début du fichier.
Par exemple, en vue héxadécimale, le début d'un fichier.php normal est :
On voit bien que trois octets sont insérés au début du fichier : EF BB BF, c'est l'entête BOM. La plupart du temps, ces trois octets sont vus comme caractères : “” dans la fenêtre du navigateur ce qui permet de déterminer qu'il s'agit bien d'une entête BOM.
Encore une fois, on ne verra ces caractères qu'en iso-8859-1, Win-1252 ou équivalent. Un BOM peut très bien passer inaperçu tout en étant nuisible dans de nombreux cas.
Il faut toujours vérifier, lorsque l'on sauvegarde un fichier modifié, que le logiciel donne une option “Sans BOM” ou que celle-ci fait partie des Réglages ou Préférences du logiciel.
Lorsque l'on édite/modifie un fichier, bien faire attention aux options ou préférences dudit logiciel :
Pas de transcodage automatique Le fichier sauvegardé doit garder son codage d'origine, par exemple pas de transcodage automatique ASCII -> UTF8 Pas d'ajout d'entête BOM si celle-ci n'existait pas
Faire aussi attention aux logiciels de téléchargement et de transfert de fichiers (FTP) qui ne doivent, en aucune manière, modifier quoi que ce soit.
Oui à tout (si ce n'est qu'un transcodage ASCII -> UTF-8 est une opération qui ne fait rien, pourvu qu'il s'agisse d'UTF-8 simple, sans BOM).
Beaucoup de logiciels Windows (incluant Notepad) ajoutent un BOM aux fichiers UTF-8 si on n'y prend pas garde. C'est pourquoi il est recommandé d'utiliser Notepad++ (Gratuit : http://notepad-plus.sourceforge.net/fr/site.htm) qui indique, en bas de page, dans la barre d'état, diverses informations dont le codage du fichier :
ANSI ANSI as UTF-8 (C'est la version UTF-8 sans BOM) UTF-8 (C'est la version UTF-8 avec BOM) etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir le cerveau assez dérangé pour inventer une telle dénomination ? Et « UTF-8 » seulement pour la version avec BOM ? Tout est fait pour tromper l'utilisateur, on dirait. :-(
et qui permet, via le menu Encodage, de convertir d'un codage vers un autre.
Ainsi, si on se retrouve, sans le vouloir, avec les caractères “”, il suffit d'ouvrir, avec Notepad++ le fichier incriminé, de changer le codage via le menu Encodage .
Ok.
Cordialement, -- Olivier Miakinen
Le 02/09/2014 11:13, Otomatic répondait à Éric Demeester :
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté
de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut
choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas
UFT-8 tout court.
Je ne sais pas si cette nouvelle tentative d'explication sera ou non
couronnée de succès, d'autant que je vais ajouter mon grain de sel
aux explications très claires d'Otomatic...
Parce que cette entête BOM ajoute des caractères « parasites » sur une
ou plusieurs pages HTML (générées par PHP), comme “” ou, la
génération des pages donne une erreur du style Warning: Cannot modify
header information - headers already sent by …
Oui et oui. Je précise que ces caractères “” ne sont visibles sous
cette forme que si l'on lit le fichier comme si c'était du Latin-1 ou
équivalent. Ils sont invisibles si on le lit en tant qu'UTF-8, mais
néanmoins présents (et potentiellement nuisibles).
Il y a une très grande probabilité pour qu'un ou plusieurs de vos
fichiers ait été sauvegardé avec une entête BOM, en anglais Byte Order
Mark, qui est - théoriquement - utilisée comme marqueur pour indiquer
que le texte est codé en UTF-8, UTF-16 ou UTF-32 et dans quel ordre sont
les octets d'un caractère UTF-16 ou UTF-32.
Pour UTF-16, le BOM est une séquence de deux octets FE FF au début de la
chaîne codée, pour indiquer que les caractères codés suivants utilisent
l'ordre poids fort en dernier (big-endian) ; ou FF FE pour indiquer
l'ordre poids faible en dernier (little-endian). Alors qu'UTF-8 n'a
aucun problème d'ordre des octets, un BOM codé en UTF-8 peut être mis
pour identifier un fichier comme UTF-8, mais ce n'est pas recommandé
puisque ce BOM ne sert à rien, l'ordre des octets étant fixe en UTF-8.
J'ajoute que le BOM en UTF-8 est d'autant plus inutile que UTF-8 est
très facile à reconnaître : je n'ai entendu parler de confusion possible
que dans le cas d'un fichier en chinois de 4 octets.
Si on utilise un éditeur de texte (ou autre logiciel éditeur
hexadécimal) qui permet de voir le fichier sous forme hexadécimale,
c'est à dire avec une suite d'octets qui en représente le contenu, on
peut voir si il y a des caractères supplémentaires (BOM) au début du
fichier.
Par exemple, en vue héxadécimale, le début d'un fichier.php normal est :
On voit bien que trois octets sont insérés au début du fichier : EF BB
BF, c'est l'entête BOM. La plupart du temps, ces trois octets sont vus
comme caractères : “” dans la fenêtre du navigateur ce qui permet de
déterminer qu'il s'agit bien d'une entête BOM.
Encore une fois, on ne verra ces caractères qu'en iso-8859-1, Win-1252
ou équivalent. Un BOM peut très bien passer inaperçu tout en étant
nuisible dans de nombreux cas.
Il faut toujours vérifier, lorsque l'on sauvegarde un fichier modifié,
que le logiciel donne une option “Sans BOM” ou que celle-ci fait partie
des Réglages ou Préférences du logiciel.
Lorsque l'on édite/modifie un fichier, bien faire attention aux options
ou préférences dudit logiciel :
Pas de transcodage automatique
Le fichier sauvegardé doit garder son codage d'origine, par exemple
pas de transcodage automatique ASCII -> UTF8
Pas d'ajout d'entête BOM si celle-ci n'existait pas
Faire aussi attention aux logiciels de téléchargement et de transfert de
fichiers (FTP) qui ne doivent, en aucune manière, modifier quoi que ce
soit.
Oui à tout (si ce n'est qu'un transcodage ASCII -> UTF-8 est une
opération qui ne fait rien, pourvu qu'il s'agisse d'UTF-8 simple, sans
BOM).
Beaucoup de logiciels Windows (incluant Notepad) ajoutent un BOM aux
fichiers UTF-8 si on n'y prend pas garde. C'est pourquoi il est
recommandé d'utiliser Notepad++ (Gratuit :
http://notepad-plus.sourceforge.net/fr/site.htm) qui indique, en bas de
page, dans la barre d'état, diverses informations dont le codage du
fichier :
ANSI
ANSI as UTF-8 (C'est la version UTF-8 sans BOM)
UTF-8 (C'est la version UTF-8 avec BOM)
etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir
le cerveau assez dérangé pour inventer une telle dénomination ? Et
« UTF-8 » seulement pour la version avec BOM ? Tout est fait pour
tromper l'utilisateur, on dirait. :-(
et qui permet, via le menu Encodage, de convertir d'un codage vers un
autre.
Ainsi, si on se retrouve, sans le vouloir, avec les caractères “”, il
suffit d'ouvrir, avec Notepad++ le fichier incriminé, de changer le
codage via le menu Encodage .
Le 02/09/2014 11:13, Otomatic répondait à Éric Demeester :
Pour des raisons que je n'ai pas entièrement comprises (on avait tenté de me m'expliquer à l'époque sans grand succès), dans Notepad++, il faut choisir comme encodage : UTF-8 sans BOM, adapté aux sites web, et pas UFT-8 tout court.
Je ne sais pas si cette nouvelle tentative d'explication sera ou non couronnée de succès, d'autant que je vais ajouter mon grain de sel aux explications très claires d'Otomatic...
Parce que cette entête BOM ajoute des caractères « parasites » sur une ou plusieurs pages HTML (générées par PHP), comme “” ou, la génération des pages donne une erreur du style Warning: Cannot modify header information - headers already sent by …
Oui et oui. Je précise que ces caractères “” ne sont visibles sous cette forme que si l'on lit le fichier comme si c'était du Latin-1 ou équivalent. Ils sont invisibles si on le lit en tant qu'UTF-8, mais néanmoins présents (et potentiellement nuisibles).
Il y a une très grande probabilité pour qu'un ou plusieurs de vos fichiers ait été sauvegardé avec une entête BOM, en anglais Byte Order Mark, qui est - théoriquement - utilisée comme marqueur pour indiquer que le texte est codé en UTF-8, UTF-16 ou UTF-32 et dans quel ordre sont les octets d'un caractère UTF-16 ou UTF-32.
Pour UTF-16, le BOM est une séquence de deux octets FE FF au début de la chaîne codée, pour indiquer que les caractères codés suivants utilisent l'ordre poids fort en dernier (big-endian) ; ou FF FE pour indiquer l'ordre poids faible en dernier (little-endian). Alors qu'UTF-8 n'a aucun problème d'ordre des octets, un BOM codé en UTF-8 peut être mis pour identifier un fichier comme UTF-8, mais ce n'est pas recommandé puisque ce BOM ne sert à rien, l'ordre des octets étant fixe en UTF-8.
J'ajoute que le BOM en UTF-8 est d'autant plus inutile que UTF-8 est très facile à reconnaître : je n'ai entendu parler de confusion possible que dans le cas d'un fichier en chinois de 4 octets.
Si on utilise un éditeur de texte (ou autre logiciel éditeur hexadécimal) qui permet de voir le fichier sous forme hexadécimale, c'est à dire avec une suite d'octets qui en représente le contenu, on peut voir si il y a des caractères supplémentaires (BOM) au début du fichier.
Par exemple, en vue héxadécimale, le début d'un fichier.php normal est :
On voit bien que trois octets sont insérés au début du fichier : EF BB BF, c'est l'entête BOM. La plupart du temps, ces trois octets sont vus comme caractères : “” dans la fenêtre du navigateur ce qui permet de déterminer qu'il s'agit bien d'une entête BOM.
Encore une fois, on ne verra ces caractères qu'en iso-8859-1, Win-1252 ou équivalent. Un BOM peut très bien passer inaperçu tout en étant nuisible dans de nombreux cas.
Il faut toujours vérifier, lorsque l'on sauvegarde un fichier modifié, que le logiciel donne une option “Sans BOM” ou que celle-ci fait partie des Réglages ou Préférences du logiciel.
Lorsque l'on édite/modifie un fichier, bien faire attention aux options ou préférences dudit logiciel :
Pas de transcodage automatique Le fichier sauvegardé doit garder son codage d'origine, par exemple pas de transcodage automatique ASCII -> UTF8 Pas d'ajout d'entête BOM si celle-ci n'existait pas
Faire aussi attention aux logiciels de téléchargement et de transfert de fichiers (FTP) qui ne doivent, en aucune manière, modifier quoi que ce soit.
Oui à tout (si ce n'est qu'un transcodage ASCII -> UTF-8 est une opération qui ne fait rien, pourvu qu'il s'agisse d'UTF-8 simple, sans BOM).
Beaucoup de logiciels Windows (incluant Notepad) ajoutent un BOM aux fichiers UTF-8 si on n'y prend pas garde. C'est pourquoi il est recommandé d'utiliser Notepad++ (Gratuit : http://notepad-plus.sourceforge.net/fr/site.htm) qui indique, en bas de page, dans la barre d'état, diverses informations dont le codage du fichier :
ANSI ANSI as UTF-8 (C'est la version UTF-8 sans BOM) UTF-8 (C'est la version UTF-8 avec BOM) etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir le cerveau assez dérangé pour inventer une telle dénomination ? Et « UTF-8 » seulement pour la version avec BOM ? Tout est fait pour tromper l'utilisateur, on dirait. :-(
et qui permet, via le menu Encodage, de convertir d'un codage vers un autre.
Ainsi, si on se retrouve, sans le vouloir, avec les caractères “”, il suffit d'ouvrir, avec Notepad++ le fichier incriminé, de changer le codage via le menu Encodage .
Ok.
Cordialement, -- Olivier Miakinen
alainL
Parfait, ça marche ! Un grand merci et bonne journée.
> ANSI > ANSI as UTF-8 (C'est la version UTF-8 sans BOM) > UTF-8 (C'est la version UTF-8 avec BOM) > etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir le cerveau assez dérangé pour inventer une telle dénomination ? Et « UTF-8 » seulement pour la version avec BOM ? Tout est fait pour tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper » l'utilisateur. Maintenant, c'est : - 'UTF-8 w/o BOM' pour UTF-8 sans BOM - 'UTF-8' pour UTF-8 avec BOM -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont forcément raison. Coluche
> ANSI
> ANSI as UTF-8 (C'est la version UTF-8 sans BOM)
> UTF-8 (C'est la version UTF-8 avec BOM)
> etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir
le cerveau assez dérangé pour inventer une telle dénomination ? Et
« UTF-8 » seulement pour la version avec BOM ? Tout est fait pour
tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper »
l'utilisateur.
Maintenant, c'est :
- 'UTF-8 w/o BOM' pour UTF-8 sans BOM
- 'UTF-8' pour UTF-8 avec BOM
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche
> ANSI > ANSI as UTF-8 (C'est la version UTF-8 sans BOM) > UTF-8 (C'est la version UTF-8 avec BOM) > etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir le cerveau assez dérangé pour inventer une telle dénomination ? Et « UTF-8 » seulement pour la version avec BOM ? Tout est fait pour tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper » l'utilisateur. Maintenant, c'est : - 'UTF-8 w/o BOM' pour UTF-8 sans BOM - 'UTF-8' pour UTF-8 avec BOM -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont forcément raison. Coluche
Olivier Miakinen
Le 02/09/2014 14:48, Otomatic a écrit :
> ANSI as UTF-8 (C'est la version UTF-8 sans BOM) > UTF-8 (C'est la version UTF-8 avec BOM)
[...] Tout est fait pour tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper » l'utilisateur. Maintenant, c'est : - 'UTF-8 w/o BOM' pour UTF-8 sans BOM - 'UTF-8' pour UTF-8 avec BOM
Même si j'aurais préféré respectivement 'UTF-8 w/o BOM' et 'UTF-8 with BOM', voire 'UTF-8' et 'UTF-8 with BOM', c'est déjà beaucoup mieux. Merci de l'avoir demandé... et obtenu !
Le 02/09/2014 14:48, Otomatic a écrit :
> ANSI as UTF-8 (C'est la version UTF-8 sans BOM)
> UTF-8 (C'est la version UTF-8 avec BOM)
[...] Tout est fait pour tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper »
l'utilisateur.
Maintenant, c'est :
- 'UTF-8 w/o BOM' pour UTF-8 sans BOM
- 'UTF-8' pour UTF-8 avec BOM
Même si j'aurais préféré respectivement 'UTF-8 w/o BOM' et 'UTF-8
with BOM', voire 'UTF-8' et 'UTF-8 with BOM', c'est déjà beaucoup
mieux. Merci de l'avoir demandé... et obtenu !
> ANSI as UTF-8 (C'est la version UTF-8 sans BOM) > UTF-8 (C'est la version UTF-8 avec BOM)
[...] Tout est fait pour tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper » l'utilisateur. Maintenant, c'est : - 'UTF-8 w/o BOM' pour UTF-8 sans BOM - 'UTF-8' pour UTF-8 avec BOM
Même si j'aurais préféré respectivement 'UTF-8 w/o BOM' et 'UTF-8 with BOM', voire 'UTF-8' et 'UTF-8 with BOM', c'est déjà beaucoup mieux. Merci de l'avoir demandé... et obtenu !
Denis Beauregard
Le Tue, 02 Sep 2014 14:48:52 +0200, Otomatic écrivait dans fr.comp.lang.php:
Olivier Miakinen <om+ écrivait :
> ANSI > ANSI as UTF-8 (C'est la version UTF-8 sans BOM) > UTF-8 (C'est la version UTF-8 avec BOM) > etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir le cerveau assez dérangé pour inventer une telle dénomination ? Et « UTF-8 » seulement pour la version avec BOM ? Tout est fait pour tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper » l'utilisateur. Maintenant, c'est : - 'UTF-8 w/o BOM' pour UTF-8 sans BOM - 'UTF-8' pour UTF-8 avec BOM
J'ai la version française et je pense que j'ai toujours lu
Encoder en UTF-8 (sans BOM)
Je ne me rappelle pas avoir lu ANSI pour UTF-8 mais je n'utilise que depuis 2 ou 3 ans.
Denis
Le Tue, 02 Sep 2014 14:48:52 +0200, Otomatic <otomatic@oto.invalid>
écrivait dans fr.comp.lang.php:
> ANSI
> ANSI as UTF-8 (C'est la version UTF-8 sans BOM)
> UTF-8 (C'est la version UTF-8 avec BOM)
> etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir
le cerveau assez dérangé pour inventer une telle dénomination ? Et
« UTF-8 » seulement pour la version avec BOM ? Tout est fait pour
tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper »
l'utilisateur.
Maintenant, c'est :
- 'UTF-8 w/o BOM' pour UTF-8 sans BOM
- 'UTF-8' pour UTF-8 avec BOM
J'ai la version française et je pense que j'ai toujours lu
Encoder en UTF-8 (sans BOM)
Je ne me rappelle pas avoir lu ANSI pour UTF-8 mais je n'utilise que
depuis 2 ou 3 ans.
Le Tue, 02 Sep 2014 14:48:52 +0200, Otomatic écrivait dans fr.comp.lang.php:
Olivier Miakinen <om+ écrivait :
> ANSI > ANSI as UTF-8 (C'est la version UTF-8 sans BOM) > UTF-8 (C'est la version UTF-8 avec BOM) > etc.
Beurk ! « ANSI as UTF-8 » pour de l'UTF-8 sans BOM ? Qui a pu avoir le cerveau assez dérangé pour inventer une telle dénomination ? Et « UTF-8 » seulement pour la version avec BOM ? Tout est fait pour tromper l'utilisateur, on dirait. :-(
J'avais demandé à ce que ce soit modifié pour éviter de « tromper » l'utilisateur. Maintenant, c'est : - 'UTF-8 w/o BOM' pour UTF-8 sans BOM - 'UTF-8' pour UTF-8 avec BOM
J'ai la version française et je pense que j'ai toujours lu
Encoder en UTF-8 (sans BOM)
Je ne me rappelle pas avoir lu ANSI pour UTF-8 mais je n'utilise que depuis 2 ou 3 ans.
Denis
Otomatic
Denis Beauregard écrivait :
Encoder en UTF-8 (sans BOM)
Je ne me rappelle pas avoir lu ANSI pour UTF-8 mais je n'utilise que depuis 2 ou 3 ans.
Ce dont je « parlais », c'est ce qui est indiqué dans la ligne d'état, pas des intitulés des options du menu de transcodage.
Je ne me rappelle pas avoir lu ANSI pour UTF-8 mais je n'utilise que depuis 2 ou 3 ans.
Ce dont je « parlais », c'est ce qui est indiqué dans la ligne d'état, pas des intitulés des options du menu de transcodage.
Otomatic
Olivier Miakinen <om+ écrivait :
Même si j'aurais préféré respectivement 'UTF-8 w/o BOM' et 'UTF-8 with BOM', voire 'UTF-8' et 'UTF-8 with BOM', c'est déjà beaucoup mieux. Merci de l'avoir demandé... et obtenu !
Et moi aussi ! Je préfère l'explicite à l'implicite(1). Mais, c'est mieux que rien. Du coup, je viens de faire une demande similaire pour UltraEdit.
(1) En tant qu'ancien contrôleur qualité principal dans l'aéronautique, je faisais appliquer : Tout ce qui n'est pas explicitement autorisé est implicitement interdit. -- Envoyé depuis mon Apple ][ Europlus et Carte Appletell en réversible 1200/75
Même si j'aurais préféré respectivement 'UTF-8 w/o BOM' et 'UTF-8
with BOM', voire 'UTF-8' et 'UTF-8 with BOM', c'est déjà beaucoup
mieux. Merci de l'avoir demandé... et obtenu !
Et moi aussi !
Je préfère l'explicite à l'implicite(1). Mais, c'est mieux que rien.
Du coup, je viens de faire une demande similaire pour UltraEdit.
(1) En tant qu'ancien contrôleur qualité principal dans l'aéronautique,
je faisais appliquer :
Tout ce qui n'est pas explicitement autorisé est implicitement interdit.
--
Envoyé depuis mon Apple ][ Europlus et
Carte Appletell en réversible 1200/75
Même si j'aurais préféré respectivement 'UTF-8 w/o BOM' et 'UTF-8 with BOM', voire 'UTF-8' et 'UTF-8 with BOM', c'est déjà beaucoup mieux. Merci de l'avoir demandé... et obtenu !
Et moi aussi ! Je préfère l'explicite à l'implicite(1). Mais, c'est mieux que rien. Du coup, je viens de faire une demande similaire pour UltraEdit.
(1) En tant qu'ancien contrôleur qualité principal dans l'aéronautique, je faisais appliquer : Tout ce qui n'est pas explicitement autorisé est implicitement interdit. -- Envoyé depuis mon Apple ][ Europlus et Carte Appletell en réversible 1200/75
J'ai la version française et je pense que j'ai toujours lu Encoder en UTF-8 (sans BOM)
C'est bien ça.
Je ne me rappelle pas avoir lu ANSI pour UTF-8 mais je n'utilise que depuis 2 ou 3 ans.
Au delà de la réponse d'Automatic, il me semble qu'ANSI (dans le menu de choix d'encodage) se rapporte à ce qu'on a choisi comme table dans « Langues d'Europe occidentale », à savoir le plus communément ISO-8859-1(5) ou cp1252 (Windows).
Quelqu'un pour confirmer ou infirmer cette interprétation pifométrique ?
J'ai la version française et je pense que j'ai toujours lu
Encoder en UTF-8 (sans BOM)
C'est bien ça.
Je ne me rappelle pas avoir lu ANSI pour UTF-8 mais je n'utilise que
depuis 2 ou 3 ans.
Au delà de la réponse d'Automatic, il me semble qu'ANSI (dans le menu de
choix d'encodage) se rapporte à ce qu'on a choisi comme table dans
« Langues d'Europe occidentale », à savoir le plus communément
ISO-8859-1(5) ou cp1252 (Windows).
Quelqu'un pour confirmer ou infirmer cette interprétation pifométrique ?
J'ai la version française et je pense que j'ai toujours lu Encoder en UTF-8 (sans BOM)
C'est bien ça.
Je ne me rappelle pas avoir lu ANSI pour UTF-8 mais je n'utilise que depuis 2 ou 3 ans.
Au delà de la réponse d'Automatic, il me semble qu'ANSI (dans le menu de choix d'encodage) se rapporte à ce qu'on a choisi comme table dans « Langues d'Europe occidentale », à savoir le plus communément ISO-8859-1(5) ou cp1252 (Windows).
Quelqu'un pour confirmer ou infirmer cette interprétation pifométrique ?
