Le sam 06/03/2004 à 23:56, Denis Barbier a Ãcrit : > Quand le codage peut > Ãtre spÃcifiÃ, ce qui est le cas dans l'immense majorità des cas (le > contre-exemple flagrant Ãtant le nommage des fichiers), on n'a pas > besoin d'imposer un codage unique.
Nous sommes bien d'accord (à part pour  immense majorità des cas Â). Mais un codage en particulier ne peut pas tout dÃcrire. Si j'envoie un mail ne contenant que des caractÃres pouvant Ãtre dÃcrits en iso8859, il sera encodà ainsi par evolution (cf. les autres mails de cette discussion). Maintenant, si je mets des kanji (ææ), il va Ãtre encodà en utf-8. On en revient au mÃme point. Et c'est pareil pour le web : si tu veux une page avec à la fois du FranÃais et du Japonais dessus, tu auras du mal sans utiliser utf-8. Quand bien mÃme c'est possible d'avoir l'information sur l'encodage, Ãa ne suffit pas toujours. Je suis encore tombà sur un exemple à la con : les signets à paramÃtres de galeon (ou autre). Quand tu vas sur google.fr et que tu cherches un mot avec des accents, il se dÃmerde avec l'encodage en envoyant le formulaire, car la page de dÃpart contient un encodage (iso8859-1 ici). Mais quand tu veux faire une recherche en utilisant directement un signet, tu n'as pas l'information sur l'encodage dans lequel le site à l'autre bout veut ses informations. Et, corrigez-moi si je me trompe, autant HTTP prÃcise un encodage pour ce que le serveur envoie, autant le client ne peut pas prÃciser en quoi son URL est encodÃe, et doit donc prÃsupposer qu'elle est en utf-8. Et ma recherche sur RÃmi se transforme en RÃÂmi. Alors oui, gÃnÃraliser les mÃta-donnÃes sur l'encodage est une bonne chose, mais Ãa ne suffit pas, et c'est de toute faÃon inutile si tu veux un systÃme vraiment multilingue. -- .''`. Josselin Mouette /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
