Version imprimable
Hello,
Je vous présente mon nouveau tutoriel qui va vous guider dans le passage d'un site en UTF-8 en reprenant toutes les étapes à ne pas manquer, ainsi que les différentes alternatives en fonction de votre environnement de travail.
N'hésitez pas à me faire part de vos remarques, questions et suggestions dans cette discussion.
Bonne lecture à tous !
Salut !
Merci pour cet excellent (comme toujours :mrgreen:) tutoriel qui permettra à beaucoup de mieux comprendre la chaîne complète de l'encodage des caractères.
Je pense que c'est effectivement une ressource qui manquait !
:merci:
:ccool:
Bravo et merci pour ce document! On aura enfin un lien vers lequel pointer lorsque la question sera posée.
Bravo pour cet article !
Les explications sur l'encodage UTF8 general et unicode sur MySQL étaient bienvenues.
Bien penser à en faire de même pour les traitements AJAX.
+1... ;)Citation:
Envoyé par Macmillenium
Bonjours,
j'ai deja subit un site qui tentait de faire de l'utf-8.
Le probleme étant que, par exemple, les données reçues via post/get étaient en latin1. Sur ce site, il fallait donc faire des utf8_encode() à tout bout de champ...
Par curiosité, ce memo résout-il le pb, et si oui, à quel niveau?
(j'ai survolé l'article sans trouvé de réponse)
@hansaplast : Personnellement je n'ai vu aucun soucis de ce type dans mes tests. Les développeurs du site sur lequel tu bossais avaient dû louper une (ou plusieurs) étape, comme l'enregistrement du fichier en UTF-8 sans BOM par exemple.
Si on prend ce code et qu'on enregistre le fichier en UTF-8 sans BOM, on peut voir qu'il n'y a pas de soucis d'accent :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Après, comme dit dans mon tutoriel, si tu étais obligé d'utiliser utf8_encode() pour afficher correctement des caractères encodés en UTF-8, c'est que ton serveur renvoyait de l'ISO.
Bref, plusieurs pistes à approfondir pour résoudre ton problème.
Et si tu as l'occasion de démontrer qu'il manque quelque chose à ce niveau là dans le tutoriel avec un exemple que tu avais à l'époque et qui ne fonctionne toujours pas en ayant apporté les modifications nécessaires, tu peux toujours nous en faire part pour qu'on corrige le tutoriel. :P
Bonjour
Je vient de tomber sur le tutoriel qui est plutôt pas mal, mais je ne comprend pas l'Intérêt d'utiliser utf8_decode ou utf8_encode si tout le site passe en utf-8.
L'Intérêt d'utiliser l'encodage ou le décodage est pour les endroit du site qui ne sont peut être PAS en utf-8... non?
Désolé si je me trompe, ou si j'ai mal compris l'utilisation dans le tutoriel/cour.
Sky
ok, alors je pense que le souci devait venir de làCitation:
Envoyé par Bisûnûrs
non non, je me renseignait juste :)Citation:
Envoyé par Bisûnûrs
et merci :)
Merci beaucoup pour ce tuto qui éclaire un sujet quasiment pas traité à ma connaissance.
Un petit plus pour les utilisateurs de Notepad++ :ccool:: pensez à choisir le bon encodage pour les nouveau documents "Paramétrage | Préférences | nouveau document" et cocher UTF-8 sans BOM. Ca évite de devoir rechercher quel script a échappé à cet encodage surtout lorsqu'il y a de nombreuses inclusions.
Néanmoins, cette manipulation n'est pas toujours de bon aloi notamment si vous faites usage de la librairie fpdf qui ne supporte pas l'UTF-8 jusque dans sa version 1.6 :roll:. Il vous faudra alors décoder chaque chaîne vers de l'ISO grâce à utf8_decode.
Merci également pour les précieux conseils et tuyaux.
Attention que php travaille en ISO ce qui signifie que les fonctions de manipulation de caractères classiques (ucfirst, strlen, strtolower...) ne fonctionnent pas si on manipule des chaines encodées en utf8...
Il est intéressant à ce moment là de repasser la chaine de utf-8 vers ISO et inversément ensuite en utilisant utf8_encode() et utf8_decode()...
Ou il faut installer et configurer le module mbstring ...
Dommage que le tutoriel n'en parle pas car j'ai lu ça ailleurs mais j'aurais aimé plus d'infos quant à ce module... ou ce qu'il est mieux de faire...
Vivement php 6 qui lui travaillera en UTF-8 ;)
Ce bout de code convertit de l'UTF-8 dans le buffer de sortie de PHP vers de l'ISO.Code:
2
3
4iconv_set_encoding('internal_encoding','utf-8'); iconv_set_encoding("output_encoding", "iso-8859-1"); ob_start('ob_iconv_handler');
J'aime bien aussi utiliser le buffer de sortie de PHP pour appliquer ce genre de traitements, il est tout à fait fait pour ça ^^
Le principe d'utf-8 n'est-il pas justement qu'il contient tous les caractères du monde alors qu'ISO n'en contient que 250, et qu'on ne peut donc pas convertir l'utf-8 vers l'ISO ?Citation:
Envoyé par Alixe80
Bonjour et merci pour ce tutoriel ! (et bonne année aussi)
Dans l'éditeur PHPEdit (v3.4.4) :
- option des nouveaux fichiers : Outils > Editer préférences ou F10, Menu Fichiers et copies de sauvegarde, options des fichiers, section type d'encodage
- enregistrement d'un fichier ouvert en UTF8 : Fichier > Encodage de fichier > UTF-8
Sinon ne pas oublier dans les formulaires accept-charset="utf-8" exemple :
Pour moi tout a très bien fonctionné, ça m'a évité d'utiliser htmlentities (car en plus j'empêche d'insérer des caractères spéciaux du type < et >) et j'ai aussi pu mettre des accents dans les commentaires et les voir affichés dans le HTML généré par doxygen.Code:
2<form name="logon" action="index.php" method="post" title="Identification" accept-charset="utf-8">
?Citation:
Envoyé par stundman
C'est vraiment utile dans des cas précis, ou c'est pour la beauté du geste et la complétude par principe de l'information ?
Bonsoir,
je n'avais jamais vu de propriété accept-charset. Pour m'être renseigné, cela ne fonctionne pas avec IE. Donc, c'est une notion à ne pas prendre en compte quand on souhaite être cross-browser.
Si on en croit cette page :Citation:
Envoyé par stundman
http://giminik.developpez.com/xhtml/form.html
cet attribut n'agit pas sur l'encodage lors du transfert de données vers le serveur, mais décrit seulement ceux qui sont lus par le serveur (preuve en est, on peut en mettre plusieurs). Donc effectivement il n'est pas très utile, sauf à des fins descriptives.
Mais sinon merci pour les autres remarques, je vais essayer de les prendre en compte rapidement. ;)
:ccool:
Merci beaucoup pour ce tuto ! après une journée entière à galérer avec l'encodage sur mon site, j'en pouvais plus.
Maintenant je mettrais tout en UTF-8 !!
Et donc en pratique, il faut ouvrir tous les fichiers PHP et rechercher toutes les fonctions de traitement de chaine et les fonctions PCRE (par exemple preg_match) (avec notepad++ par exemple) susceptible de traiter des caractères accentués, et effectuer les adaptations comme précisé par Alixe80 (jouer avec utf8_decode() avant traitement et utf8_encode() après, ou trouver et utiliser la fonction mb_ équivalente).Citation:
Envoyé par Alixe80
En pratique encore, je conseille de tagger chaque modif dans un commentaire (pour les retrouver facilement avec notepad++) en prévision de PHP6.. puisqu'il travaillera nativement en utf-8 : il faudrat alors supprimer tout les utf8_encode() et utf8_decode().. un futur tracas de moins 8-). Pour les fonctions mb_string, je suppose qu'elles seront supportées par PHP6..:zen:
Cela n'est bon qu'à perdre les caractères qui ne sont pas gérés par ISO-8859-1.Citation:
Envoyé par gomodo
Quand on en est arrivé à ce point-là de la conversion, c'est vraiment trop dommage de la perdre bêtement pour ça.
C'est un meilleur conseil, je pense.Citation:
Envoyé par gomodo
Ouais .. ou pas.Citation:
Envoyé par gomodo
Merci pour ce tuto ! Cela fait bien 4 ou 5 heures que je googelise dans tous les sens mon problème d'encodage pour une application XMLhttpRequest.
Dans de nombreux autre sites on retrouve exactement les mêmes conseils, mais ce qui a fait la différence c'est le :
Merci encore ; )Code:mysql_set_charset( 'utf8' );
Tuto complet et pertinent vu le nombre de questions relatives à ce génial encodage.
Quelques remarques néanmoins :
- Pourquoi proposer l'usage de utf8_decode() ? Si on passe en full utf8, transférer des données en utf8 vers de l'utf8 en passant par de l'ISO ne semble pas avoir d'intérêt, non ? Thelvin a aussi émis des doutes sur son utilisation, et ce n'est pas la première fois que j'en lis.
- Pour html5, cette déclaration suffit :
Code:<meta charset="utf-8" />
Si tu relis bien, je ne propose utf8_decode() que comme une solution alternative, puisqu'en l'utilisant on ne dit pas au serveur d'afficher de l'UTF-8. La solution du header reste elle-même une alternative à la configuration Apache, configuration qui n'est malheureusement pas permise sur tous les serveurs (mutualisés).Citation:
Envoyé par Muchos
Et si je n'avais pas mis la solution uft8_decode(), on m'aurait dit "mais on peut faire comme ça aussi !", donc j'ai préféré prendre les devants, en disant que ce n'est pas la meilleure méthode pour gérer un site encodé en UTF-8.
Ce tuto a de toute façon besoin de quelques rafraichissements, notamment pour parler de PDO.
Chapeau :ccool: un article très intéressant merci Bisûnûrs ;)
@wallas07
Tu peux aussi pertinenter le sujet pour qu'il ne soit pas remonté ;)
Bonjour,
Depuis la v6 de N++, le menu "Format" a été remplacé par le menu "Encodage".
Merci pour ce tuto ;).
Bonjour, je viens de lire très attentivement ton excellent tuto, j'y ai trouvé quelques soluces à des problèmes que je trouvais depuis longtemps, c'est cool.
J'aurais cependant une question :
J'ai une table mal encodée. Son interclassement est utf8_general_ci et chaque champ l'est aussi.
Cependant les champs de type texte sont corrompus et dans phpMyAdmin, je vois des Téléphone...
J'ai réussi en local, à force de manips (modifier le type de champ de varchar à text, modifier l'interclassement, exporter en 8859-1 (ou utf-8 ?), modifier l'encodage avec notepad++, importer en iso ou UTF8 ?....) et ça a finalement réparé les caractères accentués tout en maintenant l'interclassement utf8_general_ci. Côté affichage site, j'ai résolu les maudits ? grâce à ton astuce mysql_set_charset( 'utf8' );
Et les INSERT sont impeccables sans traitement !
Le problème, c'est que j'ai tellement fait de manips que je ne sais plus reproduire l'opération...:aie:
Pourrais-tu me dire la manip step by step pour réparer la table et surtout faire en sorte que les prochains INSERT donnent "téléphone" sans que j'aie recours à des utf8_encode ?
Je t'en remercie d'avance et encore bravo.
Bonjour
J'ai un problème avec un site en interne. Il me semble tout avoir fait pour que l'encodage soit de l'UTF-8. Mais, ça ne passe pas : je dois obliger firefox de l'affiche en unicode pour que ça passe (utf-8 est bien de l'unicode ?).
Voici l'entête du fichier (c'est du php) :
Voici le /etc/apache2/conf-enabled/charset.conf du serveur (c'est du debian) :Code:
2
3
4
5
6
Le .htaccess est :Code:
2
3
4
5
6
7
8
9
Les champs de ma base de données sont en varchar(255) utf8_general_ci . Et mes requêtes pour lire la base de données sont de la forme :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Cet ensemble de page marche très bien chez ovh, mais la version de test chez moi ne passe pas les accents. Il y a un point de différence que je peux donner pour vous aider peut-être, un point de fonctionnement différent entre les deux serveurs :Code:
2
3
Code:
2
3
4
5
6
7
8
9
10
11
12if (isset($_GET['recherche'])) { $recherche=$_GET['recherche']; } else { $recherche=""; } [...] $requete=mysqli_query($db,utf8_decode("SELECT `nom`,`id` FROM `add_sorts_magicien` WHERE `nom` LIKE '%".$recherche."%' ORDER BY `nom`")); // ce code marche chez ovh //$requete=mysqli_query($db,"SELECT `nom`,`id` FROM `add_sorts_magicien` WHERE `nom` LIKE '%".$recherche."%' ORDER BY `nom`"); // ce code marche chez moi.
Hello, a priori il te manque la communication UTF-8 entre la base de données et le script PHP. Pour cela, il te suffit d'appeler cette fonction juste après la sélection de la base de données :
Code:mysqli_set_charset('utf8');
Ou d'exécuter la requête :
Code:SET NAMES "utf8";
À priori, ça ne change rien. Ceci dit, je ne suis pas très surpris, car le problème semble plutôt venir de la réception au niveau de mon PC : il ne prend pas par défaut le mode unicode pour ce document.
je viens de faire un test de plus qui me semble encore plus déroutant, je commence à me perdre dans tout ce fatras ! Le document qui marche (serveur OVH) n'est pas affiché en unicode non plus par défaut :(
Je regarde avec chrome : il me dit que le document d'OVH ( http://dnd.siaud.org/mago.php?sort=&...%C3%A9#monstre ) est affiché en iso-8859-15 (choix par défaut) pour que ça marche. Par contre le paramètre "élé" passé en utf-8 est bien décodé comme il se doit, mais il est mal affiché.
Mon document interne de test est aussi affiché en iso-8859-15 (choix par défaut) et pour que ça marche, je dois le faire afficher en utf-8 .
Bilan : je pense tout avoir configurer pour l'utf-8 et je reçois de l'iso !!!
nb : pour test, j'ai rajouté une ligne dans mon code html :Elle s'affiche bien quand je demande l'affiche en unicode : mon fichier est bien sauvé en unicode.Code:<p> test : éèà.</p>
Pour imposer l'utf lors des trasactions dans mon formulaire, j'avais du mettre :Code:<form action="mago.php#monstre" method='get' accept-charset='utf-8' >
Je vois ça dans le code de ta page :
Code:
2
3
Sachant que tu peux enlever le prologue XML sans problème.
Bon... Ceci me permet de comprendre que le peu de chose que je croyais comprendre, ça ne marche pas :(
Parce que, la page qui marchait, marchait parce que j'avais oublié de faire la mise à jour de l'entête... Maintenant que tout est bien configuré pour l'UTF-8, ça ne marche plus !
Je regarde un coup du côté du serveur OVH ce que donne la configuration.
Et tant qu'on y est, autant embrouiller encore plus les pistes :Même pas iso-8859-15...Code:
2
3
4
5
6
C'est corrigé sur mon serveur perso. Il reste à voir sur OVH maintenant...
Dans le fichier /etc/php5/apache2/php.ini j'ai inversé les lignes commentés :
Maintenant, il faut que je vois comment faire ça chez OVH...Code:
2
3
4
Avec la doc, je suis passé de php 5.2 à php 7 : https://docs.ovh.com/fr/fr/web/hosti...bergement-web/
Comme à partir de php 5.5, c'est utf-8 qui est par défaut, c'est bon... Il va falloir que je regarde ce que ça génère sur les autres pages...
bonjour,
l'article est bien pédagogique, bravo il cerne les bases.
par contre il manque le traitement du charset dans 2 cas :
le mien dont je parle là-bas
https://www.developpez.net/forums/d2.../#post11816837
c-a-d le passage de données en fichier via un lien A data: contenant la chaine... sans avoir besoin d'un serveur.
et le traitement dans du POST/GET dans un formulaire en utilisant "application/x-www-form-urlencoded; charset=utf-8" ou l'attribut accept-charset dans les balises FORM :
https://www.w3schools.com/tags/att_f...pt_charset.asp
bonne continuation
très bon document.
je vois qu'il date de 2010, ce serait bien de la compléter ou de mentionner l'existence du mb4 utf8 également.