J'ai dû essayer de "réparer" un certain nombre de situations de rupture d'UTF8 dans le passé, et malheureusement ce n'est jamais facile, et souvent plutôt impossible.
À moins que vous ne puissiez déterminer exactement comment elle a été cassée, et qu'elle l'a toujours été de la même manière, il sera difficile de "réparer" les dommages.
Si vous voulez essayer de réparer les dégâts, votre meilleure chance serait de commencer à écrire un exemple de code, où vous essayez de nombreuses variations sur les appels à mb_convert_encoding()
pour voir si vous pouvez trouver une combinaison de "de" et "à" qui fixe vos données. En fin de compte, il est souvent préférable de ne pas s'inquiéter de la correction des anciennes données en raison des niveaux de douleur impliqués, mais plutôt de corriger les choses pour l'avenir.
Cependant, avant de faire cela, vous devez vous assurer que vous corrigez tout ce qui cause ce problème en premier lieu. Vous avez déjà mentionné que la collation et les éditeurs de votre table de base de données sont correctement définis. Mais il y a d'autres endroits où vous devez vérifier que tout est correctement UTF-8 :
- Assurez-vous que vous fournissez votre HTML en UTF-8 :
header("Content-Type: text/html; charset=utf-8");
- Changez le jeu de caractères par défaut de PHP en utf-8 :
ini_set("default_charset", 'utf-8');
- Si votre base de données ne parle pas TOUJOURS en utf-8, il se peut que vous deviez lui demander, pour chaque connexion, de s'assurer qu'elle est en mode utf-8, ce que vous pouvez faire avec MySQL :
- Vous pouvez avoir besoin de dire à votre serveur web de toujours essayer de parler en UTF8, dans Apache cette commande est :
- Enfin, vous devez TOUJOURS vous assurer que vous utilisez des fonctions PHP qui sont correctement conformes à l'UTF-8. Cela signifie que vous devez toujours utiliser l'option mb_* des fonctions de chaîne de caractères de type "multibyte". Cela signifie également que lorsque vous appelez des fonctions telles que
htmlspecialchars()
Il est important que vous incluiez le paramètre charset 'utf-8' approprié à la fin pour vous assurer qu'il ne les codera pas de manière incorrecte.
Si vous oubliez une seule étape de votre processus, l'encodage peut être déformé et des problèmes peuvent survenir. Une fois que vous avez pris l'habitude d'utiliser utf-8, tout cela devient une seconde nature. Et bien sûr, PHP6 est supposé être entièrement unicode dès le départ, ce qui facilitera beaucoup de choses (espérons-le).
0 votes
Vous pourriez peut-être énumérer les personnages qu'ils sont censés représenter ? Et peut-être un vidage hexagonal ?
7 votes
Un coup d'œil rapide semble suggérer que vos chaînes ont pu être "doublement" encodées en utf-8. C'est-à-dire qu'elles ont été encodées en utf-8, ces octets ont été pris comme des caractères unicode, et le résultat a été encodé en utf-8. En revenant en arrière : "î"=" \xC3\x83\xC2\xAE " <-(utf-8)- " \xC3\xAE " <-(utf-8)- " \xEE " = "î". Ou peut-être pas -- pas beaucoup de données à diagnostiquer ici.
0 votes
Il est possible que ce soit un double encodage. Existe-t-il un moyen sûr de vérifier cela par programme, et si oui, quel est le meilleur moyen de décoder le double encodage en toute sécurité ?
0 votes
Oui, Jayrox, regardez ma réponse ci-dessous.
0 votes
Un des problèmes est que
utf8_general_ci
qui apparemment ne garantira pas un bon UTF8 stackoverflow.com/a/1036459/183677 . Aussi les personnages que vous mentionnez sont UTF8 valide hexutf8.com/ (mais je me rends compte que c'est probablement juste ce que vous voyez dans la console ou quoi que ce soit d'autre). il est intéressant de poster les octets réels0 votes
Acc. à cette réponse ,
mysqli_set_charset($dbc, "utf8");
pourrait aider.0 votes
Voir "Mojibake" dans stackoverflow.com/questions/38363566/