Pour ce qui est des 2 premières lignes c'est un oublie de ma part.
elles ne devaient pas être là.
Mettre une explication sur la différence technique entre utf8 et latin, je ne suis pas contre.. mais je voulais faire le plus simple possible histoire de ne pas trop embrouiller les débutants.
Après, je peux tout à fait rajouter ce coté historique même si dans ce cas on peut très bien ne pas faire de FAQ et copier coller ce liens (qui ressort bien sur google vu que je l'avais aussi lu).

Quand à la structure.. Qu'est ce qui cloche au juste?

merci.

Ben pourquoi commencer par mysql ?

Normalement on devrait commencer par l'éditeur de texte, ensuite par html, puis apache/php et enfin mysql.

Sinon même si c'est reprendre de très près la présentation du lien (y'a pas de pb à copier les choses bien faites tant qu'on spécifie la source) on va plus vite à l'essentiel et c'est plus clair en disant

Si la page affiche des caractères de ce type : "é", "î", "Ã", ...
=> Les données ont été enregistrées au format UTF-8, et le navigateur les affiche en pensant avoir affaire à de l'ISO.

Si la page affiche des caractères de ce type : "�"
=> Les données ont été enregistrées au format ISO, et le navigateur les affiche en pensant avoir affaire à de l'UTF-8.

Si les données sont codées en dur dans la page, voir l'encodage de l'éditeur de texte, l'header apache et la balise meta "charset".
Si les données proviennent de la base, vérifier le format de stockage et les méthodes de lecture et d'insertion (SET NAMES et charset).
Si les données proviennent de l'extérieur (web services, rss, ...), penser à convertir les chaînes de caractère (utf8_encode-decode et fonctions du module iconv).

que

Voici quelques problèmes courants et leur solution :

Problème : Apparition de caractères tels que "Ã", "é" ...

Solution : Lorsque des caractères de ce type apparaisse, c'est que votre donnée est encodée en utf8 mai que le navigateur tente de lire en mode "normal" (latin1 ou iso-8859-1). Pensez à spécifier le méta html vu au dessus.

Problème : Apparition de caracètères comme "�" ...

Solution : Lorsque ce caractères apparait, c'est en fait l'inverse, notre navigateur est réglé pour lire de l'utf8 (via le méta html ou la fonction header() de php) mais tente de lire du texte qui est encodé normalement (latin1 ou iso-8859-1). Pensez à encoder votre fichier en utf8 ou utilisez la fonction utf8_encode() si vos données proviennent de l'extérieur (base de données, import de fichiers etc ...).

Ensuite sans rentrer dans les mêmes détails que la présentation du lien tu pourrais prendre l'essentiel à savoir
- l'avantage de l'utf-8 : permet d'afficher les caractères internationaux
- Sera bientôt l'encodage par défaut d'apache/php mysql
- Pose actuellement des pb avec certaines fonctions (à développer à la fin du tuto)

Hum...
Soit.

Je reprendrais du coup mon post un peu plus tard pour rendre ça plus "présentable".

Pour illustrer mes propos voici un lien que je trouve mieux structuré tout en étant plus complet http://electron-libre.fassnet.net/utf8.php

C'est le même lien que je m'apprêter à poster ^^

C'est également ce lien que je renvoi lorsqu'il y a cette question qui est posée, très fréquente je le confirme aussi

Pour reprendre la fin de mon dernier message, en préambule cela me semble le minimum que d'indiquer l'avantage de l'utf8 par rapport à l'iso. Cela va devenir la norme en effet mais c'est plus motivant d'indiquer pourquoi.

Autre remarque pour mysql, faudrait un exemple simpliste de création de la table, avec phpMyAdmin mais aussi avec du code que l'on peut copier coller dans une fenêtre sql

@yaug
Ce serait mieux de suivre les conseils de mere-teresa plutôt que de modifier ton post au fur et à mesure des remarques sinon tu n'en finiras jamais... ou dans très longtemps car il risque d'y avoir de nombreux post dans ce topic

Il est vrai que dans les citations de mon précédent message j'ai parlé de la forme et non pas du fond...
Je propose donc d'en revenir à l'essentiel pour l'instant

... Vous pouvez commencer à vous concerter sur ce que vous voulez voir apparaître dans une telle FAQ, et faire un plan ou une liste de questions.

Voici donc un plan à compléter/améliorer

• Préambule
  - l'avantage de l'utf-8 : permet d'afficher les caractères internationaux
  - Sera bientôt l'encodage par défaut d'apache/php mysql
  - Pose actuellement des pb avec certaines fonctions - à développer à la fin du tuto sous forme de faq.
  
  Développement
  - Configuration éditeur de texte
  - Configuration html
  - Configuration Apache/php
  - Configuration MySql
  
  Annexe
  - Problème avec certaines fonctions PHP http://www.phpwact.org/php/i18n/utf-8 (reprendre l'essentiel en français)
  - Problème de portage d'un code iso vers utf8 (vaste sujet), ce lien peut-être utile pour la partie html
  - Cohabitation utf-8 interne et données iso externes
  - Diagnostic des problèmes d'affichage

@jojolapine

Ne pourrais-tu pas éditer ton sujet pour un titre plus explicite du style "proposition tuto encodage utf-8" ?

Bon j'ai commencé une introduction :

• Apache, php et mysql travaillent encore aujourd'hui par défaut avec la norme ISO-8859-1. L'inconvénient de cette norme est qu'elle utilise un encodage des caractères ou symboles sur un octet soit seulement 256 possibilités.
  
  C'est pour dépasser cette limite et pouvoir faire afficher par exemple des caractères français et chinoix sur une même page qu'a été développé l'unicode et plus particulièrement l'UTF-8 très utilisé pour les applications Unix et Internet.
  
  L'UTF-8 peut encoder sur 1 à 4 octects et permet l'affichage de quasiment tous les caractères et symboles internationnaux. La future version PHP6 adoptera cette norme par défaut.
  
  Cette norme possède néanmoins les inconvénients de ses avantages : pour gagner de la place en mémoire certains caractères seront encodés sur un octet alors que d'autres le seront sur deux (caractères accentués français par exemple) ou plus. Or de nombreuses fonctions php de recherche sur les chaines de caractères retournent le nombre d'octects trouvés. Par exemple la fonction strlen('aé') retournera donc 3 sur une page codée en UTF-8 alors qu'elle est censée retourner la longueur de la chaine 'aé' soit une valeur attendue de 2.
  
  Il est donc important d'être homogène tout au long de la création de votre projet, de la configuration de votre outill de travail en UTF-8, à l'utilisation de fonctions adéquates au traitement des chaines multi-octets.

ça y est titre changé
Alors pour l'intro je trouve ça pas mal, (même bien ), juste par curiosité, est-ce que ça a un rapport l'utf-16/32 ? est-ce que ça serait utile de les mentionné içi? (j'en sais rien du tout hein c'est au hasard)

Le plan me parait bien également...
Dans les annexes, lorsque l'on parlera des problèmes de strlen et consort, il faudra présenter la librairie mbstring et ses possibilités (en attendant de passer à php6...)

Sinon dans l'ensemble, moi je vois rien à redire...

J'ai fait un lien vers Wikipédia pour ceux qui voudraient plus de détails concernant l'unicode, UTF-16, UTF-32.

L'idée est de faire quelque chose d'accessible, en séparant bien dans chaque rubrique les différentes solutions suivant que l'on a accès ou non à la configuration du serveur.
Si tout le monde est d'accord sur ce type de présentation, chacun pourra commencer à faire une rubrique qui sera cohérente avec le reste.

Mais avant de poursuivre il faudrait plus de retours, notamment sur le plan

• Apache, php et mysql travaillent encore aujourd'hui par défaut avec la norme ISO-8859-1. L'inconvénient de cette norme est qu'elle utilise un encodage des caractères ou symboles sur un octet soit seulement 256 possibilités.
  
  C'est pour dépasser cette limite et pouvoir faire afficher par exemple des caractères français et chinoix sur une même page qu'a été développé l'unicode et plus particulièrement l'UTF-8 très utilisé pour les applications Unix et Internet.
  
  L'UTF-8 peut encoder sur 1 à 4 octects et permet l'affichage de quasiment tous les caractères et symboles internationnaux. La future version PHP6 adoptera cette norme par défaut.
  
  Cette norme possède néanmoins les inconvénients de ses avantages : pour gagner de la place en mémoire certains caractères seront encodés sur un octet alors que d'autres le seront sur deux (caractères accentués français par exemple) ou plus. Or de nombreuses fonctions php de recherche sur les chaines de caractères utilisent le nombre d'octets trouvés. Par exemple la fonction strlen('aé') retournera donc 3 sur une page codée en UTF-8 alors qu'elle est censée retourner la longueur de la chaine 'aé' soit une valeur attendue de 2.
  
  Il est donc important d'être homogène tout au long de la création de votre projet, de la configuration de vos outils de travail en UTF-8, à l'utilisation de fonctions adéquates au traitement des chaines multi-octets.

Configurer votre outil de travail

• Il est indispensable d'enregistrer vos fichiers en choisissant l'encodage UTF-8, par exemple :
  
  - Eclipse : Window > préferences > Géneral > WorkSpace > boite "Text file encoding"
  - Notepad++ : Paramétrage > Nouveau document. Pour modifier le document courant : Format > "Encoder en UTF8"
  - Zend Studio : Tools > Desktop > Apparence
  - Dreamweaver : Edition > Préférences > Nouveau document > Codage par défaut
  - Bloc notes window : Enregistrer sous > codage
  
  Dans tous les cas si cela vous est proposé, ne pas inclure une signature unicode BOM

Configuration des entêtes

• HTML
  Il vous suffit d'indiquer le charset dans une balise meta à la suite de la balise head

  Code : Tout sélectionner

  <head> <meta http-equiv="Content-type" content="text/html; charset=UTF-8"/> ... </head>
  Cette ligne doit logiquement être la première suivant la balise <head> puisqu'elle indique au navigateur l'encodage utilisé.
  Attention, l'entête envoyée par le serveur sera prioritaire sur cette déclaration html
  
  
  APACHE
  Comme mentionné en préambule, le serveur apache envoie (généralement pour l'instant) des entêtes à la norme ISO-8859-1.
  - Si vous avez accès à la configuration du serveur > httpd.conf, ajoutez l'une ou l'autre des lignes

  Code : Tout sélectionner

  AddDefaultCharset UTF-8 #ou AddDefaultCharset Off
  Avec la deuxième solution le serveur se renseigne sur l'entête http et sera donc en cohérence avec le charset indiqué dans la page html.
  
  - Sans accès à la configuration du serveur vous pouvez mettre l'une ou l'autre des lignes ci-dessus dans un fichier .htacces
  
  - Sinon indiquez au début de vos pages php

  header('Content-Type: text/html; charset=UTF-8');

  Cette dernière solution permet un meilleur portage de vos scripts.

PHP

• Configuration php.ini
  Le module "mbstring" s'occupe de la manipulation des chaînes tandis que le module "iconv" permet de convertir différents types d'encodages.
  Les conversions entre ISO et UTF-8 peuvent se réaliser à l'aide des fonctions utf8_encode() et utf8_decode().
  Dans la plupart des cas vous n'aurez pas à intervenir sur la configuration du php.ini.
  
  Utilisation des fonctions de traitement des chaines multi octets
  Pour reprendre l'exemple initial, mb_strlen() sera utilisée à la place de strlen().
  Liste des fonctions adaptées au traitement des chaines UTF-8
  
  PHP travaille pour l'instant en ISO, il faudra donc spécifier l'encodage utilisé pour les fonctions qui le demande ou modifier l'encodage initial.
  
  Typiquement :

  echo mb_internal_encoding(); //affiche  ISO-8859-1 
  echo mb_strlen('aé');// affiche 3
  echo mb_strlen('aé',"utf-8");// affiche 2
  
  mb_internal_encoding("UTF-8");// indique d'utiliser l'encodage UTF-8
  echo mb_strlen('aé');// affiche 2

MySql

• Pour MySql comme pour toute autre base de donnée il est préférable de créer votre base en spécifiant l'encodage utf8_general_ci.
  Cette possibilité est cependant rarement disponible sur les serveurs mutualisés. Pour contourner ce problème et une meilleure portabilité de votre code, vous pouvez indiquer l'encodage à utiliser en envoyant la requête "SET NAMES UTF8" juste après la connexion à votre base.

  mysql_select_db($database, $connection);
  mysql_query("SET NAMES 'utf8'");

  Vos tables doivent également être créées en utilisant l'Interclassement utf8_general_ci via phpMyAdmin ou dans une fenêtre sql :

  Code : Tout sélectionner

  CREATE TABLE IF NOT EXISTS `membres` ( `pseudo` varchar(100) NOT NULL, `pass` varchar(100) character set utf8 collate utf8_bin NOT NULL, PRIMARY KEY (`pseudo`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
  Dans cet exemple le champ "pass" est formaté avec "collate utf8_bin" pour être sensible à la casse.

FAQ

• Problèmes d'affichage
  Si la page affiche des caractères de ce type : "é", "î", "Ã", ...
  => Les données ont été enregistrées au format UTF-8, et le navigateur les affiche en pensant avoir affaire à de l'ISO.
  
  Si la page affiche des caractères de ce type : "�"
  => Les données ont été enregistrées au format ISO, et le navigateur les affiche en pensant avoir affaire à de l'UTF-8.
  
  Si les données sont codées en dur dans la page, voir l'encodage de l'éditeur de texte, l'header apache et la balise meta "charset".
  Si les données proviennent de la base, vérifier le format de stockage et les méthodes de lecture et d'insertion (SET NAMES et charset).
  Si les données proviennent de l'extérieur (web services, rss, ...), penser à convertir les chaînes de caractère (utf8_encode-decode et fonctions du module iconv).
  
  Utilisation de fonctions pouvant poser problème avec les chaines multi octet
  Erreurs courantes
  - strtr() => utilisez str_replace()
  - htmlentities() => spécifiez le charset utf-8 ou mieux utilisez htmlspecialchars()
  - strpos(), strlen(), substr() etc. => utilisez les fonctions adaptées au traitement des chaines UTF-8
  Consultez ce lien http://www.phpwact.org/php/i18n/utf-8
  
  Migration d'un site d'ISO-8859-1 vers UTF-8
  En plus des conseils ci-dessus ce lien peut vous être utile

Ce tuto a été réalisé en s'inspirant de http://electron-libre.fassnet.net/utf8.php et http://www.phpfrance.com/forums/voir_re ... php#272340

Hum.
Cela me parait un bon début mais me semble tout de même un peu... light non?
Ce n'est pas un reproche hein, juste que je trouve qu'il faudrait étoffer un peu pour chaque paragraphe en expliquant le pourquoi notamment.
Non ?

Du genre

IL est indispensable d'enregistrer vos fichiers en choisissant l'encodage UTF-8. Si vous souhaitez travailler avec de l'utf8 mais que vos fichiers sont encodé en latin1 par exemple, vous aurez alors de nombreux problèmes d'affichage.

La plupart des éditeurs vous permettront de gérer l'encodage de vos fichiers. Voici une liste non exhaustive des éditeurs et de l'endroit ou modifier l'encodage :

- Eclipse : Window > preferences > General > WorkSpace > boite "Text file encoding"
- Notepad++ : Paramètrage > Nouveau document. Pour modifier le document courant : Format > "Encoder en UTF8"
- Zend Studio : Tools > Desktop > Apparence
- Dreamweaver : Edition > Préférences > Nouveau document > Codage par défaut
- Bloc notes window : Enregistrer sous > codage


Dans tous les cas si cela vous est proposé, ne pas inclure une signature unicode BOM
Faites de plus attention à bien commencer tous vos projets directement en utf8, cela vous évitera de nombreux problèmes par la suite.

Ce n'est bien sur qu'un exemple, mais je pense qu'il faut quelques petites explications à chaque fois.
non?

OK, pour tenir compte de ta remarque tout en étant pas trop redondant, j'ai modifié l'introduction.

Bon ça se bouscule pas trop pour les remarques...

Une raison à cela pourrait être que vous travaillez en mode "décousu", avec des morceaux répartis sur plusieurs pages (difficile d'imaginer l'ensemble). Tu sembles être le seul avec yaug à avoir une vision globale du tuto fini

Une remarque cependant, que j'espère constructive : j'aime bien le côté court et pratique du tuto initial de yaug, il est assez digeste pour être lu en entier d'une seule traite. Comme on va immanquablement renvoyer les gens vers ce tuto, je pense qu'il serait bon de ne pas trop l'alourdir (pour qu'il conserve cette qualité), selon moi il ne faudrait pas que les réponses concrètes qu'il contient soient noyées dans un article pseudo-exhaustif sur les encodages.

Je prône donc le côté pratique (problème->solution) et la non-réinvention de la roue, en me mettant à la place d'un développeur PHP dans le besoin et en attente d'une réponse à son problème. On peut toujours faire des liens vers d'autres ressources plus complètes pour le lecteur qui voudrait en apprendre +.

Oui mais avant d'avoir une faq, il est important d'avoir une présentation d'ensemble.

J'avais fais un plan plus haut. Par rapport à ce que j'ai fait, il ne reste plus à faire que la configuration de php et mysql avant l'annexe dans laquelle on pourrait mettre la FAQ.

Tu trouve cette présentation vraiment trop longue ?

Je rappelle le plan dont je disais qu'il était à compléter/améliorer.
Pour que le visiteur puisse avoir accès directement à ce qui l'intéresse on pourrait mettre le plan avant l'introduction.

• Préambule
  - l'avantage de l'utf-8 : permet d'afficher les caractères internationaux
  - Sera bientôt l'encodage par défaut d'apache/php mysql
  - Pose des pb avec certaines fonctions - à développer à la fin du tuto sous forme de faq.
  
  Développement
  - Configuration éditeur de texte
  - Configuration html
  - Configuration Apache
  - Configuration PHP
  - Configuration MySql
  
  Annexe
  - Problème avec certaines fonctions PHP http://www.phpwact.org/php/i18n/utf-8 (reprendre l'essentiel en français)
  - Problème de portage d'un code iso vers utf8 (vaste sujet), ce lien peut-être utile pour la partie html
  - Cohabitation utf-8 interne et données iso externes
  - Diagnostic des problèmes d'affichage

Ajouté la partie PHP.

J'essaie d'être assez concis tout en mentionnant le minimum essentiel. http://www.phpfrance.com/forums/voir_re ... php#272609 ...