Iso-8859-1, iso-8859-15, utf-8, lequel choisir ?

(reprise du message précédent)

thierry8 +1

thierry8 a écrit :


PROBLEME:
L'orsque je souhaite enregistrer un caractère spécial comme "é" ou "€" réceptionné d'un formulaire dans une base de données gros problème !

Ma base de données est en utf8. (interclassement)

Si je récupère les valeurs du formulaire et que je les affiches directement, aucun soucis, il s'affiche bien ! Si je récupère une valeur de ma base de données il faut que je la traite avec htmlentities($test,ENT_QUOTES,'utf-8'), de manière à obtenir un affichage cohérent et donc m'afficher le bon caractère !

En revanche dans ma base de données...
- pour le "é" j'obtiens: é
- pour le "€" j'obtiens: €

(et là je n'est pas tout testé !)
Donc ma question est simple comment faire pour avoir un affichage compréhensible dans ma base de données ?

La solution est simplissime, le problème se pose même quand la base est en utf8, je l'ai indiqué dans mon post juste avant. Dans php, tu indiques ceci juste après avoir établie la connection avec mysql :

mysql_query("SET NAMES, 'utf8'");

et là... comme par miracle, ça devrait marcher !
Modifié par thiebo (12 Dec 2005 - 11:39)

Salut,

Et bien je crois que je vais apporter une pierre a l'edifice d'utf-8 ...
j'ai le meme probleme que thierry8 sauf que l'interclassement de ma base (MySQL) est en latin1, un champ de formulaire, saisi par un utilisateur lambda, contenant le sigle €, stocké dans la base et reformaté par le biais de htmlentities() n'affiche pas &euro mais €, donc ce n'est pas "valide";
m'etant apercu du probleme j'essayais betement de faire : htmlentities($var, ENT_COMPAT, 'iso8859-15') sauf qu'a la place de € j'obtenais '?' ce qui n'est a priori pas "accessible" ...
la raison est que MySQL ne connait pas le charset iso-8859-15 (je viens de l'apprendre ce soir en lisant le manuel , faite

mysql>SHOW CHARACTER SET;

il n'y a pas de latin9 aka iso-8859-15 ! ).
donc j'ai l'option de laisser les choses en l'etat (tout reste en 8859-1 : base, page, editeur et tant pis si un jour y'a un € qui traine, finalement comme Alsacreations... ), l'alternative d'un charset windows et là autant aller en enfer tout de suite , ou tout basculer en utf-8 avec ce que ca implique : base plus lourde, fonctions a revoir, mais des page pérennes, valides et accessibles dans n'importe quel navigateur et OS connaissant utf-8 (je pencherai naturellement vers cette solution, mais je suis déjà à la bourre dans mon developpement , 2 mois de boulot a revoir, et loin d'etre un expert es PHP )
enfin pour finir, j'aime bien savoir ce que je fais, donc la solution de Thiebo m'a intriguée , et l'explication est donc : (extrait manuel mysql 5.0, section 10.3.6)

a écrit :
Il y a deux commandes qui permettent de modifier le jeu de caractères de la connexion :

SET NAMES 'charset_name'
SET CHARACTER SET charset_name

SET NAMES indique ce qui est dans la commande SQL que le client envoie. Par conséquent, SET NAMES cp1251 indique au serveur : ``les futurs messages fournis par ce client seront dans le jeu de caractères cp1251'' et le serveur est libre de les traduire dans son propre jeu de caractères, éventuellement.

La commande SET NAMES 'x' est équivalente à ces trois commandes :

mysql> SET character_set_client = x;
mysql> SET character_set_results = x;
mysql> SET character_set_connection = x;

SET CHARACTER SET est similaire, mais spécifie le jeu de caractères et la collation par défaut des bases pour la connexion. Une commande SET CHARACTER SET x est équivalente à :

mysql> SET character_set_client = x;
mysql> SET character_set_results = x;
mysql> SET collation_connection = @@collation_database;

Lorsque vous exécutez la commande SET NAMES ou SET CHARACTER SET, vous changez aussi la collation de la connexion. Cependant, la collation de connexion existe uniquement par cohérence. Généralement sa valeur n'a pas d'importance.

@+

PS et vive les standards, pour qu'on en finisse avec ces prises de tetes
Modifié par lovetronic (19 Dec 2005 - 00:51)

lovetronic a écrit :
donc j'ai l'option de laisser les choses en l'etat (tout reste en 8859-1 : base, page, editeur et tant pis si un jour y'a un € qui traine, finalement comme Alsacreations... ), l'alternative d'un charset windows et là autant aller en enfer tout de suite ...

Au pire, ce n’est pas dramatique si les données sont stockées en Windows-1252 dans la base de données. Ce qu’il faut éviter surtout, c’est d’utiliser ce jeu de caractères dans les pages HTML (il entre en conflit avec la déclaration SGML du HTML).

Donc si on utilise PHP, on peut par exemple utiliser la fonction purge_iso88591() que je donne dans ce sujet :
http://forum.alsacreations.com/topic.php?fid=17&tid=6460

Typiquement, on l’utilisera pour traiter les données en sortie, donc avec ob_start('purge_iso88591').

Bobe a écrit :


Au pire, ce n’est pas dramatique si les données sont stockées en Windows-1252 dans la base de données.

Pour moi si !!! (bon peut etre que j'exagere un peu là )
hormis le coté integriste, il est quand meme plus sur d'essayer de maitriser toute la chaine de traitement de A a Z ,du debut a la fin, surtout avec des formulaires livrés en pature ...
mais ta fonction a l'air bien sympa (j'etais en train de faire a peu pres la meme chose avec preg_replace ...) , je vais tester ca .
Et on va peut etre pas trop insister avec php/sql ca va virer off-topic..
En tout cas , pour moi à l'avenir ca sera utf-8 , et peut etre le present (si delais suffisants), il y a une notion d'universalité qui me convient tout a fait , une table standardisée de tous les caracteres , pour tous le monde, toutes plateformes, en rapport modifier ses habitudes de code c'est vraiment pas important .
La question que je me pose c'est la compatibilité descendante ? ou est le probleme coté client ? any idea ?
++
Modifié par lovetronic (19 Dec 2005 - 04:28)

thierry8 a écrit :
Si mon avis peut aidé certain: (conclusion tiré après beaucoup d'heure de travail entre l'utf-8 et l'ISO-8859-1)

Avis totalement personnel !

Je pense que l'utf-8 est à ce jour est très très mal compris, ou plutôt que les éléments mis à notre disposition (fonctions) ne sont pas encore optimisée pour simplifier leur utilisation ! Beaucoup d'embêtement pour faire des traitements, pour des stockages dans une base de données...
La preuve est qu'il faut pour tout cela un module bien spécifique et utiliser un tas d'autre fonction (similaire aux autres) mais cela aurait pu être intégré directement, plutôt que de devoir tout changer !

L'UTF-8 est donc utile si vous créé un site japonais, chinoix, etc...
(c'est d'ailleurs plus ou moins pour cela que ce codage existe)

Un site allemand, anglais, italien, espagnole ? L'ISO-8859-1 est largement suffisant !

N'hésiter pas à critiquer mon avis. Cela me permettra de voir les choses que j'ai oublié ou négligé

Sauf qu'on finira bien par tous se mettre à utf8, et si tu crées une base aujourd'hui, tu as peut être intérêt à penser à d'ici un an ou deux, quand mysql sortira une version plus conforme encore avec utf8. Au fond, si tout le monde parle la même langue, c'est tout de même plus facile. Je ne cherche bien sûr pas à construire une tour de babel, mais uniformiser les moyens de communication est avantageux pour tout le monde et il faut bien espérer que les ISO-machin vont TOUS finir par disparaître au profit des UTF8 et UTF16.

Je commence à me mettre à l'utf-8.

Etant donné que je souhaite respecter au mieux les standards, je commence par utiliser l'encodage qui se veut être LE standard du web.

Je pense qu'il est donc préfèrable d'encoder en utf-8 afin d'assurer une meilleure compatibilité pour toutes les plateformes.

++

Bonjour,

Je viens de tomber sur cette conversation très intéressante pour moi.

J'ai un base de données provenant d'un vieux forum phpBB 1.4 codé je ne sais pourquoi en UTF-8

J'aimerai pouvoir mettre cette base de données SQL en ISO-8859-1, est-ce possible et comment faire. Y a t-il un logiciel qui pourrait faire ça ?

Ma demande est peut-être incongrue, mais je ne connais pas les codages, cela ne fait pas très longtemps que je m'y intéresse.

Merci de votre aide
Cordialement
Pascal

Bonjour,

Raphael a écrit :

PS3 : j'avais lu un billet très intéressant une fois à ce propos mais je ne le retrouve pas (appel subliminal)

Comme Laurent n'a pas fait sa pub, et que je viens justement de rechercher des infos à ce sujet...
Spécifier l'encodage des caractères d'un document (X)HTML

Bonjour !

Je viens de lire le sujet et je vois qu'il y a les "pros" et les "antis" UTF-8. Etant débutante dans le langage web, je ne suis pas sûre d'avoir saisi toutes les subtilités du débat, mais j'aurais une question :

Dans la mesure où je suis amenée à écrire en chinois, l'UTF-8 est-elle la meilleure solution ? En existe-t-il d'autres ?

Merci !


P.S. : Bon, pour l'instant je n'utilise ce forum que pour poser des questions, mais quand je serai un peu plus calée, j'essaierai d'y participer de manière plus active
Modifié par Armony (29 Mar 2006 - 14:34)

Je pense que passer à l'utf8 est très important... c'est un peu la même philosophie que de suivre des standards. C'est clair que pour du français on à pas de problème... enfin non car on à dut faire iso machin -15 juste à cause du signe de l'euro...
utf8 est ENFIN la solution au problème de passage de fichier entre les différente pays,système,logiciel et j'en passe, ne passer pas à côté!!!
Nous somme dans une phase de transition comme avec l'xhtml il y à deux ans, mais dés que la phase de transition sera passé et que tout les logiciel seront par défaut en utf8 il n'y aurra plus de problème...
Pour les db exécuté ces deux requettes après votre connexion (ça devrait régler les problème).
SET CHARACTER SET 'utf8'
SET collation_connection = 'utf8_bin''utf8'

EDIT: oups j'avais pas vu qu'il y avait deux page... sorry...
Modifié par gagarine (29 Apr 2006 - 20:35)

Bobe a écrit :
Typiquement, on l’utilisera pour traiter les données en sortie, donc avec ob_start('purge_iso88591').

Bonjour à vous et merci pour votre aide.
J'utilise actuelement la fonction ob_start de cette manière:
ob_start("ob_gzhandler");
J'ai essayé :
ob_start("ob_gzhandler", "purge_iso88591");
Mais bien sur cela ne marche pas.
Pouvez vous m'aider?

Sined_style a écrit :

Bonjour à vous et merci pour votre aide.
J'utilise actuelement la fonction ob_start de cette manière:
ob_start("ob_gzhandler");
J'ai essayé :
ob_start("ob_gzhandler", "purge_iso88591");
Mais bien sur cela ne marche pas.
Pouvez vous m'aider?

D'après les spec, il est possible de faire ceci, mais je n'ai jamais essayé :

<?php
ob_start("ob_gzhandler");
ob_start("purge_iso88591");
?>
<!doctype ....... 
<html .... >
....
</html>
<?php 
ob_end_flush();
ob_end_flush();
?>

Fais juste gaffe de ne pas faire le contraire ...

Bonjour,

Je me permet de faire remonter le sujet, car cela n'est pas encore clair dans ma tête, malgré les multiples pages web que j'ai consultés sur la question.

J'ai fait un petit test ; je me suis crée 2 pages htms, l'une encodée en utf-8 et l'autre en iso-8859-1 avec des caractères accentués pour chacune :

utf-8 :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
  <head>
    <title>Votre titre</title>
    <meta http-equiv="Content-Type" content="text/HTML; charset=utf-8" />
  </head>
  <body>
    à é ù 
  </body>
</html>

iso-8859-1 :

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
  <head>
    <title>Votre titre</title>
    <meta http-equiv="Content-Type" content="text/HTML; charset=iso-8859-1" />
  </head>
  <body>
    à é ù 
  </body>
</html>

Dans le navigateur, la page encodée en iso-8859-1 fait correctement apparaître les caractères accentués.
Par contre, la page encodée en utf-8 fait apparaitres des points d'intérrogation à la place des caractères. Si je veux pouvoir afficher mes caractères accentués, je dois mettre à la place de mon caractère une entité html ("é" pour obtenir "é" par exemple).
Donc mon premier reflexe, c'est de me dire qu'avec l'encodage iso-8859-1, je vais pouvoir garder un code "propre" en gardant les accents dans mes paragraphes, alors qu'un encodage en utf-8 me le "salira" par l'apparition de nombreuses entités html.

Est-ce que je dis des bétises ?
Modifié par buh31 (28 Aug 2006 - 23:12)

buh31 a écrit :

Dans le navigateur, la page encodée en iso-8859-1 fait correctement apparaître les caractères accentués.
Par contre, la page encodée en utf-8 fait apparaitres des points d'intérrogation à la place des caractères. Si je veux pouvoir afficher mes caractères accentués, je dois mettre à la place de mon caractère une entité html ("é" pour obtenir "é" par exemple).
Donc mon premier reflexe, c'est de me dire qu'avec l'encodage iso-8859-1, je vais pouvoir garder un code "propre" en gardant les accents dans mes paragraphes, alors qu'un encodage en utf-8 me le "salira" par l'apparition de nombreuses entités html.

Est-ce que je dis des bétises ?

IL ne faut pas oublier une chose : les entêtes HTTP
Si tu regardes le type d'affichage que sélectionne ton navigateur lorsque tu appelles ta page utf8, tu verras qu'il est en AINSI. Si tu le mets en unicode, tu n'auras plus de point d'interrogation.
Le navigateur sélectionne l'encodage d'affichage en fonction de l'entete HTTP. Il faut donc, modifié ton entete HTTP.
En PHP, tu peux utiliser la fonction header, sinon, il faut utiliser les fonctions charset de Apache

Sinon, je reviens sur le débat
Voici pourquoi j'utilise utf8 partout.
Aujourd'hui, je ne suis plus le seul a utiliser AJAX. J'utilise JSON_services pour convertir mes tableaux PHP en structure JSON. Cette conversion travaille uniquement sur de l'ascii ou utf8 !
Je vais donc avoir des problemes si j'utilise notre ISO dans ma bdd ou mes pages html.
Par contre, c'est assez deroutant dans ce cas precis d'une fonction PHP qui travaille sur de l'urf8 alors que PHP ne comprends pas utf8 nativement... Je dois malheureusement utiliser les fonctions encore_utf8 dès que j'utilise cette fonction.

Tout ca pour dire que l'utf8 permet l'internationalisation, et non pas uniquement dans l'affichage, mais également dans le code et qu'une utilisation de l'utf8 serait rendre compatible sans aucun travail de conversion de nombreuse application.

Bonjour à tous !

Depuis ce soir, je m'interrogeai sur le problème.

Il est pour moi résolu. Il suffit d'indiquer un charset ISO-8859-1 dans vos pages et dans IE, Firefox et toute la clique, vous mettez encodage UTF-8.

Par contre, j'ai remarqué que si vous indiquez un codage ISO-8859-1 et que vous afficher en ISO-8859-1 SOUS FIREFOX et bah les accents et le logo € ne s'affichent pas...

C'est bizarre que ça le fasse avec mon site car ici Alsa, c'est en ISO et pourtant j'affiche ISO mais ya les accents et € alors...

Alors j'ai remarqué que le codeur de mon design avait du enregistré en UTF et il suffit de recodé le fichier en ANSI et le passé en Unix puis en Windows, retapé les accents et bizarrement tout va mieux !

J'espère vous avoir aidé à résoudre votre problème et gardez ISO, c'est mieux.

@+

désolé baba, je comprends rien à ce que tu racontes.

a écrit :
Par contre, j'ai remarqué que si vous indiquez un codage ISO-8859-1 et que vous afficher en ISO-8859-1 SOUS FIREFOX et bah les accents et le logo € ne s'affichent pas...

Il est normal que tu n'arrive pas à afficher le signe euro en iso-8859-1, car ce symbole n'appartient pas à ce charset, il faut utiliser l'iso-8859-15 pour cela. Quand aux accents, il doit effectivement s'agir d'un mauvais encodage du fichier.

@ bush31

vérifie qd même que ton éditeur de texte a bien enregistrer la page comme de l'utf8 (le ? est typique d'un accent codé en iso 8859-1(5) et lu en utf8)

a écrit :
PS3 : j'avais lu un billet très intéressant une fois à ce propos mais je ne le retrouve pas (appel subliminal)

le billet oublié ? :
http://french.joelonsoftware.com/Articles/Unicode.html
Modifié par gonga (22 Oct 2006 - 18:19)

Bon billet, même s'il commence à dater.