Discussion:
encodage mal programmé ?
(trop ancien pour répondre)
alainL
2014-09-01 07:32:30 UTC
Permalink
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>

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" >
<title>Quizz fleurs (questions)</title>
...............................................................

# lecture fichier, sélection aléatoire de 10 lignes
$Fnm=$_GET['Fnm'];
$inF = fopen($Fnm,'r');

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);
}
............................................

print ("<form name='form1' method='post' action='quizz1r.php'>
<fieldset><legend></legend>
<img src='$imgligne1' alt='' ><br>
<label for='r_01'>
<input id='r_01' type='radio' name='reponse1' value='$nfligne1' >
$nfligne1
</label>
<label for='r_02'>
<input id='r_02' type='radio' name='reponse1' value='$nvligne1' >
$nvligne1
</label>
<label for='r_03'>
<input id='r_03' type='radio' name='reponse1' value='$nffligne1' >
$nffligne1
</label>
<input type='hidden' name='bonnereponse1' value='$nvligne1' >
<input type='hidden' name='image1' value='$imgligne1' >
</fieldset>

================================================================

AlainL
Denis Beauregard
2014-09-01 07:59:46 UTC
Permalink
Post by alainL
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 )
Mon serveur impose l'UTF-8 même si le fichier est en iso. Le problème
est peut-être là et non dans le code.


Denis
Eric Demeester
2014-09-01 08:58:01 UTC
Permalink
Bonjour,
Post by alainL
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)
Au delà de la possibilité évoquée par Denis, je te suggère d'utiliser
plutôt Notepad++, beaucoup mieux adapté à la gestion des encodages
(ainsi qu'à l'écriture de scripts PHP, entre autres) que le Notepad de
Windows :
http://notepad-plus-plus.org/fr/
Post by alainL
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" >
Menu Encodage -> Encoder en ANSI (ou convertir en ANSI)
Menu Édition -> Convertir les sauts de ligne -> Convertir en format UNIX
(si ton serveur est sous UNIX, cas le plus fréquent).

Vois si ça résoud ton problème, ou si ça te permet de mieux le
comprendre.
Eric Demeester
2014-09-01 09:39:54 UTC
Permalink
Post by Eric Demeester
Menu Encodage -> Encoder en ANSI (ou convertir en ANSI)
En complément, dans le même menu :
Codage de caractères -> Langues d'Europe occidentale -> ISO-7859-1

Tu devrais songer à travailler plutôt en UFT-8, voire adopter aussi
HTML5, mais nous sortons du cadre du PHP.
alainL
2014-09-01 11:00:10 UTC
Permalink
Merci.

Je viens de modifier le charset du fichier question et d'enregistrer la
liste avec notepad++ en précisant encodage utf-8...

la liste apparait, après le choix d'utf-8, avec des caractères
particuliers mais c'est peut-être normal...

Par contre, les deux fichiers transférés sur la site distant, le
problème persiste, certaines données sont ignorées... (testé sous Ffx ou
Chrome)

http://autourdalos.fr/html/quizz1qutf.php?Fnm=fleurs_septembreutf.txt

AlainL
Post by Eric Demeester
Post by Eric Demeester
Menu Encodage -> Encoder en ANSI (ou convertir en ANSI)
Codage de caractères -> Langues d'Europe occidentale -> ISO-7859-1
Tu devrais songer à travailler plutôt en UFT-8, voire adopter aussi
HTML5, mais nous sortons du cadre du PHP.
Olivier Miakinen
2014-09-01 13:24:40 UTC
Permalink
Post by alainL
Je viens de modifier le charset du fichier question et d'enregistrer la
liste avec notepad++ en précisant encodage utf-8...
la liste apparait, après le choix d'utf-8, avec des caractères
particuliers mais c'est peut-être normal...
C'est normal si ton encodage par défaut ini_get("default_charset") vaut
UTF-8 : la fonction htmlspecialchars dont je t'ai encouragé à lire la
doc laisse passer les caractères puisque maintenant ils sont valides,
mais le navigateur les décode mal puisqu'on lui a dit que c'était du
Latin-1.
Post by alainL
Par contre, les deux fichiers transférés sur la site distant, le
problème persiste, certaines données sont ignorées... (testé sous Ffx ou
Chrome)
http://autourdalos.fr/html/quizz1qutf.php?Fnm=fleurs_septembreutf.txt
Cf. la doc, tu dois préciser à la fonction htmlspecialchars quel est
l'encodage de ce dont tu lui demandes de traiter les 'special chars'.
Pour te faciliter la vie, tu peux aussi mettre l'option ENT_SUBSTITUTE,
ce qui te permettra de voir au moins les caractères ASCII.

P.-S.: Tant que tu y es, je te suggère de passer *tout* à UTF-8 :
- le contenu du fichier .txt
- le paramètre de htmlspecialchars
- le meta http-equiv de la page
- l'entête Content-Type envoyé par ton serveur Apache (ceci, quand tu
auras traduit toutes tes pages en UTF-8)

Cordialement,
--
Olivier Miakinen
Olivier Miakinen
2014-09-01 14:13:55 UTC
Permalink
Post by Olivier Miakinen
Post by alainL
la liste apparait, après le choix d'utf-8, avec des caractères
particuliers mais c'est peut-être normal...
C'est normal si ton encodage par défaut ini_get("default_charset") vaut
UTF-8
C'est un peu plus compliqué que ça, comme je viens de m'en rendre
compte en lisant un peu plus complètement la doc :
<http://fr2.php.net/manual/fr/function.htmlspecialchars.php>.

L'encodage par défaut est :
- "ISO-8859-1" avant PHP 5.4
- "UTF-8" en PHP 5.4 et PHP 5.5
- ini_get("default_charset") à partir de PHP 5.6

En outre, si l'on en croit une note d'utilisateur vieille de trois
ans, le paramètre $encoding est sensible à la casse !


Bref, à utiliser avec précautions...
alainL
2014-09-01 21:10:09 UTC
Permalink
Je patauge !
j'ai donc :
- le fichier.txt en UTF-8 (avec notepad++)AlainL
- DOC type html 4.01 et charset=UTF-8

- j'ai essayé d'utiliser l'exemple de la doc et modifié une série de
récup de données avec ça :
================================================================
string htmlspecialchars ( string $string [, int $flags = ENT_COMPAT |
ENT_HTML401 | ENT_QUOTES [, string $encoding = UTF-8]] )

if ($numligne[$i]==$origine){
$imgligne1=$donneesligne[1];
$nvligne1=htmlspecialchars($donneesligne[2]);
$nfligne1=htmlspecialchars($donneesligne[3]);
$nffligne1=htmlspecialchars($donneesligne[4]);
}
.............
============================================

Mauvaise syntaxe sans doute, le résultat est une page blanche, je n'ai
même plus l'image !


http://autourdalos.fr
Post by Olivier Miakinen
Post by Olivier Miakinen
Post by alainL
la liste apparait, après le choix d'utf-8, avec des caractères
particuliers mais c'est peut-être normal...
C'est normal si ton encodage par défaut ini_get("default_charset") vaut
UTF-8
C'est un peu plus compliqué que ça, comme je viens de m'en rendre
<http://fr2.php.net/manual/fr/function.htmlspecialchars.php>.
- "ISO-8859-1" avant PHP 5.4
- "UTF-8" en PHP 5.4 et PHP 5.5
- ini_get("default_charset") à partir de PHP 5.6
En outre, si l'on en croit une note d'utilisateur vieille de trois
ans, le paramètre $encoding est sensible à la casse !
Bref, à utiliser avec précautions...
Olivier Miakinen
2014-09-02 08:17:41 UTC
Permalink
Post by alainL
Je patauge !
Bon, reprenons calmement.

Tu as gardé une sauvegarde de ton script initial (encodé en iso-8859-1)
avec le fichier de questions lui-même en iso-8859-1 ?

Reprends tout ça, en remplaçant simplement les :
htmlspecialchars($donneesligne[...], ENT_QUOTES);
par :
htmlspecialchars($donneesligne[...], ENT_QUOTES|ENT_SUBSTITUTE,
"ISO-8859-1");

Puis reviens nous voir.


P.-S. : Je suis désolé, je pensais que t'envoyer vers la lecture de la
doc de la fonction htmlspecialchars suffirait à t'éclairer.
Rappel : <http://fr2.php.net/manual/fr/function.htmlspecialchars.php>

Cordialement,
--
Olivier Miakinen
alainL
2014-09-02 09:36:58 UTC
Permalink
Parfait, ça marche !
Un grand merci et bonne journée.

AlainL

http://autourdalos.fr
Post by Olivier Miakinen
htmlspecialchars($donneesligne[...], ENT_QUOTES|ENT_SUBSTITUTE,
"ISO-8859-1");
Denis Beauregard
2014-09-01 23:02:27 UTC
Permalink
Le Mon, 01 Sep 2014 15:24:40 +0200, Olivier Miakinen
Post by Olivier Miakinen
- l'entête Content-Type envoyé par ton serveur Apache (ceci, quand tu
auras traduit toutes tes pages en UTF-8)
Pour le passage à UTF-8, l'idéal est de tout convertir avec
notepad++ comme suggéré.

Je me rappelle qu'il y avait un test pour vérifier si tous les
caractères de type 0x80 à 0xFF sont précédés ou suivis d'un autre
du même groupe ou pas. Si c'est isolé, ce n'est pas du UTF-8.

Ce doit être dans les archives de ce groupe Usenet.

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.


Denis
Eric Demeester
2014-09-02 08:33:04 UTC
Permalink
Bonjour,
Post by Denis Beauregard
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.
Post by Denis Beauregard
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
2014-09-02 09:13:46 UTC
Permalink
Post by Eric 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.
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 :

00000000 3C3F 7068 700D 0A2F 2A2A 2A2A 2A2A <?php..//******
0000000E 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************
0000001C 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************

Le même fichier avec entête BOM est :

00000000 EFBB BF3C 3F70 6870 0D0A 2F2A 2A2A <?php..//***
0000000E 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************
0000001C 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************

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
2014-09-02 09:36:42 UTC
Permalink
Post by Otomatic
Post by Eric 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...
Post by 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).
Post by Otomatic
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.
Post by Otomatic
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.
00000000 3C3F 7068 700D 0A2F 2A2A 2A2A 2A2A <?php..//******
0000000E 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************
0000001C 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************
00000000 EFBB BF3C 3F70 6870 0D0A 2F2A 2A2A <?php..//***
0000000E 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************
0000001C 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************
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.
Post by Otomatic
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
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).
Post by Otomatic
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
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
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. :-(
Post by Otomatic
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
Otomatic
2014-09-02 12:48:52 UTC
Permalink
Post by Olivier Miakinen
Post by Otomatic
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
2014-09-02 13:01:35 UTC
Permalink
Post by Otomatic
Post by Otomatic
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.
- '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 !
Otomatic
2014-09-02 13:35:47 UTC
Permalink
Post by Olivier Miakinen
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
Denis Beauregard
2014-09-02 13:06:06 UTC
Permalink
Post by Otomatic
Post by Olivier Miakinen
Post by Otomatic
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.
- '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
2014-09-02 13:35:47 UTC
Permalink
Post by Denis Beauregard
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.
Denis Beauregard
2014-09-02 13:52:41 UTC
Permalink
Post by Otomatic
Post by Denis Beauregard
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.
Alors, c'est encore affiché ANSI as UTF-8, version 5.9.6.2 (je viens
de faire la mise à jour).


Denis
Otomatic
2014-09-02 14:37:09 UTC
Permalink
Post by Denis Beauregard
Alors, c'est encore affiché ANSI as UTF-8, version 5.9.6.2 (je viens
de faire la mise à jour).
J'ai vérifié sur MA version 6.6.8
http://notepad-plus-plus.org/download/v6.6.8.html
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche
Denis Beauregard
2014-09-02 15:25:24 UTC
Permalink
Post by Otomatic
Post by Denis Beauregard
Alors, c'est encore affiché ANSI as UTF-8, version 5.9.6.2 (je viens
de faire la mise à jour).
J'ai vérifié sur MA version 6.6.8
http://notepad-plus-plus.org/download/v6.6.8.html
Je comprends pourquoi la date de compilation était encore 2011 !
Cette version 5.xxx ne pourrait donc faire des mises à jour que pour
les 5.xxx.


Denis

Eric Demeester
2014-09-02 13:57:17 UTC
Permalink
Post by Denis Beauregard
J'ai la version française et je pense que j'ai toujours lu
Encoder en UTF-8 (sans BOM)
C'est bien ça.
Post by Denis Beauregard
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 ?
Otomatic
2014-09-02 15:22:42 UTC
Permalink
Post by Eric Demeester
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).
Oui.
« Langues d'Europe Occidentale » ou « Europe de l'Ouest », souvent noté
également « Latin1 » selon les logiciels, se réfère à ISO-8859-1, en
théorie. J'écris « en théorie », puisque, sous Windows, c'est
généralement CP1252 qui est utilisé, nommé également ANSI, par
opposition à OEM qui est le jeu utilisé en fenêtre de Commande, en
principe CP850(1)
La différence entre CP1252 et ISO-8859-1 réside dans la plage 0x80 à
0x9F utilisée en CP1252 et pas en ISO-8859-1, sinon le reste est
identique.
Voir l'excellente page d'Olivier :
http://www.miakinen.net/vrac/charsets/

(1) Ce qui peut poser des problèmes, par exemple avec l'utilisation de
MySQL en console, si on ne prend pas la précaution de déclarer le jeu de
caractère que l'on va utiliser.
--
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
Technologie aéronautique - http://aviatechno.net - Les anciens de Vilgénis
Olivier Miakinen
2014-09-01 10:49:16 UTC
Permalink
Bonjour,
[...] 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 )
En effet, certaines chaînes sont vides.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Voici qqs morceaux du code de la page question.php
=================================================================
Voyons les fonctions que tu appelles.
$inF = fopen($Fnm,'r');
http://fr2.php.net/manual/fr/function.fopen.php
Je ne vois pas de problème particulier avec le charset.
$ligne[$i] = fgets($inF, 4096);
http://fr2.php.net/manual/fr/function.fgets.php
Idem.
$donneesligne=explode(';',$ligne[$i]);
http://fr2.php.net/manual/fr/function.explode.php
Idem.
$nvligne1=htmlspecialchars($donneesligne[2], ENT_QUOTES);
http://fr2.php.net/manual/fr/function.htmlspecialchars.php

Là par contre il y a plein de trucs à propos de l'encodage et des
caractères invalides ! En particulier...

1) un paramètre $encoding qui vaut par défaut ini_get("default_charset")
et non "iso-8859-1" : sais-tu quelle est sa valeur ?

2) le fait que la valeur de retour sera une chaîne vide si la chaîne
d'entrée est une séquence de code invalide, à moins que tu n'aies
mis l'un des drapeaux ENT_IGNORE (déconseillé) ou ENT_SUBSTITUTE
(qui mettra U+FFFD à la place).


Et donc, comme souvent : RTFM ! ;-)

Cordialement,
--
Olivier Miakinen
Continuer la lecture sur narkive:
Loading...