[Résolu] A l'assaut de l'UTF-8

Salut tout le monde !

Je suis un petit nouveau dans la communauté d'alsa, je viens ici assez régulièrement dès que j'ai des soucis et bien souvent les questions déjà posées ou les très bonnes FAQ me suffisent. Mais aujourd'hui je suis face à un problème un peu plus corsé: la migration d'un site vers UTF-8 et tout ce que cela implique.

Pour passer rapidement sur mes motivations de passage à l’UTF-8, ca m’est venu en cherchant l’origine de caractères du style é lorsque que j’écrivais un é dans mon javascript. Après la lecture de différents sujets dont http://forum.alsacreations.com/faq/faq-36-Charset-Iso-8859-1-iso-8859-15-utf-8-lequel-choisir-.html j’ai fait le choix de passer à l’UTF-8.
Il faut l’avouer je n’ai jamais prêté attention au charset et je me contentais bien souvent d’utiliser le meta dans le head html sans me poser de questions. Mais l’application que je suis en train de développer requiert un peu plus d’attention à ce niveau là.

Au fur et à mesure de mes différentes recherches je suis tombé sur plusieurs sites expliquant plus ou moins bien comment passer à l'UTF-8 et les risques encourus.
C'est principalement sur ce site http://blog.neovov.com/index.php?2007/03/06/143-convertir-un-site-en-utf-8 que j'ai trouvé le plus d'informations

Mais alors quelle est la raison de mon post car ce site explique plein de choses bien me direz-vous.
Et ben en réalité je nage dans un flou artistique total sur quelques points de détails, les voici :
(Par avance désolé si certaines questions peuvent paraître désuètes mais il s’agit surtout de confirmer certaines de mes interrogations)

Apache :
- Est-il préférable d'utiliser la fonction header PHP pour préciser l'encodage en UTF-8 ou alors de paramétrer la config dans Apache? (sachant que je suis sur un mutualisé j'ai pas accès à tout mais j’aurai un dédié très prochainement)
- L’extension mbstring est-elle vraiment nécessaire ?

MySQL :
J'avoue ne pas avoir tout compris au niveau des encodages des requêtes à faire... plusieurs questions ici aussi :
- Quelle différence y a-t-il entre utf8_general_ci et utf8_unicode_ci ?
- Sur la page d’accueil de PHPMyAdmin, si on m’indique « Jeu de caractères pour MySQL: UTF-8 Unicode (utf8) » cela signifie donc que la base est en utf8_unicode_ci ?
- Toujours sur la page d’accueil de PHPMyAdmin, ce qui est indiqué « Interclassement pour la connexion MySQL » il s’agit bien du jeu de caractère pour toute les requêtes que fera PHPMyAdmin et cela n’a rien à voir avec la base de données en elle-même non ?

PHP/MySQL :
Bon maintenant que le serveur c’est ok et que la base est au bon format, il va falloir lire et écrire dans la base ^^
- Est-ce donc nécessaire de faire pour chaque insertion en base un « utf8_encode » et pour chaque lecture un « utf8_decode » ?
- L’utilisation de SET NAMES ‘utf8’ ; avant chaque requête n’est-elle pas un peu lourde ?
En sommes qu’elle est la bonne marche à suivre pour bien dialoguer avec la base de données.

FTP et fichiers :
Jusqu’à maintenant j’utilisais PSPad pour sa fonction d’éditeur en mode FTP et j’en étais très content ! Mais le passage à l’UTF-8 requiert un encodage des fichiers, PSPad permet de choisir l’encodage des fichiers à l’enregistrement mais il y a ce fameux UTF-8 BOM ou sans BOM qui n’est pas géré par PSPad (du moins pas d’après mes recherches), par défaut j’ai l’impression que c’est la version BOM qui est utilisée car j’ai des caractères  qui apparaissent sur ma page.
Est-ce que quelqu’un connaitrait donc un bon éditeur avec une fonction FTP et gérant la version BOM/sans BOM.
Question bonus sur le BOM, je me suis rendu compte que lorsque j’ajoute le header HTTP UTF-8 les caractères disparaissent, cependant on conseille partout d’éviter le BOM, que faire ?

Globalement j’aimerai éviter d’avoir à repasser sur tous mes fichiers pour modifier le code de mes dialogues avec la base de données je pense que vous devez me comprendre (surtout quand l’appli possède près de 800 fichiers….). Cependant je crois que je vais devoir malheureusement repasser sur tous les fichiers, au moins pour les enregistrer au format UTF-8 (sans BOM).

Finalement si vous aviez quelques bons liens expliquant des choses en plus je suis preneur !

Voila, je sais que mon post est assez long, certaines questions peuvent vous paraitre enfantines mais si vous pouviez éclairer ma lanterne je vous en serais très reconnaissant.

Par avance merci !
Modifié par tone (15 Oct 2007 - 23:14)

Bonjour,

a écrit :
Apache3/PHP :
- Est-il préférable d'utiliser la fonction header PHP pour préciser l'encodage en UTF-8 ou alors de paramétrer la config dans Apache? (sachant que je suis sur un mutualisé j'ai pas accès à tout mais j’aurai un dédié très prochainement)
- L’extension mbstring est-elle vraiment nécessaire ?

-Il est possible, à mon souvenir, de modifier l'encodage par défaut d'un type de fichier directement dans un .htaccess donc probablement sur le mutualisé. Je penses que les 2 solutions se valent, ce n'est que 2 moyens différents d'envoyer une même information.

-l'extension mb_string est utile si tu fais usage des fonctions de manipulation de texte, telles strpos, substr, etc et pour la conversion. Cependant elle n'est pas indispensable, les fonctions citées précédemment marchent parfaitement sans, il faut juste savoir qu'elle comptent un caractère accentué comme deux (NB: cette remarque n'est plus valide dans la version 6 de php). Quand aux conversions, normalement il n'y a pas besoins d'en faire.

a écrit :
MySQL :
J'avoue ne pas avoir tout compris au niveau des encodages des requêtes à faire... plusieurs questions ici aussi :
- Quelle différence y a-t-il entre utf8_general_ci et utf8_unicode_ci ?
- Sur la page d’accueil de PHPMyAdmin, si on m’indique « Jeu de caractères pour MySQL: UTF-8 Unicode (utf8) » cela signifie donc que la base est en utf8_unicode_ci ?
- Toujours sur la page d’accueil de PHPMyAdmin, ce qui est indiqué « Interclassement pour la connexion MySQL » il s’agit bien du jeu de caractère pour toute les requêtes que fera PHPMyAdmin et cela n’a rien à voir avec la base de données en elle-même non ?

-utf8_unicode est plus lent mais supporte des égalités plus complexes entre les lettres lors d'une recharche. Exemple donné par le site MySQL (en) le ß allemand est considéré comme un simple "s" en _general_ alors qu'il est considéré comme "ss" en _unicode_.

-je penses qu'il s'agit même du jeu de caractère pour le serveur entier.

-oui, il s'agit de la connexion, par contre j'ignore si cette valeur est stockée côté serveur (auquel cas elle concerne tous les scripts) ou dans phpMyAdmin.

a écrit :
PHP/MySQL :
Bon maintenant que le serveur c’est ok et que la base est au bon format, il va falloir lire et écrire dans la base ^^
- Est-ce donc nécessaire de faire pour chaque insertion en base un « utf8_encode » et pour chaque lecture un « utf8_decode » ?
- L’utilisation de SET NAMES ‘utf8’ ; avant chaque requête n’est-elle pas un peu lourde ?
En sommes qu’elle est la bonne marche à suivre pour bien dialoguer avec la base de données.

-non, il n'y a aucune conversion a faire: le stockage est en utf8, le traitement est en utf8 puis l'affichage est en utf8. Donc à aucun moment il n'est nécessaire de repasser en iso-8859-1 via utf8_decode().

-je n'ai jamais utilisé ça Probablement pas indispensable donc.

a écrit :
FTP et fichiers :
Jusqu’à maintenant j’utilisais PSPad pour sa fonction d’éditeur en mode FTP et j’en étais très content ! Mais le passage à l’UTF-8 requiert un encodage des fichiers, PSPad permet de choisir l’encodage des fichiers à l’enregistrement mais il y a ce fameux UTF-8 BOM ou sans BOM qui n’est pas géré par PSPad (du moins pas d’après mes recherches), par défaut j’ai l’impression que c’est la version BOM qui est utilisée car j’ai des caractères  qui apparaissent sur ma page.
Est-ce que quelqu’un connaitrait donc un bon éditeur avec une fonction FTP et gérant la version BOM/sans BOM.
Question bonus sur le BOM, je me suis rendu compte que lorsque j’ajoute le header HTTP UTF-8 les caractères disparaissent, cependant on conseille partout d’éviter le BOM, que faire ?

PSPad supporte l'unicode sans BOM, il faut le désactiver dans Options->Options du programme...->Programme-fonctionnement->Octets de signature en code UTF-8(décocher)

a écrit :
Globalement j’aimerai éviter d’avoir à repasser sur tous mes fichiers pour modifier le code de mes dialogues avec la base de données je pense que vous devez me comprendre (surtout quand l’appli possède près de 800 fichiers….). Cependant je crois que je vais devoir malheureusement repasser sur tous les fichiers, au moins pour les enregistrer au format UTF-8 (sans BOM).

Un moyen simple de faire ça avec PSPad est de mettre l'encodage en iso, ouvrire la totalité des fichiers, changer l'encodage puis enregistrer (via le menu Format).
Modifié par Necromantik (12 Oct 2007 - 14:20)

Tout d'abord merci pour toutes ces réponses !

J'ai appris notamment que tous mes fichiers étaient déjà en UTF-8 j'avais pas fait attention au menu "Format", et que finalement mon problème de caractères accentués qui ne passaient pas venait du fait que j'étais en UTF-8 et que j'affichais en ISO et de plus c'est moi même qui avais coché l'activation du BOM j'avais pas tout à fait compris a quoi ça servait au moment du méfait

Je vais m'atteler de ce pas à la mise en place de tout ceci et je viendrais vous tenir au courant si jamais j'ai des soucis.
(Dans le mesure où pour l'instant j'ai plus de problème je pense que je vais mettre le tag [Résolu] mais c'est pas grave si je continue à poster dedans si j'ai d'autres questions ?)

Sinon, une nouvelle question me vient à l'esprit, comment traiter les entités HTML ? Finalement si j'ai bien compris je ne devrais plus en avoir besoin non ? Car c'est là un des intérêts d'utiliser l'UTF-8.

Cependant je fais un htmlentities sur de nombreuses informations provenant de l'extérieur (les utilisateurs surtout ^^) afin d'éviter tout ce qui est injection de code etc. mais finalement transformer en entités HTML ne m'était utile que contre l'injection de code et m'embetait pas mal pour faire des recherches et des tris sur des mots commençants par un accent (&eacute ; ça vient pas après le "e" )

Donc que faire contre les injections de code si je n'utilise plus htmlentities ? RegExp ? (je dévie du sujet originel je sais, désolé, si il le faut j'irai créer un autre sujet la où il faut)

Merci d'avance
Modifié par tone (12 Oct 2007 - 15:34)

De rien.

a écrit :
Dans le mesure où pour l'instant j'ai plus de problème je pense que je vais mettre le tag [Résolu] mais c'est pas grave si je continue à poster dedans si j'ai d'autres questions ?

Tu n'as qu'à enlever le tag le temps de les poser

a écrit :
Sinon, une nouvelle question me vient à l'esprit, comment traiter les entités HTML ? Finalement si j'ai bien compris je ne devrais plus en avoir besoin non ? Car c'est là un des intérêts d'utiliser l'UTF-8.

Les seuls entités qui restent utiles sont & (afin d'éviter l'interpretation éronnée comme une entité) ainsi que < / > (afin d'éviter que le texte ne soit considéré comme du html).

a écrit :
Cependant je fais un htmlentities sur de nombreuses informations provenant de l'extérieur (les utilisateurs surtout ^^) afin d'éviter tout ce qui est injection de code etc. mais finalement transformer en entités HTML ne m'était utile que contre l'injection de code et m'embetait pas mal pour faire des recherches et des tris sur des mots commençants par un accent (&eacute ; ça vient pas après le "e" )

Donc que faire contre les injections de code si je n'utilise plus htmlentities ? RegExp ? (je dévie du sujet originel je sais, désolé, si il le faut j'irai créer un autre sujet la où il faut)

Si c'est à destination de mysql, il exite la fonction mysql_real_escape_string().
Si c'est pour du php, addslashes() suffit en général.
Enfin pour du html htmlspecialchars() s'occupe parfaitement des entités qui restent de vigueur en utf8.
Modifié par Necromantik (12 Oct 2007 - 15:54)

Salut c'est encore moi !

Bon je suis en train de basculer en UTF-8 en ce moment même... mais bon vous vous en serez douté si je reviens ici c'est que j'ai un chti soucis

Alors si je récapitule ce que j'ai fait :
- Enregistrer tous les fichiers en UTF-8 sans BOM
- Convertir mes tables et mes champs en utf8_unicode_ci
- Ajouter un .htaccess pour spécifier que le serveur délivre de l'UTF-8

Sauf que là, malheur, le résultat n'est pas du tout ce que j'attends et je me retrouve avec des http://img137.imageshack.us/img137/8104/interogjs0.jpg de partout

Or si je m'en réfère au site que j'avais cité dans mon premier message, celui-ci disait :

a écrit :
Si vous voyez des " http://img137.imageshack.us/img137/8104/interogjs0.jpg " c'est que les données sont en ISO et que le navigateur les affiche en UTF-8 ;

Donc a priori ca voudrait dire que j'ai encore des données en ISO, oui mais où ?

J'ai essayé de faire un export SQL puis de réinsérer en précisant "SET NAMES 'utf8';" mais rien n'y fait.

Je commencais à me demander si le problème venait pas de mon moteur de templates, mais définitive même en faisait un echo direct de ce qui me revient de la requète je me retrouve avec des http://img137.imageshack.us/img137/8104/interogjs0.jpg .

Une idée ?

Hello,

As-tu essayé le "SET NAMES" avant chaque requête ?

Salut,

au sujet de la conversion de tables mysql de l'iso vers utf8 j'étais tombé sur cette page.

Mais si "SET NAMES" suffit, ce serait une bonne nouvelle !

Je viens d'essayer mais ca ne fait rien, dans mon dump j'ai essayé sur une seule de mes 60 tables (la flemme de faire 180 copier coller...) j'ai mis devant le DROP TABLE, le CREATE TABLE et l'INSERT

Si phpMyAdmin me dit que les champs sont au format 'utf8_unicode_ci', a priori y'a pas de soucis c'est bien que je suis en utf-8 non ?
Les données dans mes tables peuvent pas être à un autre format ?

EDIT : je parlais de SET NAMES !

Je vais essayer l'autre technique de ce pas !
Modifié par tone (15 Oct 2007 - 15:36)

En passant, si la solution donnée en lien ne marche pas, je viens de tomber sur un topic qui va bien : [résolu] Convertir une base de données ISO en UTF-8

(désolé pour le double post mais c'est pour être sûr que les intéressés voit le sujet remonté )

Bon j'ai essayé la technique de l'écriture dans le fichier et phpMyAdmin me fait une super erreur, forcément il aime pas les caractères bizarres qu'il trouve au début du fichier

a écrit :
MySQL a répondu:Documentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'xEFxBBxBF

DROP TABLE IF EXISTS `_adm_dossier`' at line 1

Euh ptete que j'ai fait quelque chose de mal ? parce que visiblement y'a un soucis avec l'écriture en binaire de plus en ouvrant le fichier tous mes accents sont devenus des "é"
Pourtant rien de moins compliqué qu'un copié/collé...

Bon j'ai regardé ton lien mais justement j'aurai bien aimé que ce soit si simple, j'ai déjà fait tout ce qui y est dit et voilà où j'en suis

Je suis sur un mutualisé OVH, si ca peut donner des infos en plus...

Essayes de valider ta page afin de voir quels encodages sont utilisés.
(il te dira par exemple si le mime-type du document et du serveur sont différents, etc.)

Ceci afin de savoir quel est l'encodage réel et quel est l'encodage que le navigateur tente d'interpreter (parce que tenter de re-encoder de l'utf8 en utf8 peut donner des trucs irrécupérables)

Bonne idée la validation

Malheureusement le résultat n'est pas celui espéré, enfin peut être que ça te donnera une idée, voila ce qu'on me dit :

a écrit :
Sorry! This document can not be checked.
Sorry, I am unable to validate this document because on line 134 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.

The error was: utf8 "\xE9" does not map to Unicode

Malheureusement pas moyen d'afficher l'outline ou le source donc je sais même pas a quoi correspond sa ligne 134, et quand je valide en faisant un copié/collé ça me répond que ma page est valide

Bonsoir,

Le caractère \xE9 correspond à un "é" en ISO8859-1.

Si ça peut aider

Quand tu copies-colle, je suppose que ça fait la conversion
Modifié par Lanza (15 Oct 2007 - 21:30)

Selon toute vraisemblance il y a donc les bons headers utf-8 mais le document est en iso...
Or ta base semble aussi en utf-8.

Je vois 2 possibilités:
-il y a un utf8_decode() sur le résultat de la requête mysql.
-la connexion est en iso.

Pour vérifier:
-lire le code
-effectuer mysql_client_encoding() ou mysqli_character_set_name() sur la connexion à la base afin de connaitre l'encodage de celle-ci.

Dans le cas de la 2eme option, il faut selon la doc mysql
effectuer les 2 requêtes suivantes après avoir ouvert la connexion (et pas avant chaque requête)

SET NAMES 'charset_name'
SET CHARACTER SET charset_name

(et à prioris c'est plutôt la 2eme qui va t'aider car la première indique l'encodage de ce que le client envoie et non de ce qu'il reçoit)
Modifié par Necromantik (15 Oct 2007 - 21:53)

On s'approche on s'approche

Je viens de faire un test d'encodage de la connexion et en effet la connexion avec la base est en latin1. Par contre mauvaise nouvelle le SET NAMES et consor de change rien

echo mysql_client_encoding($this->link),'<br />';
mysql_query("SET NAMES 'utf8'");
echo mysql_client_encoding($this->link),'<br />';
mysql_query("SET CHARACTER SET utf8");
echo mysql_client_encoding($this->link),'<br />';

Sortie :

a écrit :
latin1
latin1
latin1

Aller on reste motivé ! En tout cas merci pour tout le temps passé à m'aider !

As-tu essayé d'afficher le site quand même ?

En effet dans les commentaires de la doc php il est dit:

a écrit :
Please note that even if you set the charset by issuing the two mentioned SQL statements (set names, set character set) mysql_client_encoding still deliveres the old result.

Default for me is latin1. After switching to UTF8 mysql_client_encoding still returns latin1. The charset switched to UTF8 successfully, though.

En gros mysql_client_encoding retournerait latin1 même après le switch.
Modifié par Necromantik (15 Oct 2007 - 22:59)

En effet ! Ca marche malgré le retour "latin1", le site est bien passé en UTF8, étonnant qu'une fonction renvoie quelque chose qui n'a rien à voir

Et ça marche même en faisant juste le SET NAMES dans le doute je vais garder les deux instructions.

Merci bien pour toutes ces explications, je pense que je peux mettre le tag [résolu] maintenant ^^

( jusqu'au prochain problème )

Merci encore !

Bonjour,
C'est vrai que le message commence à dater.
Je voulais préciser que pour utiliser SET NAMES 'UTF8', il ne faut pas utiliser mysqli_connect() mais il faut utiliser:
mysqli_init(), mysqli_option() puis mysqli_real_connect()

Exemple:

$mysqli = mysqli_init();
$mysqli->options(MYSQLI_INIT_COMMAND, "SET NAMES 'UTF8'");
$mysqli->real_connect([%nom machine%], [%compte utilisateur%],[%mot de passe%], [%schéma de données%]);

@+