[Résolu] Réaliser un site PHP utilisant l'encodage UTF-8

Bonsoir à tous,

comme je le disais dans le sujet de hibou57, je suis, depuis ce matin, en train d'approfondir mes maigres connaissances en gestion de l'UTF-8 avec PHP. J'ai lu pas mal de choses à ce sujet, j'essaie de me représenter un peu la marche à suivre autant côté encodage des fichiers/DB que du côté de PHP, mais j'avoue être un peu perdu et ne pas trop savoir par quel bout le prendre.


D'après ce que j'ai compris, côté affichage, deux choses :

1. La définition du charset

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

2. L'envois d'un header du serveur vers le client, 3 possibilités

// PHP
header('Content-Type: text/html; charset=UTF-8');

# .htaccess
AddDefaultCharset UTF-8

# .htaccess
AddDefaultCharset Off

Si il n'y a que ça de ce côté tout va bien.

Mais reste le côté PHP. En effet, j'ai pu lire à pas mal d'endroits qu'il fallait configurer la base de données (MySQL pour ma part) en UTF-8, que certaines fonctions ne fonctionnaient pas correctement avec un contenu codé en UTF-8, et bien d'autres...


Dans un premier temps j'aimerai, si quelqu'un veut bien, qu'une personne me propose une espèce de marche à suivre, ou du moins les différentes étapes, les choses à ne pas oublier et les points délicats. Parce que côté gestion de l'UTF-8 sous PHP... je suis com-plète-ment paumé.


Ensuite j'ai quelques questions. Certaines pourront parraitres bêtes, mais je suis vraiment perdu, alors je tappe ce qu'il me passe par la tête :

- Si je dois insérer du texte en dur dans mon code PHP, il faut que mon éditeur soit en UTF-8, mais qu'en serat-il de l'encodage du code PHP en lui même (elements de syntaxe : guillemets, parenthèses, etc.), serat-il encodé aussi ? Si oui, cela ne risque t'il pas de poser problème au niveau de PHP (includes, etc.) ?

- Si je dois intervenir avec PHP (regexp, etc.) sur des chaînes en UTF-8, quel(s) problème(s) cela engendrera-t-il ? Et comment y remedier ?

- Si un utilisateur entre du texte dans un formulaire, le texte retourné par $_GET ou $_POST serat-il codé en UTF-8 ? Si non, que faut-il faire pour qu'il le soit ?


J'ai tellement de questions, sans vraiment en avoir... Dur dur.

Merci,
Antoine
Modifié par Bouda (13 Jan 2006 - 00:46)

a écrit :
Si je dois insérer du texte en dur dans mon code PHP, il faut que mon éditeur soit en UTF-8, mais qu'en serat-il de l'encodage du code PHP en lui même (elements de syntaxe : guillemets, parenthèses, etc.), serat-il encodé aussi ? Si oui, cela ne risque t'il pas de poser problème au niveau de PHP (includes, etc.) ?

Pas de soucis à ce niveau là, quand PHP, comme beaucoup d'autres langage de programmation, n'autorise dans sa syntax (en dehors des literaux de chaines de caractères) que les caractère ascii dont le code est compris entre 32 et 127 (bornes incluses). Et les caractères correspondant de ces caractères, restent les mêmes en utf-8. En effet, utf-8 est compatible avec les caratères acsii de 32 à 127.

Donc l'interpréteur n'aura aucun soucis. Car le texte du programme aura le même encodage qu'il soit en ascii ou en utf-8. S'il ne comprends pas l'encodage utf-8 dans les commentaires, ce n'est absolument pas un problèmes, puisqu'il ne les interprètent pas. Maintenant, pour les chaînes de caractères, même s'ils ne comprends pas l'utf-8, s'il les retransmet à une fonction externe (comme MySQL), alors il retransmetra une suite d'octets, sans même savoir que c'est de l'utf-8, il fera comme s'il transmettait de l'ascii. Donc aucun soucis à ce niveau là non-plus, mais à la condition que l'interpréteur ne décode/recode pas les caractères de commende (0 à 31), comme le font certains environnements (mais c'est alors toujours paramètrable, comme avec la convertion cr-lf par exemple, avec ftp).

Le problème se posera surement par contre, avec des fonctions internes comme celles destinées à mettre une chaîne en minuscule ou majuscules, longeur de chaînes, ... En bref, il y aura un problème avec toutes les fonctions internes, traitant sur les chaînes de caractères (en dehors des simples fonctions de copies, à condition toujours que les caractères de 0 à 31 ne soient pas modifiés)

Voilà ce que je peux te dire à ce sujet Bouda

Slt,

c'est vrai que c'est assez déstabilisant cette impossibilité de traiter de l'UTF-8 avec php.
Vu que php n'est pas capable de traiter des chaînes de caractères multi-octet (utf-8, utf-16) sans extension, je dirais qu'il y a deux solutions :
1 - rajouter l'extension nécessaire, du nom de mbstring mais avec les problèmes de portabilité qui vont avec (c'est une extension peu souvent activée);
2 - ne traiter que des chaînes de caractères en latin-1 (iso-8859-1) et effectuer la conversion lorsqu'on reçoit/envoie les données.

La marche à suivre pour la seconde solution est simple : on decode toutes les données qu'on reçoit en utf8 grâce à utf8_decode() et on encode tout ce qui doit sortir en utf8 grâce à utf8_encode.
C'est super lourd je te l'accorde mais avant php6 je vois pas comment on pourra faire autrement.

Pour tes questions :

- je ne pense pas que php puisse travailler sur un script dont le fichier est enregistré en utf8. Mais c'est à vérifier.

- un bête strlen() ne fonctionne pas sur une chaîne utf8. Donc j'imagine que c'est tout aussi catastrophique pour les REGEXP. La solution : traiter avec du latin1.

- je sais pas et je suis très intéressé par la réponse. Plus globalement, si quelqu'un sait dans quel encodage sont traités les entêtes http, je suis intéressé.

Après, utf8 étant utf8, utf8_encode('string') == 'string' enfin bref tant qu'il n'y a pas d'accents, deux chaînes en utf8 et en latin1 sont identiques.

Voilà je pense ne pas avoir dit trop de bêtises

a+

a écrit :
Si je dois intervenir avec PHP (regexp, etc.) sur des chaînes en UTF-8, quel(s) problème(s) cela engendrera-t-il ? Et comment y remedier ?

J'y ai répondu dans le précédent post...

a écrit :
Si un utilisateur entre du texte dans un formulaire, le texte retourné par $_GET ou $_POST serat-il codé en UTF-8 ? Si non, que faut-il faire pour qu'il le soit ?

Non, il n'y a aucun rapport entre l'encodage du texte du programme php, et l'encodage des données transmise à un cgi en php. Car le navigateur qui renvoit les données, est totalement indépendant de l'environnement d'interpretation du script.

Sauf erreur de ma part, le texte saisi dans un formulaire, aura le même encodage que celui reconnu pour la page html (éventuellement généré en php). Et toujours sauf erreur de ma part, il est possible de spécifié l'encodage utilisé pour un formulaire (par un attribu), indépendament de l'encodage de la page. Pour cette éventualité, c'est les attribut html/xhtml qu'il faut chercher.

Merci pour vos réponses, j'y vois désormais un petit peu plus clair.

Au niveau du traitement des chaînes, OVH n'install pas mbstring donc déjà, ça, out. La méthode du utf8_encode/utf8_decode ne me dit rien, car certains caractères resteront sous forme de caractères spéciaux (é), elle me parrait bien lourde à gérer, mais si c'est la seule solution, je ferais avec. Et vous, quelle méthode utilisez-vous ?

Cette histoire me prend la tête, j'ai l'impression de rien trouver de précis et de clair au sujet de l'utilisation de PHP avec UTF-8...


Question subsidiaire ; j'utilise SciTE pour coder, il propose 5 modes d'encodage :
- 8 bit
- UCS-2 « gros-boutiste »
- UCS-2 « petit-boutiste »
- UTF-8 (avec BOM)
- UTF-8 « cookie » (sans BOM)

Le mode 8 bit correspond à un encodage ISO-8859-1, mais convient-il aussi pour l'ISO-8859-15 ?

Antoine

Coucou!

a écrit :
certains caractères resteront sous forme de caractères spéciaux (é)

C'est normal, car l'utf-8 n'est pas un encodage ordinnaire. Certains caractères sont codés sur un octet, d'autres sur deux octects... jusque parfois six octets. Si tu vois apparaître (é) c'est que affiche avec une application qui ne reconnais pas l'encodage.

a écrit :
Le mode 8 bit correspond à un encodage ISO-8859-1, mais convient-il aussi pour l'ISO-8859-15 ?

ISO-8859-15 est compatible avec ISO-8859-1. En fait, c'est le même, mais avec des ajouts, dont entre autres, le symbole de l'euro. D'ailleurs il y a même parfois des pages qui se déclarent 8859-15 et qui sont en fait du 8859-15.

A Bientôt

Hello,

j'ai trouvé une page qui pourra peut-être m'être utile. Je vais faire des tests cette après-midi.

Si quelques personnes veulent indiquer la méthode qu'elles utilisent, ça me serait fort bien utile.

Merci,
Antoine


EDIT : En fait, je viens de me rendre compte que la suite de mes questions n'a plus vraiment rapport avec les standards ; je bascule donc sur le Hub, merci.
Modifié par Bouda (13 Jan 2006 - 00:46)

La méthode pour quoi ? Je ne suis pas sure que la question soit complète.

A+ Bouda
Modifié par hibou57 (13 Jan 2006 - 00:46)

La méthode côté PHP.

Pour gérer de l'UTF-8 en PHP, il n'y a pas 36 méthodes !

Tout d'abord, il faut comprendre que le moteur de PHP ne sait pas gérer l'UTF-8 (en faite, PHP ne supporte pas nativement l'Unicode). Donc, lorsque tu va créer des scripts PHP, même s'ils sont encodés en UTF-8, la machine virtuelle chargé d'interpréter le PHP considerera systématiquement qu'elle manipule des caractères ASCII... à priori, cela n'a que peut ou pas d'incidence sur ton code en lui même.

Le seul problème, c'est si tu veux manipuler des chaines de caractères encodées en UTF-8. Dans ce cas, tu as 3 possibilités :

1 - Utiliser l'extention MBString (fortement recommendé... si ton hebergeur ne le propose pas, change d'hebergeur !)
2 - Utiliser l'extention ICONV (Beaucoup moins souple et puissant que MBString, mais parfait pour faire de la conversion d'encodage à la volé)
3 - Utiliser les deux fonction utf8_encode (à chaque fois que tu veux envoyer une chaine vers la sortie standard avec echo ou print par exemple) et utf8_decode (a chaque fois que tu recupères une chaine de texte qui est au format UTF-8)

Pour comprendre comment fonctionne ces 3 solutions, il te faudra lire la documentation : http://www.php.net/manual/fr/


Modifié par Jep (17 Jan 2006 - 15:40)

Voilà une réponse claire et précise comme je les aime, merci à toi.


Je suis actuellement chez OVH, et mbstring n'est pas installée... J'ai contacté le service client, et voici la réponse :

a écrit :
mbstring n'est pas disponible sur php5 mais il l'est sur php4, php5 étant encore en test, l'installation de mbstring ne s'étant pas bien passé, nous l'avons retiré.

Je veux PHP5 ET mbstring moi !
Modifié par Bouda (18 Jan 2006 - 02:41)

Apparement du coté de eskuel , ils traitent le probléme trés bien même pour l'export des tables ...

Contrairement à une idée répandue, les noms de variables, constantes et autres en PHP peuvent tout à fait contenir des caractères dans l’intervalle 128-255 (cependant, dans la pratique, c’est rarement le cas).

Jep a écrit :

3 - Utiliser les deux fonction utf8_encode (à chaque fois que tu veux envoyer une chaine vers la sortie standard avec echo ou print par exemple) et utf8_decode (a chaque fois que tu recupères une chaine de texte qui est au format UTF-8)

À éviter, la fonction utf8_decode() est destructrice, c’est à dire que les caractères dans la chaîne qui n’ont pas d’équivalent en latin1 seront remplacés par un point d’interrogation.