Après la mise à niveau de PHP sur notre serveur de développement de 5.2 à 5.3, nous rencontrons un problème où les données demandées à partir de notre base de données et sont affichées sur une page Web indique avec un encodage incorrect lors de la tentative d'affichage des caractères russes. < / p>
dans PHP 5.3, la bibliothèque clientèle par défaut pour interagir avec des bases de données MySQL a été modifiée de libmysql vers mysqlnd , qui semblerait être la cause de la question que nous rencontrons.
Nous nous connectons à la base de données avec le code suivant: < / p> Les données stockées dans notre base de données sont codées avec le codage UTF-8. Connexion à la base de données via le client de ligne de commande et les requêtes en cours d'exécution confirment que les données sont intactes et codées correctement. Cependant, lorsque nous interrogeons la base de données en PHP et essayez d'afficher exactement les mêmes données, elle se brouit. Dans ce cas particulier, nous essayons d'afficher des caractères russes et le résultat est des caractères non-anglais, non russe:
Les en-têtes de réponse que nous recevons confirment que le type de contenu est UTF-8 : Nous avons testé les cordes avant l'affichage avec MB_Detect_Encoding en mode strict ainsi que mb_check_encoding et on m'a dit que la chaîne était une chaîne UTF-8 avant de l'afficher . Nous avons également utilisé mysql_client_encoding pour tester le codage du client et indique également Le jeu de caractères est UTF-8. dans effectuer des recherches, nous avons découvert Quelques suggestions pour essayer de contourner ce problème: Nous avons même essayé utf8_encode : Cependant, aucune de ces solutions n'a fonctionné. À court d'options, nous avons mis à niveau MySQL sur notre système de développement pour distribuer 5.1.55. Après cette mise à niveau, tout est affiché correctement lorsque nous sommes connectés à notre base de données de développement. Bien sûr, il continue de s'afficher de manière incorrecte lorsque nous nous connectons à notre base de données en direct. Idéalement, nous souhaitons résoudre ce problème sans moderniser MySQL sur nos serveurs de production, à moins que nous ne puissions vérifier la raison exacte de la raison. t Travailler et pourquoi la mise à niveau le réparera. Comment pouvons-nous résoudre ce problème de codage sans mettre à niveau MySQL? Alternativement, pourquoi la mise à niveau MySQL corrige-t-elle le problème? 
3 Réponses :
Je vois que vous avez essayé cela, mais la syntaxe que j'utilise est la suivante: mysql_query ("noms noms UTF8"). Votre syntaxe peut être correcte, je ne l'ai jamais vu comme ça avant.
Exemple:
Oui, nous ne fournissons que le deuxième paramètre facultatif pour fournir la connexion (voir DOCS . Je t'ai essayé de choisir juste pour des coups de pied (avec les citations de UTF minuscules et doubles aussi) et les résultats étaient les mêmes: Texte brisé.
Si vous vous êtes assuré que les tables et le codage de sortie sont UTF-8, la seule chose que la seule chose à resserre est l'encodage de la connexion.
La raison du changement de comportement lors de la mise à jour des serveurs pourrait Soyez un changement d'encodage de la connexion par défaut: p> Cependant, je ne peux voir aucune modification du codage par défaut entre les versions, donc si celles-ci étaient neuves Installe, je ne peux pas voir cela se produire. P> Quoi qu'il en soit, que se passe-t-il si vous exécutez cela à partir de votre requête PHP et de produire les résultats. Toute différence pour la sortie de la ligne de commande? P> SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
@Andreas étrange, semble bien. Faites-vous quelque chose de spécifique avec les données ou faites-vous simplement le modifier?
@Pekka: Si nous sélectionnons simplement un champ russe, puis l'écho, il est affiché de cette façon. Et oui tout cela est très étrange ..
@Andreas aucune chance d'un lien direct?
@Pekka qui serait difficile car nous testons cela sur les systèmes de développement interne. J'ai mis à jour la question avec une capture d'écran des en-têtes de réponse comme indiqué par Firebug. Y a-t-il d'autres informations supplémentaires que vous voudriez d'un lien?
@Shaun est "utf8" ce que le navigateur affiche également dans son menu de codage? Cela semble-t-il bien si vous forcez la remplacement de l'ISO-8859-5 ou l'un des autres codages cyrilliques?
@Pekka: Le menu du navigateur affiche "Unicode (UTF8)" comme étant sélectionné. Essayer d'invoquer ISO-8859-5 entraîne un mélange de sortie de caractère cyrillique et brouillon. J'ai essayé plusieurs autres méthodes de codage marquées comme "Cyrillic" avec des résultats similaires.
@Shaun c'est bizarre, alors ça ne semble même pas être "correctement cassé" ... très étrange, je suis à court d'idées! L'étape suivante peut essayer de le reproduire sur une installation de serveur différente et de comparer les paramètres de versions MySQL 'Côte à côte pour voir si quelque chose est différent. Vérifiez également les tables et les colonnes - vous pouvez spécifier des codages personnalisés pour chaque
@Pekka: Comme il s'avère, vous étiez sur la bonne voie avec votre réponse initiale. Je remettais directement les requêtes que vous avez suggérées directement sur notre serveur en direct et obtenu Différents résultats que Andreas ont signalé . Exécution Statut; à partir de la ligne de commande a également montré la différence d'encodage du client VS Server VS. Une fois que nous avons forcé nos scripts de test à l'aide de latin1, le texte a fonctionné comme prévu. Il semblerait que cette divergence existait et la modification de la bibliothèque client MySQL pendant la mise à niveau vers PHP 5.3 l'a exposée.
@Shaun ah, intéressant! Merci pour les commentaires. Cela explique également pourquoi les personnages étaient "doublement" cassés et non seulement des représentations monopy-octet de données multi-octets - Cyrillic ne peut pas être affichée en latin1
@Pekka en effet. Merci pour l'assistance sur celui-ci. :)
J'ai eu un problème similaire après la mise à niveau de PHP de 5.2.3 au 5.3.5 (5.3.5-Win32-VC6-X86), MySQL 5.0.41 (non mise à jour). Je pense que cette raison est une petite différence entre les versions PHP.
php 5.2.3 Par défaut (sans noms de jeu): php 5.3.5 Par défaut (sans noms de jeu): J'ai ajouté des données à la base de données dans PHP 5.2.3 Par défaut (sans noms définis), alors maintenant pour l'afficher correctement, je dois le lire correctement, je dois la lire à l'aide de: P>
caractère_set_client = latin1
Caractère_set_connection = Latin1
Caractère_set_database = utf8
Caractère_set_FileSystem =
binaire
Caractère_set_results = Latin1
Caractère_set_server = latin2
Caractère_set_system = utf8
Collation_Connection = Latin1_SWEDISH_CI
Collation_Database = utf8_polish_ci
Collation_Server = Latin2_General_ci
em> p>
caractère_set_client = latin2
Caractère_set_connection = Latin2
Caractère_set_database = utf8
Caractère_set_FileSystem =
binaire
Caractère_set_Results = latin2
Caractère_set_server = latin2
Caractère_set_system = utf8
Collation_Connection = Latin2_General_ci
Collation_Database = utf8_polish_ci
Collation_Server = Latin2_General_ci
EM> P> $pdo -> query("SET NAMES 'latin1'");
Quel genre de poignardé? Cela semble fortement que l'encodage de la connexion par défaut est ISO-8859-1 dans le boîtier brisé et UTF-8 dans le boîtier non grêle. Je ne sais pas pourquoi ... quel code utilisez-vous pour vous connecter à la base de données?
@Pekka: Mise à jour de la question pour répondre à vos questions.
Et votre codage de sortie sur l'extrémité HTML est également UTF-8? Pouvez-vous confirmer que le navigateur est en mode UTF-8 lors de la saisie de votre site?
@Pekka: Oui, c'est UTF-8 (je travaille avec Shaun et je connais ce problème avec ce problème.
Devinière aléatoire: cache de polices corrompue.