Encodage, interclassement, jeu de caractères

[Lilive]

J'ouvre ce nouveau sujet pour avoir des informations concernant les jeux de caractères...
J'explique mon cas.
En voyant tous les interclassements proposés par PHPmyAdmin, j'ai fouiné sur le web en quête de savoir lequel choisir. Sans trouver de réponse franche, je me suis arrêté au Latin 1 et à l'UTF-8. Malgré cela, il m'arrive des déconvenus dans certains cas de figures : le copier-coller depuis word... Ce gentil logiciel transforme les apostrophes et les - en caractères spéciaux non reconnus par certains jeux de caractères et remplacés alors par des ?...
Ma solution actuelle est de dire à mes utilisateurs d'exporter leur document word en txt en format UTF-8 avec autorisation de remplacement de caractères...
Pour des gens qui ne connaissent QUE word c'est déjà assez laborieux... Si quelqu'un connait un moyen de remédier à cela d'une manière simple, je suis très intéressé.

[martin]

Et tu rentres ces données issues de word comment ? Copier/coller via phpmyadmin, script automatisé en ligne ... ?

[calimo]

Attention, le latin-1 est limité et ne supporte pas certains caractères comme : "…" (3 petits points), "Ž" (l'apostrophe bizarre, préférer l'apostrophe normale : '), et quelques autres. S'ils sont copiés depuis Word, il pourrait être préférable d'utiliser l'encodage windows-1252 qui comprend ces caractères.

UTF-8 permet d'encode tous les caractères unicode (près de 100'000), autrement dit tous les caractères que n'importe qui sur cette planète pourrait avoir envie d'utiliser.

[Lilive]

Et tu rentres ces données issues de word comment ? Copier/coller via phpmyadmin, script automatisé en ligne ... ?

Mes utilisateurs ont par exemple des comptes-rendus ou des résumés sous word et doivent les passer dans des formulaire html qu'un script PHP récupère pour compléter la base de données.

Si je définis ma base de données en UTF-8, je suis tranquille pour les copier/collers directs dans la base. Mais est-ce suffisant ? Vu que mon info transite par un formulaire, puis par un script...
Comment être sûr que ces caractères spéciaux vont arrivés indemnes au bout de la chaîne.
Pour l'instant, quand ça m'affiche des ?, je reprends manuellement les enregistrements pour les corriger avec des caractères "classiques"... Autant dire que je ne vais pas passer ma vie à corriger les remplacements automatiques de Word.

Au fait : PHP n'a pas une super fonction qui permettrait de formater une chaîne automatiquement pour que tous les caractères spéciaux soient transformés en caractères moins spéciaux... ?

[calimo]

Comment être sûr que ces caractères spéciaux vont arrivés indemnes au bout de la chaîne.

En gardans la main d'un bout à l'autre de la chaine et en sachant à chaque étape quel est l'encodage utilisé (et en faisant les transformations nécessaires)
http://french.joelonsoftware.com/Articles/Unicode.html

Au fait : PHP n'a pas une super fonction qui permettrait de formater une chaîne automatiquement pour que tous les caractères spéciaux soient transformés en caractères moins spéciaux... ?

htmlentities je crois, mais si de l'info est perdue avant ça ne va pas fonctionner.
Or le problème se situe très certainement à l'envoi, les navigateurs ayant la vilaine habitude de ne pas respecter correctement les encodages (et traiter le latin-1 comme du windows-1252 dans la plupart des cas, alors qu'ils annoncent quand-même latin-1). Donc php reçoit la chaine déjà corrompue.

[Lilive]

Oui, j'ai déjà lu cet article...
Effectivement, la balise meta
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
peut permettre un affichage correct de la page, mais qu'en est-il du contenu d'une variable POST ? Peut-on également définir un jeu de caractère pour forcer le navigateur à ne rien modifier ? La balise ENCTYPE du formulaire est-elle suffisante et est-elle correctement interprétée ?

[calimo]

Oui, j'ai déjà lu cet article...
Effectivement, la balise meta
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Ne pas oublier que la balise meta est moins importantes que les entêtes HTTP.

Si tu as une entête HTTP :

Code : Tout sélectionner

Content-type: text/html; charset=iso-8859-1

ta page sera en latin-1

peut permettre un affichage correct de la page, mais qu'en est-il du contenu d'une variable POST ?

Normalement, il s'agit du même jeu de caractères que la page. Cela dit il y a des exceptions un peu compliquées si le navigateur ne la respecte pas, et là je ne sais pas trop comment ça se passe (le pire étant que le navigateur indique autre chose que ce qu'il envoie réellement, mais là il n'y a rien à faire, c'est perdu !)

Peut-on également définir un jeu de caractère pour forcer le navigateur à ne rien modifier ?

Avec l'attribut accept-charset de l'élément form je crois (à vérifier dans les specs)

La balise ENCTYPE du formulaire est-elle suffisante et est-elle correctement interprétée ?

Connais pas. C'est standardisé ?

[Lilive]

Excuse-moi, ENCTYPE n'est pas une balise mais un attribut de la balise FORM : enctype='multipart/form-data' permet en théorie de récupérer du texte non-ASCII... alors que ce n'est que de l'ASCII par défaut (d'après ce que j'ai lu...).

Je trouve assez étonnant que, vu l'importance de la communication sur le Web, il n'y ait rien de fait pour faciliter ces problèmes de jeux de caractères...
J'imagine que ce doit être extrêmement plus compliqué qu'il n'y paraît pour que ce n'ait pas encore été résolu d'une manière simple...

[calimo]

C'est peut-être compliqué, mais il y a une question de volonté.

Les américains n'utilisent que l'ASCII. Ils n'ont pas besoin de résoudre ce problème qui n'existe même pas. D'ailleurs la plupart ne savent même pas ce que signifie encodage et quand on leur parle d'utf-8 alors là c'est fichu !
Donc forcément, les choses bougent lentement

[Lilive]

Conclusion : merci les 'ricains !

En tout cas, merci pour tous tes conseils, ça me sera utile.

[Bobe]

La balise ENCTYPE du formulaire est-elle suffisante et est-elle correctement interprétée ?

Connais pas. C'est standardisé ?

C’est utile notamment pour les formulaires d’upload (enctype="multipart/form-data"), car alors, les données doivent être envoyées dans un autre format que celui par défaut.

Lilive> Pour ton problème, l’idéal serait bien entendu que ta page soit en utf-8. De ce fait, le navigateur en face t’enverrait directement de l’utf-8 lors de la soumission du formulaire.

Du coté du script PHP, il faut d’abord indiquer à mysql que tu lui envoies de l’utf-8 donc exécuter la requète SET NAMES utf8;. Ensuite:

a/ ta page html est en utf-8. Les données que tu vas recevoir sont donc déjà en utf-8, tout va bien.

b/ ta page est en iso-8859-1. Les données reçues risque de comporter des caractères provenant de windows-1252, il est donc nécessaire de faire la conversion (à faire de toute façon puisqu’on doit passer des données en utf-8 à mysql). Dans ce cas, il faut le module PHP mbstring.

Code : Tout sélectionner

$str = mb_convert_encoding($str, 'UTF-8', 'Windows-1252');

Plus d’infos sur windows-1252 :
http://forum.alsacreations.com/topic.ph ... &s=#p56012

Je donne également dans ce fil une fonction permettant de faire la transformation windows-1252 -> utf-8 (utile si jamais tu n’as pas l’extension mbstring de php) et une autre pour transformer ces caractères qui posent problème en entité numérique html (dans ce cas, tu souhaiteras probablement passer la chaîne telle quel à mysql sans l’encoder en utf-8, donc inutile d’exécuter la requète SET NAMES…).

[martin]

Le formulaire envoie un fichier ou du contenu texte ?

Si c'est un fichier texte que tu traites sur le serveur, la fonction utf8_encode() est peut être ton amie, sinon les fonctions mbstring (si installées sur ton serveur) peuvent peut être t'aider(mb_convert_encoding), ou les fonctions iconv.
Enfin on trouve des classes php via google pour faire également des conversions vers utf-8.

Si c'est des chaines de caractères que reçoit le serveur, essaie de trouver l'encodage de ce que tu reçoies, a priori les copier/coller sont gérés par les applis, c'est à dire que si je copie un texte dans un encodage et que le colle dans un autre document qui a un encodage différent, la conversion devrait être gérée nativement.
j'essaierai (pas sûr de moi) que ma page html contenant le formulaire soit en utf-8 (avec envoie d'un header en php approprié : header("Content-type: text/html; charset=UTF-8"); ). En principe le formulaire devrait alors envoyer de l'utf-8. Sinon, ben de nouveau essaie de convertir avec les fonctions précédentes.