Pourquoi mes caractères persans sont-ils tronqués lors de la migration de données d'un ancien script vers MySQL ?

Le mystère des données codées dans MySQL : le cas des anciens et des nouveaux scripts

Dans le domaine du stockage et de la récupération de données, il n'est pas rare de rencontrer un comportement inattendu lors du travail avec des systèmes différents. Tel est le cas de l'écart de codage déroutant rencontré par un développeur qui tente de migrer des données d'un ancien script vers un nouveau.

Le problème : les caractères tronqués

Le développeur a été confronté à un problème particulier : les caractères persans codés en UTF-8 dans l'ancien script apparaissaient sous forme de texte tronqué lors de l'utilisation du nouveau script, même si les deux scripts étaient censés utiliser le même jeu de caractères. (UTF-8).

Le suspect : configuration de la base de données

Les efforts de dépannage initiaux se sont concentrés sur les paramètres de la base de données. L'ancien script utilisait un moteur de base de données personnalisé, tandis que le nouveau script utilisait MySQL. Pour garantir la compatibilité, le développeur a vérifié que le jeu de caractères et le classement de la base de données MySQL étaient respectivement définis sur UTF-8 et UTF-8_persian_ci.

Le comportement étrange

Malgré la définition du jeu de caractères et du classement corrects, l'écart a persisté. L'ancienne écriture continuait d'afficher correctement les caractères persans, tandis que la nouvelle écriture affichait toujours du texte tronqué.

La cause profonde : un incident de connexion

Après avoir approfondi le problème , le développeur a découvert un détail subtil mais crucial : la connexion à la base de données utilisée par l'ancien script était définie sur Latin1. Ce paramètre apparemment inoffensif a eu des implications significatives pour l'encodage des données.

Comment cela s'est produit

Lorsque les données ont été initialement insérées dans la base de données à l'aide de l'ancien script, PHP a envoyé le Chaîne codée en UTF-8 vers la base de données. La connexion étant définie sur Latin1, la base de données a interprété les octets représentant les caractères persans comme des valeurs Latin1. Par conséquent, les caractères ont été stockés dans la base de données avec un encodage incorrect.

La solution : conversion de la base de données

Pour résoudre l'erreur de gravure, le développeur a dû convertir les données dans la base de données au format UTF-8 correct. Cela pourrait être réalisé en utilisant l'instruction SQL suivante :

SELECT CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8) FROM table_name

Une fois la conversion terminée, les caractères persans ont été stockés dans la base de données dans leur encodage UTF-8 correct. Le nouveau script peut désormais récupérer et afficher les données correctement, correspondant à la sortie de l'ancien script.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!