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

Bonsoir !

Une question à laquelle je n'ai pas réellement de réponse : Quel encodage choisir ?

L'encodage iso-8859-1 correspond à l'encodage de l'Europe de l'Ouest. L'iso-8859-15 comprend quelques caractères en plus, dont le signe de l'euro €

Donc cela signifie que l'iso-8859-15 est la "nouvelle version" de l'iso-8859-1 ? Si oui, alors pourquoi tant de site continue d'utiliser l'iso-8859-1 (par exemple Alsacréations) ?

Et pourquoi même en iso-8859-1 j'arrive à afficher le symbole de l'euro (alors que techniquement, il n'aurait pas dû bien s'afficher) ? Serait-ce à cause de la configuration de mon navigateur (qui prend le dessus sur l'encodage définit dans la page) ?

Si oui, comment faire pour les navigateurs ayant des paramètres différents des miens ?

Concernant l'UTF-8, je sais que c'est pour afficher n'importe quel caractères de n'importe quelle langue. De plus, il n'utilise qu'1 octet pour les caractères n'en nécessitant qu'1 (donc il est "intelligent").

Sachant également que je ne compte pas (à priori) mettre des caractères d'autres langues que celles d'Europe occidentales ?

Mais malgré tout, l'utf-8 a une bonne réputation (enfin il me semble), et on dirait qu'il prend de l'importance. Serait-donc "la solution" ?

Je sais que si l'on code en utf-8, il faut encoder également le fichier, cela est un peu plus chiant, mais est-ce le prix à payer pour se voir afficher tous ses caractères convenablement sur tous les navigateurs du monde entier (enfin navigateur récent, quoi) ?

Le XML utilise déjà l'utf-8 comme "the" encodage, doit-on s'attendre de même avec le XHTML ? Même si c'est pas pour tout de suite, est-ce que c'est ce qui va se passer ?

En bref :

Quel encodage choisir ? Pourquoi ? Quels sont les "sacrifices" à faire (par ex. encoder un fichier en plus de spécifier un encodage) ? Qui en bénéficie ? Et qui n'en bénéficie pas ?

Nyro Xeo a écrit :
Donc cela signifie que l'iso-8859-15 est la "nouvelle version" de l'iso-8859-1 ?

On peut le voir comme ça vu qu'il n'y a pas vraiment de perte (les caractères enlevés ne servaient pas vraiment) mais il s'agit dans les fait d'un nouveau jeu de caractère et pas d'une mise à jour de l'ancien (on a changé de nom, on ne s'est pas contenté de changer quelques caractères et de faire une v2 de l'ancien -1)

Nyro Xeo a écrit :
Si oui, alors pourquoi tant de site continue d'utiliser l'iso-8859-1

En vrac :
- parce que les gens ne connaissent pas ou ne pensent pas au -15
- parce qu'il existe encore des logiciels qui connaissent le -1 mais pas le -15 (compatibilité)
- parce que ces gens n'utilisent de toutes façons pas les nouveaux caractères (en HTML si c'est juste pour l'euro une entité suffit)
- parce que le -1 c'est le codage par défaut sur de nombreux protocoles et pas simplicité on utilise les codages par défaut
- parce les personnes n'ont pas fait attention au problème ,)

Nyro Xeo a écrit :
(par exemple Alsacréations) ?

Là il faut poser la question à l'intéressé

Nyro Xeo a écrit :
Et pourquoi même en iso-8859-1 j'arrive à afficher le symbole de l'euro (alors que techniquement, il n'aurait pas dû bien s'afficher) ? Serait-ce à cause de la configuration de mon navigateur (qui prend le dessus sur l'encodage définit dans la page) ?

Au choix :

Parce que Windows n'utilise pas vraiment de l'ISO-8859-1 mais un truc à lui (souvent nommé cp1252). Ce truc à lui c'est du -1 avec quelques variantes, dont le caractère euro (mais pas positionné au même endroit que dans le -15). Les navigateurs ont intégré ce biais et savent que souvent quand la personne dit ISO-8859-1 elle veut dire "dans le truc Windows qui dit être de l'ISO-8859-1". Ils reconnaissent donc ces caractères "spéciaux" (qui globalement ne servent de toutes façons presque pas normalement) et les affichent comme le veux Windows et pas comme le veut la norme (ou alors passent carrément le rendu en cp1252, suivant les navigateurs). Tiens, d'ailleurs tu peux rajouter ça à la liste des raisons sur le "pourquoi"

Ou parce que la page utilise des entités HTML pour afficher l'euro.

Nyro Xeo a écrit :
Sachant également que je ne compte pas (à priori) mettre des caractères d'autres langues que celles d'Europe occidentales ?

Ne jamais dire jamais, parce que le jour où tu changera d'avis ce sera toute une galère.

Nyro Xeo a écrit :
Mais malgré tout, l'utf-8 a une bonne réputation (enfin il me semble), et on dirait qu'il prend de l'importance. Serait-donc "la solution" ?

S'il y avait "une" bonne solution ça se saurait. Dans l'idéal je dirai que l'UTF8 est "la" solution. Maintenant ça pose aussi des problèmes pratiques :
- en PHP (par exemple) le résultat d'un bête strlen() sera faussé et pour avoir un résultat cohérent il faudra utiliser le module mbstring qui n'est pas fréquement présent. Dans bien d'autres langages le problème est le même
- en Mysql (toujours par exemple), l'UTF8 n'est pas officiellement supporté avant la version 4.1 qui vient de sortir et qui n'est pas chez les hébergeurs, pour gérer avec les anciennes versions il faut bidouiller les contraintes de taille
- quand on envoit ou on reçoit des données il faut faire attention que le logiciel ou le serveur en face connait la problématique des codages caractères et comprend bien qu'on lui envoie de l'UTF8 (ou alors faire une conversion), en ISO-8859-1 on n'a pas se problème vu que c'est le codage "par défaut" de quasi tous les protocoles réseaux

Nyro Xeo a écrit :
Je sais que si l'on code en utf-8, il faut encoder également le fichier

Ca veut tout et rien dire. Ton fichier sera forcément dans un "codage", même en ISO-8859-1. Ca veut simplement dire que si tu fais de l'utf8 il faudra mettre des accents UTF8, si tu met de l'ISO-8859-1 il faudra mettre un accent ISO-8859-1. La plupart des éditeurs de code (et en tout cas tous les bons) savent passer en UTF8 nativement, ça devrait être transparent de ce coté là.

Nyro Xeo a écrit :
Le XML utilise déjà l'utf-8 comme "the" encodage, doit-on s'attendre de même avec le XHTML ? Même si c'est pas pour tout de suite, est-ce que c'est ce qui va se passer ?

Si ton XHTML est envoyée en application/xhtml+xml ou en application/xml c'est *déjà* le cas. Maintenant tu peux changer ça via un prologue XML. Il ne s'agit que de codages par défaut, tu peux en déclarer et utiliser un autre.

Nyro Xeo a écrit :
Quel encodage choisir ?

- UTF-8 si tu n'as pas de contrainte technique qui te demande de faire autre chose
- ISO-8859-1 sinon et si tu peux te permettre de coder le symbole euro sous forme d'entité
- ISO-8859-15 sinon (je le met en dernier car le support est globalement moins là que pourl'ISO-8859-1 et ce qu'il apporte coté Web/html est très faible)

Nyro Xeo a écrit :
Si oui, alors pourquoi tant de site continue d'utiliser l'iso-8859-1 (par exemple Alsacréations) ?

En fait, pour les raisons évoquées par Ganf :

- parce que ces gens n'utilisent de toutes façons pas les nouveaux caractères (en HTML si c'est juste pour l'euro une entité suffit)
- parce les personnes n'ont pas fait attention au problème

Mais surtout :
- parce que les gens ne connaissent pas ou ne pensent pas au -15

J'en ai eu connaissance après avoir fait Alsa et je n'ai pas trouvé de motivation suffisante pour changer.

PS : Je mets ce sujet en post-it car il me semble tout à fait intéressant dans ce salon.

PS2 : @Ganf : je me suis permis d'éditer ton post et d'y rajouter les QUOTE pour faciliter la lecture.

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

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)

Je ne sais pas si c'est celui-là, mais en tout cas il est très intéressant :
Codage valide des caractères Windows illégaux en HTML et XHTML

ThomasLinard a écrit :


Je ne sais pas si c'est celui-là, mais en tout cas il est très intéressant

Ce n'était pas celui-là, mais il en demeure très intéressant en effet

A moi de souligner ce billet très intéressant, ce petit up permet aussi de "décoler" l'icone nouveau après un déplacement de sujet

UTF-8, "the solution" ?

Presque oui. On peut tout coder de manière transparante avec ça. Il faut juste que les applications suivent (éditeurs, technologies telles que PHP et mySQL).
Reste un problème incontournable, quelque soit le système d'encodage :

Avec UTF-8 chaque caractère est codé sur un nombre variable de caractères. De 1 à 4 si mes souvenirs sont bon.

Alors... comment dire. Il y a de la place pour tout le monte mais la question est de savoir qui passe en premier ?
Car les langues dont les caractères sont codés sur 3 ou 4 octets verront augmenté l'espéce disque de leurs document.

Alors disont le tout de suite. Les mieux placés sont les américains. Et puis pour des raison de compatibilité aussi, on a préféré garder le code ASCII en tête, comme ça il passe toujours.

Mais les asiatiques sont mal placés (3 ou 4 octets ?) Evidement, on ne peut de toute façon pas les coder sur un seul octet.
En revanche, ils utilisent des systèmes de codages optimisés pour eux (J.. qlq chose pour les japonais) qui leur permettent de coder leur langue sur deux octets à coup sûr. Ils peuvent aussi placer toutes les autres langues, mais ce sont les autres qui occupent les emplacements couteux en octets.

C'est un peu comme la carte du monde. Chaque pays se représente au centre.

Alors les japonais n'aimeront jamais l'UTF-8 ?

Je parie que si UTF-8 à le succès que l'on peut espérer, les japonais se simplifieront la vie en y passant aussi. Car les échanges internationnaux augmentent. En revanche le prix de la mémoire de stockage et du processeur baissent encore.
Leur système à 2 octets ne sera plus qu'une petite économie dérisoire.

Bah sinon passe à l'UTF32 4 octets pour tous le monde, que ce soit japonais ou américain

En fait, si l'UTF-8 ne code les caractère américains que sur un octet, c'est pour garder une compatibilité avec le système ASCII actuel. Du coup, les agents utilisateurs ne supportant pas l'Unicode affichent les documents avec un minimum de casse, à condition qu'on se limite à certains caractères...

Raphael a écrit :

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

C'est peut-être celui-ci :

http://openweb.eu.org/articles/jeux_caracteres/

J'ai eu 2 problèmes avec UTF8 dont un sûrement lié aux caractères illicites et le lien précédent proposé va me le confirmer (Merci ThomasLinard)

Salut les amis ,
J'ai des pages avec des formulaire en html aux quels sont relié des pages en php avec ajout en php de caractère sur un serveur qui travaille en utf 8 maintenant et oups du jour au lendemain du changement je n'ai plus rien qui fonction pourriez vous m'aider.
Merci.

voici comment se présente les formulaires.
$pseudo = AddSlashes (htmlentities($pseudo));
$model = AddSlashes (htmlentities($model));

mysql_query("INSERT Into annonce_immo VALUES ('','$date','$pseudo','$model'") or die ("erreur requète");

Utilise le iso-8859-15

c2pk a écrit :
Utilise le iso-8859-15

nooooon !!!!

utilise utf-8 partout !!!!
réenregistre tes fichiers en utf-8, dis à mysql que ton interconnection est en utf-8 (très facile à faire avec phpmyadmin), sers-toi si nécessaire de la fonction utf_encode(); de php (normalement tu n'en auras pas besoin à partir du moment où tes fichiers sont en utf-8 et ton interconnection mysql aussi).

IMPORTANT, VOIRE PRIMORDIAL utilise ceci :

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

avant d'exécuter une requete (si tu as fait une class mysql, tu cole cette instruction tout de suite après mysql_connect(nom, passe, base, serveur); et avant d'exécuter une autre requete - teste éventuellement en mysql en ligne de commande).

J'ai un peu galéré pour tout passer en utf-8 il y a quelques mois (pareil, mon hébergeur était passé en utf-8 en enlevant carrément les iso machin), mais une fois que c'est fait, c'est tout bon !

le SEUL et je dis bien le SEUL truc que j'ai gardé en ISO-machin, c'est l'établisssement des documents pdf par la bibliothèque fpdf, mais c'est très simple en disant utf_decode() sur les valeurs récupérées de mysql avant de les passer à fpdf.

Je dois dire que personnellement, je suis contre l'utf8, ça pose plein de problèmes à la con qu'on a pas en iso.

Par exemple : tri SQL ou tri de tableaux par ordre alphabétique : é vient après z...

URLs : Si j'ai un fichier nommé "été.html", il reste toujours accessible via <a href="%e9t%e9.html"> mais ce n'est plus le cas en utf8.

Dans les formulaires, les saisies accentuées sont tout buggées



Donc, inutile d'utiliser utf8 si on sait d'avance qu'on ne va jamais traduire son site en japonais, en russe ou en chinois...

Bonsoir,

QuentinC a écrit :
Je dois dire que personnellement, je suis contre l'utf8, ça pose plein de problèmes à la con qu'on a pas en iso.

Et inversement, iso pose plein de problèmes à la con qu'on n'a pas en utf-8.

Cela étant dit, je ne considère pas que ce serait une raison personnelle d'être "contre iso"

Laurent Denis a écrit :
Et inversement, iso pose plein de problèmes à la con qu'on n'a pas en utf-8.

... Comme ?

Bonjour,

Je me joins à ce sujet fort intéressant !

Je souhaite moi aussi me mettre à l'utf8, cependant je rencontre des difficultés:

- mes pages sont codées en utf8
- mon charset pour l'affichage XHTML est de l'utf8

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 ?

é cest le é utf8 affiché en iso... ta database ne doit pas être réellement en utf8.

Ou alors tout simplement cela provient de l'affichage avec phpadmin ?

Parce que mon champ est en utf8 general, ma table et ma base de données également ! en revanche à l'affichage de ma page cela fonctionne j'ai bien le bon caractère sauf dans ma base !
pareil si j'insère directement des car. spé. dans ma base il ne me les affiche pas correctement sous ma page xhtml !? peut etre as-tu raison mais comment faire ?

En plus j'ai fais un tour pour comparer avec de l'ut-8 ou faire certain traitement standard il faut changer pas mal ces habitudes...
strpos -> mb_strpos
strlen -> mb_strlen

Et il faut que l'hébergeur active le module mbstring!
Modifié par thierry8 (11 Dec 2005 - 12:09)

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é
Modifié par thierry8 (11 Dec 2005 - 14:07)

thierry8 +1