2009-12-20 7 views
0

J'ai un blog (Wordpress) et certains de mes messages plus anciens ont un problème d'encodage de caractères où £ affiche comme £ (c'est-à-dire un signe dièse précédé d'un 'A' majuscule avec un chapeau).Est-il correct de corriger une erreur de codage de caractères à l'aide de SQL REPLACE?

Le problème est au niveau DB, donc j'allais exécuter l'instruction SQL suivante:

update wp_posts set post_content = replace(post_content, ‘£’, ‘£’); 

Serait-ce stupide?


Informations générales (non requis pour lire):

Comment ce problème est-il passé? Je ne sais pas. Le blog a été à travers différentes mises à jour (y compris de Wordpress version 2.1.3 lorsque la table par défaut CHARSET a changé de latin1 en utf8) et a été migré vers et à partir de diverses machines et je suppose que Wordpress doit avoir écrit des caractères codés UTF-8 la base de données qui avait un CHARSET de latin1, ou vice-versa. Je sais que j'aurais dû être plus prudent (oui j'ai lu The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)).

Comment ai-je fait en sorte que cela ne se reproduise plus? Je me suis assuré que mes encodages sont cohérents. Toutes les tables MySQL utilisent CHARSET utf-8 et la section HEAD du jeu de pages de blog <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Répondre

2

Cela devrait aller. La meilleure chose est la suivante:

  • Faire un dump de votre blog db
  • charge à un autre db
  • Effectuer REPLACE sur le db temporaire
  • Check!
  • Si tout se passe bien, exécutez-le également sur le db de production.
0

Ne faites pas ça! Utilisez un trigger sur update/insert si vous en avez vraiment besoin.

EDIT: hmm, après avoir lu votre situation, je suggère de faire une copie de sauvegarde de la DB et d'essayer ce que vous avez dit. Je pense que cela fonctionnerait, tant que vous ne prévoyez pas le faire à nouveau (ce qui semble être le cas)

2

Eh bien, je dirais que ce serait probablement la meilleure "solution" au problème.

Comme les données ont été stockées en utilisant un mauvais codage quelque part le long de la ligne, les données d'origine sont perdues et il n'y a pas de solution réelle. Vous devez juste essayer de récupérer ce que vous pouvez à partir des données corrompues que vous avez.

Si elle est isolée à un seul caractère, vous avez de la chance. Il peut y avoir des codes d'octets qui ne se traduit pas un caractère disponibles, si cela se produisait partout où vous auriez pas une combinaison de caractères est possible d'identifier, vous avez juste un caractère remplacé par un autre ou un caractère manquant. Il serait seulement possible de repérer cela manuellement.

1

Bien sûr, vous avez des données dans un encodage et la table avec un autre. Vous pouvez corriger cela dans mysql. Check here