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 du codage à utiliser sur la connexion - c'est généralement l'approche préférée. En PHP :
- Si vous utilisez le PDO couche d'abstraction avec PHP ≥ 5.3.6, vous pouvez spécifier charset dans le 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 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 :

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 les en-têtes de réponse HTTP ou métadonnées HTML ).
En PHP, vous pouvez utiliser le default_charset php.ini, ou émettez manuellement le Content-Type en-tête MIME vous-même, ce qui est juste plus de travail mais a le même effet.
Lors de l'encodage de la sortie à l'aide de json_encode() , ajoutez JSON_UNESCAPED_UNICODE comme second paramètre.

Entrée :

Malheureusement, vous devez 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ù. PHP mb_check_encoding() fait l'affaire, mais il faut l'utiliser religieusement. Il n'y a vraiment aucun moyen de contourner cela, car les clients malveillants peuvent soumettre des données dans l'encodage qu'ils veulent, et je n'ai pas trouvé d'astuce pour que PHP le fasse pour vous de manière fiable.
D'après ma lecture de la spécification HTML , les sous-puces suivantes ne sont plus nécessaires ni même valides pour le HTML moderne. Je crois comprendre que les navigateurs travailleront avec et soumettront des données dans le jeu de caractères spécifié pour le document. Cependant, si vous ciblez des versions plus anciennes de HTML (XHTML, HTML4, etc.), ces points peuvent toujours être utiles :
- Pour HTML avant HTML5 uniquement :vous voulez que toutes les données qui vous sont envoyées par les navigateurs soient en UTF-8. Malheureusement, si vous passez par le seul moyen de le faire de manière fiable, ajoutez le accept-charset attribut à tous vos <form> balises :<form ... accept-charset="UTF-8"> .
- Pour HTML avant HTML5 uniquement :notez que la spécification HTML du W3C indique que les clients "devraient" renvoyer par défaut les formulaires au serveur dans le jeu de caractères servi par le serveur, mais il ne s'agit apparemment que d'une recommandation, d'où la nécessité d'être explicite sur chaque <form> balise.

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 de PHP mbstring 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 quelques bonnes ressources pour apprendre tout ce que vous devez savoir.