Accrocheur mon titre n’est-ce pas? Je trouve ça tellement pas drôle lorsque ça m’arrive ce genre de situation avec les caractères accentués. Le problème n’arrive pas tout le temps qu’avec WordPress.

Voici, enfin, une suite a mon billet Pourquoi tout ces caractères bizzares. Je devais travailler sur un problème de conversion de caractères pour un client dus a une conversion non réussie et/ou terminée entre latin1 et utf-8 puis je me suis remis a penser a ce problème. Pourquoi ne pas le régler, et documenter!

Voilà pourquoi ce billet

La situation

Mon cas était bien simple. J’avait mal fait ma sauvegarde lors d’un transfert et j’avait tout mes commentaires, billets, et autres données qui avait des accents “transform√©s comme √áa” (transformés comme ça).

Ce genre de problème arrive pour toutes sortes de raisons. Mais le symptôme est le même. Si vous avez des
Je partage avec vous mon bout de code a «copier-coller» dans phpmyadmin pour votre blogue WordPress si vous avez ces problèmes (oubliez-pas de faire des sauvegardes là(!)).

Plusieurs tutoriels existent pour régler la situation mais mon cas était assez unique. J’ai conservé le problème puis j’ai publié plusieurs billets (qui sortent bien) et laissé ceux “ab√Æm√©s” là. Il n’était plus question d’extraire, convertir et ré-importer.

Pourquoi?!

C’est une réponse assez complexe. L’article UTF-8 sur TikiWiki.org l’explique en détail.

In short, UTF-8 is a character encoding that uses 1 to 3 bytes for each character.
It is one of the existing character encodings of the UCS (Universal Character Set), that contains nearly a hundred thousand abstract characters (including ASCII characters).

UTF-8 greatly simplifies the task of internationalization by replacing multiple alternative encodings (such as ISO8859-15 Latin-9, which encodes those English, French, German, Spanish and Portuguese characters not available in ASCII).

En simple, le UTF-8 est un format d’encodage qui utilise 1 a 3 bytes pour chaque caractère. C’est un format d’encodage qui comprend près de plusieurs centaines de milliers de caractères (Incluant ceux du ASCII).

UTF-8 est fait pour contenir tout les caractères existants pour simplifier l’internationalisation.

C’est un standard qui est pas nécessairement jeune mais qui n’était pas non plus supporté partout.

MySQL a commencé a le supporter qu’a partir de la version 4.1.

Ce qui arrive c’est qu’avec le temps, les gens prennent de plus en plus soin de rendre accessible pour toutes les langues leur applications. Ainsi un russe pourrait écrire en cyrillic et un Japonais en Kanji dans la même base de donnée. Le coup est difficile! Surtout que les versions de MySQL et PHP et Java offrent maintenant le choix par défaut en UTF-8… lorsqu’on fait pas attention: on se fait coincer!

Comment j’ai opéré

Comme il n’y a pas que WordPress qui peut avoir ce type de problème j’ai fait un petit script qui génère pour chaque table et colone affectée. J’ai passé dans chaque table et colone où je voyait des choses bizzares et j’ai représenté dans un array a deux dimensions. Avec cette méthode on peut faire la même chose avec n’importequel schéma de base de donnée.

Exemple: Représenter les tables et les colones

Avec ce format, en exemple, j’ai représenté les tables (wp_posts, etc…) et chaque array représente une colone où des caractères accentués sont mal convertis.

1
2
3
4
5
6

$tables = array(
        'wp_posts' => array('post_content','post_title','post_excerpt')
        ,'wp_usermeta' => array('meta_value')
        ,'wp_term_taxonomy' => array('description')
        ,'wp_comments' => array('comment_content')
);

Utiliser le script

Le script a été utilisé pratiquement tel quel sur ma base de donnée WordPress de ce site.

Seuls ajustements a faire.

• Remplacer les “< pre >” par “<pre>”. Vous comprenez le principe
• Afficher le contenu généré via un serveur Web avec PHP installé
• Aller dans phpmyadmin, faire une copie de la base de donnée à affecter (Voir dans onglet “Opérations” et “Copier la base de données vers: “)
• Aller dans cette base de donnée là dans phpmyadmin (!!)
• Exécuter le code généré (copier-coller) dans la fenêtre SQL de la base de donnée de tests
• Faire pareil avec la vraie si vous êtes satisfaits du résultat

Le code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

header('Content-type:text/html;charset=utf8');
$tables = array(
        'wp_posts' => array('post_content','post_title','post_excerpt')
        ,'wp_usermeta' => array('meta_value')
        ,'wp_term_taxonomy' => array('description')
        ,'wp_comments' => array('comment_content')
);
 
$chars = array(
 bin2hex('√Ä').'|À',
 bin2hex('√¥').'|ô',
 bin2hex('√Ç').'|â',
 bin2hex('√á').'|ç',
 bin2hex('√©').'|é',
 bin2hex('√â').'|É',
 bin2hex('√†').'|à',
 bin2hex('√®').'|è',
 bin2hex('√™').'|ê',
 bin2hex('√¢').'|â',
 bin2hex('‚Äô').'|‘',
 bin2hex('¬´').'|«',
 bin2hex('¬ª').'|»',
 bin2hex('√ß').'|ç',
 bin2hex('√π').'|ù',
 bin2hex('√ª').'|û',
 bin2hex('√Æ').'|î');
 
foreach($tables as $table => $elements){
  foreach($elements as $col){
    foreach($chars as $char){
        $elc = explode('|',$char);
        $update_line.= 'update '.$table.' set '.$col.' = REPLACE('.$col.', UNHEX(\''.$elc[0].'\'), \''.$elc[1].'\') ;'.PHP_EOL;
    }
  }
}
echo '< pre >'.$update_line.'< / pre >';

J’était, hier, en train de jouer avec des appels SOAP pour préparer un projet et j’ai réalisé que ma version compilée de php 5.3.0 était défectueuse.

Je dis que mon installation est défectueuse car lorsque j’instantiait $client = new Zend_Soap_Client; plus rien ne répondait. Même aller en error_reporting(E_ALL); et tout ce qui est imaginable. C’est après quelques heures a tourner en rond je me suis dit que si même $client = new SoapClient; avec un résultat du genre “Class does not exists”. C’est le PHP… pas le code ou le Framework. Pas de doute.

J’ai donc pensé recompiler la dernière version PHP 5.3.1 qui est considérée stable… quant à recompiler, autant mettre à jour sur la dernière version!

Ce billet vous permettra d’installer la version stable PHP 5.3.1 a partir d’un repository déjà configuré au lieu de le compiler.

Tournage en rond avant d’en arriver là

J’ai souvent entendu l’adage qui veut qu’on ne devrait pas installer un logiciel a sa première version majeure. On peut faire le parallèle avec les automobiles. Il y a des coins ronds qui doivent être réparés. La version 5.3.1 est justement la correction de plus de 100 bugs.

Quelques corrections dans PHP 5.3.1

• Ajouté “max_file_uploads” dans la configuration INI qui peut etre là pour éviter la quantité de fichiers téléversés a 20 par défaut. Ainsi éviter un tentative d’attaque DOS
• Ajouté des vérification de validité sur le moteur exif
• Corrigé le “safe_mode” dans tempnam()
• Corrigé open_basedir dans posix_mkfifo()
• Corrigé la fonction brisée safe_mode_include_dir

Voir le “ChangeLog (anglais)” et son “release announcement (anglais)“

Ma station de travail

Ma station de travail secondaire est en Ubuntu 8.10 sur mon vieux portable. J’avait compilé la version 5.3.0 il y a plusieurs mois (dès sa sortie) pour pouvoir jouer avec les nouvelles fonctions.

La version disponible en auto-installation sur Ubuntu est encore sur du PHP 5.2.x ce qui est innacceptable pour mes projets. J’avait même fait ma ligne configure et j’avait commencé a compiler la nouvelle version. C’est là que je me suis dit que j’était pas le premier a vouloir une version plus récente de PHP.

Installer PHP 5.3.1 sous Ubuntu Linux

C’est pas une version officielle selon Debian ou Ubuntu car jusqu’en mi-2010 sur la release Squeeze de Debian c’est comme ça.

Comparé a la version Debian, la version Dotdeb a ces changements

• Les .deb ont le patch Suhosin appliqué par défaut
• mis a part apache2, apache2filter, CGI, et le CLI (pour la ligne de commande), le module FPM utilise la version custom [de Dotdeb] du paquet intitulé “php5-fpm“. Il permet des meilleures performances et plus de fonctions comparables a une installation en mode CGI.
• Note: Le module FPM: a un exemple de configuration, un “init script”, et un gabarit de configuration pour NGINX

Installer?!

C’est fonctionnel sous Debian Lenny et probablement d’autres. Moi, personnellement, je l’ai essayée sous Ubuntu 9.04 Jaunty. Dites-moi si vous l’avez essayé sous d’autres version dans les commentaires

Étape 1

Modifier le sources.list

1

$ sudo vi /etc/apt/sources.list

Ajouter les deux lignes suivantes.

1
2

deb http://php53.dotdeb.org stable all
deb-src http://php53.dotdeb.org stable all

Étape 2

Maintenant, simplement mettre a jour avec…

1

# aptitude update && aptitude upgrade

Si vous aviez une version inférieure de PHP, elle devrait se mettre à jour.

Sources

PHP 5.3.1 packages for Debian “Lenny” : they’re here!