5172 sujets

Le Bar du forum

Pages :
(reprise du message précédent)

Je vais aller re-re-re-lire ces excellents articles... En tant cas, j'ai mis à jour mes pense-bêtes, c'était apparemment urgent !

Encore merci pour toutes ces précisions.

Mine de rien, ça devient hyper technique de faire un oe !
Je me permet de citer un mail que j'ai écrit ce matin, avant d'aller dormir, sur la mailing-liste Ubuntu-FR, en réponse à une question sur le sujet:
HoPHP, le 17.12.2005, à 06.30:01 a écrit :
Bonjour,

je me lance...qu'on me corrige si je dis une bêtise...

Un fichier, c'est une suite de bits, soit des 1 et des 0. Pour faire
l'analogie avec la parole, c'est le son.

Ensuite, entre deux interlocuteurs informatiques (un serveur et un navigateur
par exemple), il faut s'entendre sur quelle suite de bits correspond à quel
caractère et combien il faut de bits pour définir un caractère. Pour ça, il
faut des alphabets (analogie "parole", c'est la langue), ce qu'on appelle, en
anglais "charset" ou "character set", "codage de caractère" en français.

Exemple avec le caractère "A majuscule"

* en ASCII (un des premiers, sur 7 bits + un bit 0 [le premier ici, bit de
poids fort]):
01000001
* en ISO-8859-1 (de même qu'en ISO-8859-15, préférable), sur 8 bits:
01000001 (on notera que c'est la même chose... )
* en UTF-8 (extension de l'ASCII en utilisant le bit à 0 et de longueur
variable):
01000001 (on notera que c'est encore la même chose).

Oui, l'exemple du A majuscule est plutôt bateau. Mais c'est normal. C'est
justement parce que le A se code de la même manière dans tous les codages de
caractères qu'il est possible, par défaut, d'avoir une certaine
"inter-opérabilité".

Prenons un autre exemple: le é (e accent aigu) [1]:

* en ASCII: n'existe pas !
* en ISO-8859-1(5):
11101001
* en UTF-8:
11000011 10101001

Ici, on a une différence. Si on décode la suite UTF8 en ISO-8859-15, on
obtient deux caractères (vu que la longueur est double): é....

L'encodage est un problème de fichier, pas de système ! On dit, par abus de
langage, que Ubuntu est en UTF-8. Cela signifie en fait que (presque [2])
tous les fichiers sont encodés en UTF-8 et que le format "par défaut" est
l'UTF-8. Mais il est simple d'enregistrer un fichier en ISO-8859-15 ou en
JIS.

> Par exemple... si je fais un fichier sur ma desktop (une page web) et que
> je la pousse sur un serveur apache qui lui est en iso-8859-1... que ce
> passe-t-il?

Si tu enregistres ton fichier en UTF-8, il sera en UTF-8 sur le serveur.
Simplement, si ton fichier est un fichier PHP qui envoie un entête HTTP
annonçant de l'ISO-8859-15 (ce qui permet au navigateur de déchiffrer
correctement la suite de bits qu'il va recevoir) et que tes caractères sont
en UTF-8, cela va poser un problème. Il faut donc s'assurer d'une certaine
cohérence entre fichiers et entêtes HTTP.

> Ou si je fais un get d'un fichier iso-8859-1 vers ma machine pour le
> modifier... les accents sont tout croche.

C'est parce que ton éditeur a ouvert le fichier dans un codage de caractères
erroné. Normalement, il est possible de préciser à ton éditeur le codage de
caractères que tu désires utiliser (bien qu'il devrait "deviner" tout seul).

Est-ce que c'est un peu plus clair ?

Sources: Wikipedia. Articles:
http://fr.wikipedia.org/wiki/Codage_de_caractères
http://fr.wikipedia.org/wiki/ASCII
http://fr.wikipedia.org/wiki/ISO_8859-1
http://fr.wikipedia.org/wiki/ISO_8859-15
http://fr.wikipedia.org/wiki/Unicode
http://fr.wikipedia.org/wiki/UTF-8

Salutations, HoPHP - Didier

P.S. Je ne suis pas certain de mes exemples, mais le principe est là...

[1] L'exemple du oe-lié est un mauvais exemple... Voir sources.
[2] Certaines pages de man, par exemple, ne sont pas en UTF-8, mais décodées
comme telles....

Merci de corriger les imprécisions!

Plusieurs remarques:
1. Si le caractère n'existe pas, le forum le transforme en entité... Mais pourquoi n'est-elle pas interprétée ? Smiley biggol
2. Chez moi, pour faire un oe (œ), je fais [Compose] et o puis e (N.B. la touche [Compose] est configurable. Chez moi, correspond au [Ctrl] droite)

@+, HoPHP
Administrateur
Laurent Denis a écrit :


ouiiiiii Smiley ravi

A-l-sa-en-UTF-8 ! A-l-sa-en-UTF-8 ! A-l-sa-en-UTF-8 !

Ah moi je ne suis pas contre, mais je dois avoir du mal avec les technologies modernes : lorsque j'indique un charset en utf-8, tous les caractères spéciaux s'affichent n'importe comment.

Si on me dit concrêtement comment procéder, je ne suis pas contre.
Relis bien le mail ci-dessus ! Smiley lol

Le charset annoncé doit correspondre à la "réalité des bits". Donc... Tous les fichiers (PHP entre autres) doivent être enregistrés en UTF-8 (ce qui, normalement, ne change rien, vu que le code ne devrait pas trop contenir d'accents et de caractères spéciaux. Les commentaires si...) et toute la base de donnée doit être en UTF-8.

Ou faire la conversion à la volée..

Problèmes que je vois:

* Soit il faut que Dew implémente la conversion à la volée. Ça, c'est chaud, m'enfin, j'attends son avis Smiley lol
* Soit il faut tout préparer, tester et faire le changement à un instant "t". Ce qui implique la fermeture du forum pour une nuit (en gros).

Quand ?

@+, HoPHP
Administrateur
Euh non mais moi je parlais d'une page web "en général" : quand je fais une bête page web (sans fichier php ni bdd), déclarée en utf-8 et contenant des caractères spéciaux, ces caractères sotn remplacés par des trucs bizarres.
Raphael a écrit :
Euh non mais moi je parlais d'une page web "en général" : quand je fais une bête page web (sans fichier php ni bdd), déclarée en utf-8 et contenant des caractères spéciaux, ces caractères sotn remplacés par des trucs bizarres.

Il faut que ton éditeur de page encode en UTF-8
Si vous passen en utf8, j'espère pour vous que votre database le supporte... parce que par exemple, en utf8, é vient après z...
Plus je comprends le problème, moins je comprends la solution Smiley biggol

J'ai eu effectivement un gros souci lors du changement de version d'easyphp : mes pages se sont retrouvées envahies de hiéroglyphes.

La solution a été d'importer les fichiers sql en utf-8, et non plus de copier-coller les requêtes comme je faisais.

Mais alors, pourquoi faut-il les bases en utf-8 pour les lire correctement avec un charset iso-8859-15 ?

Je travaille avec notepad++, ne l'ayant pas sous la main, j'ignore en quoi il encode par défaut. Sur framasoft il est indiqué qu'il gère l'utf-8.

Toujours est-il que depuis, je n'ai plus de soucis avec les caractères accentués et spéciaux.

Précisions peut-être importantes : c'était pour un SPIP, donc pages déjà existantes + nouvelles. Pour éviter les cata, je travaille toujours sur des copies, mais pas en faisant "enregistrer sous" dans notepad++ (le fichier prendrait ainsi son encodage par défaut en toute logique) mais en faisant une copie de fichier via l'explorateur.

J'avais prévenu, j'suis toute mêlée Smiley confus

Question subsidiaire : comment savoir si un fichier a été encodé en utf-8 ou en iso-8859-1(5) ?
Salut,

Et pour etre sur que la page d'un site, rédigée en français, avec la typo adéquate soit lue sur un écran outre atlantique, en France et en Asie, vous suggérez quoi?

a+
a écrit :
Y'a peu de chanse qu'un asiatique sache le français, donc ça sert à rien pour l'asiatique.
Smiley lol

Of course Quentin! Smiley lol

Mais je posais la question pour les FRANCAIS qui bossent et vivent en Asie, (et qui ont accés au net via les cyber café du coin) cqfd! Smiley lol y'a des étudiants français malgré tout, Smiley lol
Modifié par Vajra (18 Dec 2005 - 09:53)
Bonjour,

boulaneige : il est indispensable que toutes les étapes de production et de manipulation du texte, de la base de donnée au navigateur, de la version en ligne à la copie locale, etc. soient paramétrés pour le même jeu de caractères, et que celui-ci soit réellement celui des données. Une seule incohérence suffit à obtenir un résultat anormal (mauvais paramétrage d'esayphp, import d'une BDD dans le mauvais jeu, copié-collé depuis un éditeur inadapté ou mal paramétré, etc.). Dans ton cas, je suppose qu'une incohérence en a accidentellement corrigé une autre Smiley cligne

Pour connaître l'encodage réel d'une page web, une solution simple et relativement fiable : l'afficher dans un navigateur et tester le résultat en forçant les jeux de caractères possibles via le menu Afficher > Encodage. L'affichage correct révèlera le bon jeu.

Vajra : il suffit d'utiliser correctement le jeu de caractère choisi, que ce soit ISO-8859-1, ISO-8895-15, UTF-8 ou même ASCII-US :
- Conserver ce jeu à toutes les étapes, depuis l'éditeur produisant les textes jusqu'au serveur et au document finalement servi
- n'écrire littéralement que les caractères existants dans le jeu choisi, et utiliser les entités numériques ou caractères pour les autres.

Si on prend par exemple les caractères "e", "é", euro et pour mille :
- en US-ASCII, seul le "e" existe. Tous les autres devront être écrits en entités &...; Et tous pourront alors être correctement affichés.
- en ISO-8859-1, seuls le "e" et le "é" existent et pourront être écrits littéralement. Pour les autres, ce sera &...;
- en ISO-8859-15, l'euro s'ajoute aux caractères existants
- en UTF-8, tous ces caractères existent et aucun n'a besoin d'être sous forme &...;

Pour le choix entre entités caractères (€) ou numériques (€) : le support des uns et des autres est finalement à peu près équivalent : les navigateurs vraiment anciens ont du mal, les navigateurs modernes s'en sortent bien.

Précaution à prendre : les entités caractères sont définies par le format du document (HTML, XHTML, SVG, etc) et tous les formats n'ont pas une liste d'entités aussi étendue. Les caractères "français" les plus courants se retrouveront partout, mais il est prudent de vérifier pour les autres. On se réfère à :
- http://www.w3.org/TR/html401/sgml/entities.html pour un document HTML
- http://www.w3.org/TR/xhtml1/#h-A2 pour un document XHTML1.0

A l'inverse, les entités numériques sont totalement indépendantes du format de document.

Pour des caractères beaucoup plus "exotiques", comme ceux de l'alphabet phonétique par exemple, il faut prévoir une contrainte supplémentaire : préciser une police de caractère dans laquelle ces caractères sont correctement dessinés et espérer que le visiteur aura cette police ou que son navigateur saura trouver l'équivalence.
Modifié par Laurent Denis (18 Dec 2005 - 09:56)
QuentinC a écrit :
Y'a peu de chanse qu'un asiatique sache le français, donc ça sert à rien pour l'asiatique.


Ah...

Très en forme, notre Quentin, ce matin Smiley eek

(bon, ça peu arriver à tout le monde Smiley cligne )
Modifié par Laurent Denis (18 Dec 2005 - 10:01)
Raphael a écrit :
Euh non mais moi je parlais d'une page web "en général" : quand je fais une bête page web (sans fichier php ni bdd), déclarée en utf-8 et contenant des caractères spéciaux, ces caractères sotn remplacés par des trucs bizarres.

Peut-être le header HTTP "Content-Type" est-il mal renseigné ? En général les serveurs envoient en ISO-8859-1 par défaut.

Pour résoudre le problème en PHP par exemple :
header('Content-Type: text/html; charset=UTF-8');


Ou dans un .htaccess :
AddCharset UTF-8 .html
Laurent Denis a écrit :
Bonjour,

boulaneige : il est indispensable que toutes les étapes de production et de manipulation du texte, de la base de donnée au navigateur, de la version en ligne à la copie locale, etc. soient paramétrés pour le même jeu de caractères, et que celui-ci soit réellement celui des données. Une seule incohérence suffit à obtenir un résultat anormal (mauvais paramétrage d'esayphp, import d'une BDD dans le mauvais jeu, copié-collé depuis un éditeur inadapté ou mal paramétré, etc.). Dans ton cas, je suppose qu'une incohérence en a accidentellement corrigé une autre Smiley cligne


Ta conclusion est plus que probable Smiley rolleyes

Je te remercie grandement pour ces explications, j'y vois maintenant un peu mieux sur ce sujet que je négligeais. C'est un tort !

Dès que je récupère mon ordi je vérifie mes fichiers et me penche sur le paramétrage des "outils".
boulaneige a écrit :
Question subsidiaire : comment savoir si un fichier a été encodé en utf-8 ou en iso-8859-1(5) ?

Si jamais tu es sous Linux, la commande file -i est ton amie:
file -i *
fonctions.php: text/plain; charset=us-ascii
form.php:      text/plain; charset=utf-8
list.php:      text/plain; charset=utf-8

Ca te donne l'encodage !

+
LD > une explication peut-être : c'était le premier post de la journée et hier soir je me suis couché à 3h
Pourquoi "ISO-8859-1" ne permettrait pas d'écrire :

œuf , cœlacanthe, fœtus, œsophage, sur ce forum ?

Quel rapport ? Smiley eek
Salut,

Et bon, je vais relire tout cela a tête reposée, ce qui veut dire que les réponses sont fortes intéressantes te méritent beaucoup de considérations...

Mais comme j'aime bien les cas d'école, voila l'adresse du site "Accueil internet du gouvernement français"
si on affiche le code source on lit que le site est en
iso-8859-1


et celui du gouvernement canadien (rédigé en français)
ou on lit:
"Content-Type" content="text/html; charset=utf-8">


Problème: un internaute français qui est en ... Asie Smiley lol ou au Brésil, veut lire ces pages dans un cyber café de Macao ou de Rio de Janeiro... Smiley lol .
Sachant que les cyber café de macao ou de Rio de Janeiro ont le même matériel informatique, dans laquelle de ces villes ces pages pourront être lue en moins de 5 secondes par l'internaute?

Question subsidiaire: A combien s'élève le nombre d'internaute au Brésil? à Macao? Smiley lol
Modifié par Vajra (18 Dec 2005 - 18:38)
EricLB a écrit :
Pourquoi "ISO-8859-1" ne permettrait pas d'écrire :

œuf , cœlacanthe, fœtus, œsophage, sur ce forum ?

Quel rapport ? Smiley eek


Ahem. Restons zen...

ISO-8859-1 ne permet d'écrire directement sous la forme :
<p>oeuf...</p>


Il oblige à écrire sous la forme :
<p>&oelig;uf...</p>

ou:
<p>&#339;uf...</p>


<edit>Oui, EricLB, tu as mis directement le caractère oe dans ton message, et il est passé... en rendant invalide cette page du forum, car dans ton message, il n'est pas encodé en ISO-8859-1, mais en Windows 1252, jeu de caractère incompatible avec Unicode, HTML, et qui te vaudra de produire des jolis carrés énigmatiques sur des navigateurs linux par exemple...

<re-edit>Qui s'y colle pour expliquer Windows 1252, le péché originel, le Mal, la damnation, l'enfer et tout ça ? Smiley langue
Modifié par Laurent Denis (18 Dec 2005 - 18:55)
Quentin:
a écrit :
LD > une explication peut-être : c'était le premier post de la journée et hier soir je me suis couché à 3h


Donc tu as anticipé dès le premier post, le coucher tardif? Smiley lol Smiley lol Smiley lol Smiley rofl
Pages :