Discussion :

[-DeN-]

Bonjour!

Je sais que ce sujet a déjà été discuté, mais j'aimerais relancer le débat afin de bien clarifier les choses concernant l'encoding des caractères pour un site.
Trop souvent, on voit des personnes avoir des problèmes avec l'encoding, surtout lorsque les données proviennent de bases de données, et d'autant plus s'il diffère de celui du site.

On se retrouve ensuite à encoder les informations pour les insérer dans la BD (é => é etc)

Pour ma part, qui monte un site utilisant des caractères français, j'utilise:
- pour mon site iso-8859-1
- mes bases de données sont en latin1_general_ci.

Je n'ai absolument aucun problème avec les accents. Lorsque je fais des echo "éàèç" ça marche. Si j'écrit en brute éèàç dans mon code html aussi, ça s'affiche correctement dans le browser. [EDIT: car toléré par les navigateurs]

MAIS

j'ai souvent vu que des gens utilisent utf-8. avantages, inconvéniants?
J'aimerais connaître votre philosophie, iso ou utf? Et pourquoi?

[Yogui]

Salut

Je ne suis pas une pointure sur ce sujet, alors mon avis vaut ce qu'il vaut.
Je pense qu'UTF8 n'a d'intérêt que si tu comptes proposer ton site dans plusieurs langues, en particulier si certaines de ces langues ont un alphabet très particulier. En ce cas, oui, UTF8 est utile pour uniformiser l'affichage du texte.
En revanche, si tu as un site latin, je pense que ton ISO8859-1 est suffisant.

Maintenant, il semble que la tendance soit au passage à UTF8 (ou 16).

[GrandFather]

Bonjour,

Pour une application Web écrite en PHP pour un contexte purement francophone, je ne vois pas l'intérêt de passer en Unicode. Par contre, quel que soit le choix du codage des caractères, il se doit d'être homogène pour tout le site (sources PHP, CSS, fichiers XML, SGBDR,...) afin d'éviter les opérations d'encodage/décodage plutôt coûteuses en termes de performances.

[zulkifli]

L'encodage est un thème assez étranger pour moi.
Je developpe actuellement un site multilangues, avec au menu du Japonais. Je crois que UTF8 sera approprié à mon cas. Donc d'après toi GrandFather je devrai tous homogéniser, encoder mes script en UTF8, collation UTF8 pour la bdd,... pour ne pas perdre de performances. C'est deja une bonne info.

Est ce qu'ensuite un simple <meta http-equiv="Content-type" content="text/html; charset=utf-8" /> servira pour que le navigateur utilise ce charset?
Car j'ai lu que apache envoie les pages html deja codé en iso-8859-1 et que si l'on ne peut modifier la config d'apache, on doit passer par un .htacces ou indiquer explicitement l'encodage utilisé avec la fonction "header()" de PHP.
Des infos la dessus?

[Invité]

perso je pensais comme toi GrandFather au depart, mais j'ai developpé un forum où parfois quelqu'un poste un copier/coller de word (avec des apostrophes particulieres) ou meme de temps en temps un caractere japonais (je pensais pas que ça pourrait arriver vu que mon site n'est pas dedié au Japon, mais le cas s'est presenté et je me suis trouvé con ).

donc la prochaine version de mon site sera en UTF-8, et comme tu dis il faut bien encoder chaque fichier au depart (d'où l'utilisation d'un editeur de code facilement parametrable comme jEdit), ça evite les encodages à repetition (zulkifli, ça repond à ta question : tu n'as pas besoin de dire à Apache d'encoder tes pages HTML si tes sources HTML/PHP sont deja encodées )...

voilà, moi maintenant je considere que l'UTF-8 est le seul veritable standard qui evote tout probleme dans le cas d'un site où on permet à l'utilisateur de rentrer ce qu'il veut... 8)

[-DeN-]

Oki doki, le passage à UTF-8 (vu ce que je lis ici et sur d'autres sites/forums) est l'avenir!

[macbook]

Je pencherais aussi pour UTF-8 dans le sens où cet encodage est plus complet que l'ISO-8859-1.

[Séb.]

Perso j'attends PHP6 qui supportera complètement Unicode / UTF-8.
Pour le moment un strlen($chaineEnUTF) et toutes les fonctions de manip de données retournent des valeurs potentiellement erronées => il faut passer par mb_strlen( ) & cie http://www.php.net/mbstring.php, et je ne parle pas du include/require qui envoie le BOM au client.

Pour ta question plus haut à propos de la <meta> : non ça ne suffit pas, il faut que le serveur envoie le charset adéquat dans le header HTTP Content-Type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Content-Type: text/html; charset=UTF-8

Tu peux faire cela avec la fonction header( ) ou en configurant correctement ton serveur web.

[Death83]

Moi je suis plus pour l'iso car apparement avec l'ut8 il y a des petit soucis de classement dans les base de donnée pour ceux qui les utilisent.

[francis m]

bien d'accord avec death83 : j'ai eu quelques problèmes de ce genre (de mémoire comme des é qui se classent avant les a), donc je suis passé en iso pour mon site et latin1 pour mes bdd

[zulkifli]

@séb

merci pour mbstring
j'ai fait un petit test et pour une chaine encodé en UTF-8 (provenant de la bdd)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
$res->VARCHAR qui a pour valeur 'répété'
mb_strlen($res->VARCHAR,'UTF-8') renvoit 6
strlen($res->VARCHAR) renvoit 9

Ok j'utiliserai mbstring pour les chaine en UTF-8 mais que veut tu dire par

et je ne parle pas du include/require qui envoie le BOM au client.

pour ce qui est de la bdd, lorsque j'extrait du text encodé UTF-8, j'obtient des signe bizare pour les accents même si j'ai placé un header( "Content-Type: text/html; charset=UTF-8" ); je ne comprends pas.
Par contre avec un mysql_query( "SET CHARACTER SET utf8" ); tout s'affiche correctement même sans header. Donc dans ce cas le header est inutile?
je nage

[-DeN-]

Non le header est utile, il faut toujours le mettre afin de "dire au navigateur quel encoding est utilisé par le site".

Pour BOM, ça veut dire Byte Order Mark. Par contre les explications que j'ai trouvées ne m'éclairent pas bcp. Y a pas des mots simples?

Sinon merci pour mb_string. Par contre, pour les arrays, comment les trier

[zulkifli]

Ok j'ai compris l'header était inutil vu que j'avais placé la <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> car si je met <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> la sa ne va plus.

[Séb.]

que veut tu dire par

et je ne parle pas du include/require qui envoie le BOM au client.

Le BOM est une suite d'octets placée automatiquement en début de document par ton éditeur de textes et qui sert à indiquer l'ordre des octets dans le document (big-endian, little-endian).
Bon le problème est que puisque le BOM est hors des balises <?php ?> PHP va l'envoyer au client lors d'un include, comme du HTML.
1.) Le client va se retrouver avec deux zigouigouis
2.) Tu ne pourras pas faire de header('Location: [...]') puisque la page aura commencé à transiter
Une solution consiste à paramétrer l'éditeur de manière à ce qu'il n'enregistre pas le BOM (on peut le faire avec UltraEdit et d'autres). Mais est-ce une solution pérenne ? Pas sûr => Je préfère attendre PHP6 qui mettra tout à plat.

http://www.unicode.org/faq/utf_bom.html#BOM

[zulkifli]

C'est pour sa alors que mes header ne marche plus depuis que j'ai encodé mes script en UTF-8 (avec SciTe)!

merci séb

[zulkifli]

Une solution consiste à paramétrer l'éditeur de manière à ce qu'il n'enregistre pas le BOM (on peut le faire avec UltraEdit et d'autres). Mais est-ce une solution pérenne ? Pas sûr => Je préfère attendre PHP6 qui mettra tout à plat.

http://www.unicode.org/faq/utf_bom.html#BOM

Donc avec SciTe c'est File -> Encoding -> UTF-8 Cookie
Maintenant mes header refonctionnent

EDIT
Le seul inconvénient c'est qu'en on réouvre le fichier, SciTe ne détecte plus l'encodage. Donc petite astuce que je viens de trouver grâce à l'ami google

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
<? 
	# coding: utf-8 
	header( "Content-Type: text/html; charset=UTF-8" ); 
?>