Stockage des apostrophes, des points d'exclamation, etc. dans la base de données mysql

Question

Je suis passé de latin1 à utf8. Bien que toutes les sortes de texte affichaient bien j'ai remarqué que les caractères non-anglais ont été stockés dans la base de données comme symboles étranges. J'ai passé une journée à essayer de résoudre ce problème et, enfin, les caractères non anglais s'affichent désormais en tant que caractères non anglais dans la base de données et affichent la même chose sur le navigateur. Cependant, j'ai remarqué que je vois des apostrophes stockées comme ' et des points d'exclamation stockés comme !. Est-ce normal, ou devraient-ils apparaître comme 'et! dans la base de données à la place? Si oui, que devrais-je faire pour résoudre ce problème?

Answer 1

Cela dépend vraiment de ce que vous avez l'intention de faire avec le contenu de la base de données. Si votre invariant est que "le contenu de la base de données est aseptisé et peut être placé directement dans une page Web sans autre validation/désinfection", alors avoir & amp; et d'autres entités html dans votre base de données prend tout son sens. Si, par contre, votre base de données ne stocke que les données originales brutes et que vous avez l'intention de les traiter/désinfecter, avant de les afficher en code HTML, vous devrez probablement remplacer ces entités par les caractères originaux, encodés en UTF -8. Donc, cela dépend vraiment de la façon dont vous interprétez le contenu de votre base de données.

Answer 2

Les &#XX; formes sont HTML character entities, ce qui implique que vous avez passé les valeurs stockées dans la base de données via une fonction telle que htmlspecialchars ou htmlentities de PHP. Si les valeurs sont traitées dans un document HTML (ou peut-être par n'importe quel processeur HTML, indépendamment de ce dont elles font partie), elles devraient s'afficher correctement. En dehors de cela, ils ne le feront pas. Cela signifie que vous ne voulez probablement pas les garder codés en tant qu'entités HTML. Vous pouvez reconvertir les valeurs en utilisant la contrepartie de la fonction que vous avez utilisée pour les coder (par exemple, html_entity_decode), qui devrait prendre un argument quant à l'encodage à convertir. Une fois que vous avez fait cela, vérifiez certaines des entrées précédemment problématiques, en vous assurant que vous utilisez le codage correct pour les voir.

Si vous rencontrez toujours des problèmes, il existe un décalage entre l'encodage que les valeurs stockées sont censées utiliser et ce qu'elles utilisent réellement. Vous devrez déterminer ce qu'ils utilisent réellement, puis les convertir en les extrayant de la base de données et en les convertissant au codage cible avant de les réinsérer, ou en les réinsérant avec l'encodage qu'ils utilisent réellement. . Similaire à cette dernière option est de convertir les colonnes à BLOB s, puis en changeant le jeu de caractères de la colonne, puis en changeant le type de colonne en un type de texte, puis en convertissant directement la colonne au codage de caractères souhaité. La raison de cette séquence peu maniable est que les types de texte sont convertis lors du changement de l'encodage des caractères, mais pas les types binaires.

Lire "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" pour plus d'informations sur les codages de caractères en général, et § 9.1.4. of the MySQL manual, "Connection Character Sets and Collations", pour savoir comment les codages sont utilisés dans MySQL.