Discussion :

[thelvin]

et effectuer les adaptations comme précisé par Alixe80 (jouer avec utf8_decode() avant traitement et utf8_encode() après

Cela n'est bon qu'à perdre les caractères qui ne sont pas gérés par ISO-8859-1.
Quand on en est arrivé à ce point-là de la conversion, c'est vraiment trop dommage de la perdre bêtement pour ça.

ou trouver et utiliser la fonction mb_ équivalente

C'est un meilleur conseil, je pense.

[Bisûnûrs]

en prévision de PHP6.. puisqu'il travaillera nativement en utf-8

Ouais .. ou pas.

[Fractaliste]

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 :

Code :

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

mysql_set_charset( 'utf8' );

Merci encore ; )

[Muchos]

Tuto complet et pertinent vu le nombre de questions relatives à ce génial encodage.

Quelques remarques néanmoins :

1. 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.
2. Pour html5, cette déclaration suffit :
   

   Code html :

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

   <meta charset="utf-8" />

[Bisûnûrs]

1. 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 ?

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

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.

[wallas07]

Chapeau un article très intéressant merci Bisûnûrs

[Muchos]

@wallas07
Tu peux aussi pertinenter le sujet pour qu'il ne soit pas remonté

[XXdiZZ]

Bonjour,

Depuis la v6 de N++, le menu "Format" a été remplacé par le menu "Encodage".

Merci pour ce tuto .

[renaud26]

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...
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.

[troumad]

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) :

Code :

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

1
2
3
4
5
6
<?xml version="1.0" encoding="UTF-8"?>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 Strict//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"  xml:lang="fr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Voici le /etc/apache2/conf-enabled/charset.conf du serveur (c'est du debian) :

Code :

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

1
2
3
4
5
6
7
8
9
# Read the documentation before enabling AddDefaultCharset.
# In general, it is only a good idea if you know that all your files
# have this encoding. It will override any encoding given in the files
# in meta http-equiv or xml encoding tags.
 
AddDefaultCharset UTF-8
#AddDefaultCharset ISO-8859-15
 
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Le .htaccess est :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#
# Uncomment the statement below if you want to make use of
# HTTP authentication and it does not already work.
# This could be required if you are for example using PHP via Apache CGI.
#
#<IfModule mod_rewrite.c>
#RewriteEngine on
#RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
#</IfModule>
 
<Files "config.php">
Order Allow,Deny
Deny from All
</Files>
 
<Files "common.php">
Order Allow,Deny
Deny from All
</Files>

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 :

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

1
2
3
$requete=mysqli_query($db,"SELECT `nom`,`id` FROM `add_sorts_magicien` WHERE $sph ORDER BY `nom`");
[...]
echo "<em><button value='".$row['id']."' onclick='change(".$row['id'].",this)'>".$row['nom']."</button></em>

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 :

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

1
2
3
4
5
6
7
8
9
10
11
12
if (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.

[Bisûnûrs]

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 php :

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

mysqli_set_charset('utf8');

Ou d'exécuter la requête :

Code sql :

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

SET NAMES "utf8";

[troumad]

À 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 :

Code :

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

<p> test : éèà.</p>

Elle s'affiche bien quand je demande l'affiche en unicode : mon fichier est bien sauvé en unicode.
Pour imposer l'utf lors des trasactions dans mon formulaire, j'avais du mettre :

Code :

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

<form action="mago.php#monstre" method='get' accept-charset='utf-8' >

[Bisûnûrs]

Je vois ça dans le code de ta page :

Code html :

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

1
2
3
<?xml version="1.0" encoding="ISO-8859-15"?>
 
<meta http-equiv="Content-Type" content="charset=ISO-8859-15">

Sachant que tu peux enlever le prologue XML sans problème.

[troumad]

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 :

Code :

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

1
2
3
4
5
6
l# curl -I localhost
HTTP/1.1 401 Unauthorized
Date: Thu, 01 Sep 2016 10:50:23 GMT
Server: Apache/2.4.10 (Raspbian)
WWW-Authenticate: Basic realm="Restricted Files"
Content-Type: text/html; charset=iso-8859-1

Même pas iso-8859-15...

[troumad]

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 :

Code :

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

1
2
3
4
; PHP's default character set is set to UTF-8.
; http://php.net/default-charset
default_charset = "UTF-8"
;default_charset = "ISO-8859-15"

Maintenant, il faut que je vois comment faire ça chez OVH...

[troumad]

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...

[clavier12AZQSWX]

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

[clavier12AZQSWX]

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.