UTF-8 d'un bout à l'autre

Stockage des données :

Spécifiez le utf8mb4 jeu de caractères sur toutes les tables et colonnes de texte de votre base de données. Cela permet à MySQL de stocker et de récupérer physiquement les valeurs encodées nativement en UTF-8. Notez que MySQL utilisera implicitement utf8mb4 encodage si un utf8mb4_* le classement est spécifié (sans jeu de caractères explicite).
Dans les anciennes versions de MySQL (<5.5.3), vous serez malheureusement obligé d'utiliser simplement utf8 , qui ne prend en charge qu'un sous-ensemble de caractères Unicode. J'aimerais plaisanter.

Accès aux données :

Dans votre code d'application (par exemple PHP), quelle que soit la méthode d'accès à la base de données que vous utilisez, vous devrez définir le jeu de caractères de connexion sur utf8mb4 . De cette façon, MySQL n'effectue aucune conversion à partir de son UTF-8 natif lorsqu'il transfère des données à votre application et vice versa.
Certains pilotes fournissent leur propre mécanisme pour configurer le jeu de caractères de connexion, qui met à jour son propre état interne et informe MySQL de l'encodage à utiliser sur la connexion - c'est généralement l'approche préférée. En PHP :
- Si vous utilisez la couche d'abstraction PDO avec PHP â¥ 5.3.6, vous pouvez spécifier charset dans la DSN :
```
 $dbh = new PDO('mysql:charset=utf8mb4');
```
- Si vous utilisez mysqli, vous pouvez appeler set_charset() :
```
  $mysqli->set_charset('utf8mb4');       // object oriented style
  mysqli_set_charset($link, 'utf8mb4');  // procedural style
```
- Si vous êtes bloqué avec mysql simple mais que vous utilisez PHP â¥ 5.2.3, vous pouvez appeler mysql_set_charset .
Si le pilote ne fournit pas son propre mécanisme pour définir le jeu de caractères de connexion, vous devrez peut-être émettre une requête pour indiquer à MySQL comment votre application s'attend à ce que les données de la connexion soient encodées :SET NAMES 'utf8mb4' .
La même considération concernant utf8mb4 /utf8 s'applique comme ci-dessus.

Sortie :

UTF-8 doit être défini dans l'en-tête HTTP, tel que Content-Type: text/html; charset=utf-8 . Vous pouvez y parvenir soit en définissant default_charset dans php.ini (préféré), ou manuellement en utilisant header() fonction.
Si votre application transmet du texte à d'autres systèmes, ils devront également être informés de l'encodage des caractères. Avec les applications Web, le navigateur doit être informé de l'encodage dans lequel les données sont envoyées (via des en-têtes de réponse HTTP ou des métadonnées HTML).
Lors de l'encodage de la sortie à l'aide de json_encode() , ajouter JSON_UNESCAPED_UNICODE comme second paramètre.

Entrée :

Les navigateurs soumettront les données dans le jeu de caractères spécifié pour le document, donc rien de particulier ne doit être fait sur l'entrée.
Si vous avez des doutes sur l'encodage de la requête (au cas où il pourrait être falsifié), vous pouvez vérifier chaque chaîne reçue comme étant UTF-8 valide avant d'essayer de la stocker ou de l'utiliser n'importe où. mb_check_encoding() de PHP fait l'affaire, mais il faut l'utiliser religieusement. Il n'y a vraiment aucun moyen de contourner cela, car les clients malveillants peuvent envoyer des données dans l'encodage de leur choix, et je n'ai pas trouvé d'astuce pour que PHP le fasse pour vous de manière fiable.

Autres considérations relatives au code :

Évidemment, tous les fichiers que vous allez servir (PHP, HTML, JavaScript, etc.) doivent être encodés en UTF-8 valide.
Vous devez vous assurer que chaque fois que vous traitez une chaîne UTF-8, vous le faites en toute sécurité. C'est malheureusement la partie la plus difficile. Vous voudrez probablement faire un usage intensif du mbstring de PHP extension.
Les opérations de chaîne intégrées de PHP ne sont pas par défaut UTF-8 sécurisé. Il y a certaines choses que vous pouvez faire en toute sécurité avec les opérations de chaîne PHP normales (comme la concaténation), mais pour la plupart des choses, vous devez utiliser l'équivalent mbstring fonction.
Pour savoir ce que vous faites (lire :ne pas tout gâcher), vous avez vraiment besoin de connaître UTF-8 et comment cela fonctionne au niveau le plus bas possible. Consultez l'un des liens de utf8.com pour trouver de bonnes ressources pour apprendre tout ce que vous devez savoir.

En plus de définir default_charset dans php.ini, vous pouvez envoyer le jeu de caractères correct en utilisant header() depuis votre code, avant toute sortie :

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

Travailler avec Unicode en PHP est facile tant que vous vous rendez compte que la plupart des fonctions de chaîne ne fonctionnent pas avec Unicode, et certaines peuvent complètement mutiler les chaînes . PHP considère que les "caractères" font 1 octet de long. Parfois, cela convient (par exemple, explosion() ne recherche qu'une séquence d'octets et l'utilise comme séparateur - donc peu importe les caractères réels que vous recherchez). Mais d'autres fois, lorsque la fonction est réellement conçue pour fonctionner sur des caractères , PHP n'a aucune idée que votre texte contient des caractères multi-octets trouvés avec Unicode.

Une bonne bibliothèque à vérifier est phputf8. Cela réécrit toutes les "mauvaises" fonctions afin que vous puissiez travailler en toute sécurité sur les chaînes UTF8. Il existe des extensions comme l'extension mb_string qui essaient de le faire pour vous aussi, mais je préfère utiliser la bibliothèque car elle est plus portable (mais j'écris des produits grand public, c'est donc important pour moi). Mais phputf8 peut utiliser mb_string dans les coulisses, de toute façon, pour augmenter les performances.

J'aimerais ajouter une chose à l'excellente réponse de chazomaticus :

N'oubliez pas non plus la balise META (comme celle-ci, ou sa version HTML4 ou XHTML) :

<meta charset="utf-8">

Cela semble trivial, mais IE7 m'a déjà posé des problèmes avec cela.

je faisais tout correctement; la base de données, la connexion à la base de données et l'en-tête HTTP Content-Type étaient tous définis sur UTF-8, et cela fonctionnait bien dans tous les autres navigateurs, mais Internet Explorer insistait toujours pour utiliser l'encodage "Europe occidentale".

Il s'est avéré que la page manquait la balise META. L'ajout de cela a résolu le problème.

Modifier :

Le W3C a en fait une section assez importante dédiée à I18N. Ils ont un certain nombre d'articles liés à ce problème - décrivant le côté HTTP, (X)HTML et CSS :

FAQ :Modification de l'encodage de page (X)HTML en UTF-8
Déclarer des encodages de caractères en HTML
Tutoriel :Jeux de caractères et encodages en XHTML, HTML et CSS
Définition du paramètre de jeu de caractères HTTP

Ils recommandent d'utiliser à la fois l'en-tête HTTP et la balise méta HTML (ou la déclaration XML dans le cas de XHTML servi comme XML).