Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Le bon charset...

166 réponses
Avatar
METIS
Bonjour,
comme je ne suis pas un codeur fou, j'utilise Dreamweaver pour composer mes
pages (et non pas Bloc-notes(;o))).
Par défaut, le charset est...
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Est-ce que c'est pertinent (en général) ?
Vous allez me dire que ça dépend...?
(;o)))))))))

--
<|[;o)) METIS
http://www.graphM.com
Pour m'écrire en privé,
moi c'est metis15 et
je tourne à l'Oranges...

10 réponses

Avatar
METIS
Andreas Prilop wrote:
On Thu, 11 Dec 2008, METIS wrote:

X-Newsreader: Microsoft Outlook Express 6.00.2900.5512

Mais ? part ces propos de sp?cialistes, que dois-je conclure??



Outils > Options > Envoyer
Format d'envoi du courrier > Texte brut > Parametres > Format du
message MIME Coder le texte: Aucun
Format d'envoi des News > Texte brut > Parametres > Format du
message MIME Coder le texte: Aucun



OK, j'étais réglé comme tu dis pour le courrier, mais en UUENCODE pour les
news.
J'ai donc tout mis en MIME

Mais comme j'ai des problèmes sur la reception d'email, ça doit pas être là
le problème..?

--
<|[;o)) METIS
http://www.graphM.com
Pour m'écrire en privé,
moi c'est metis15 et
je tourne à l'Oranges...
Avatar
Pierre Goiffon
Paul Gaborit wrote:
Mais de toute façon il n'y a pas que le client mail utilisé au final qui
importent : toutes les passerelles comptent...


Ah non ! Il existe peut-être encore des passerelles préhistoriques en
SMTP qui ne supportent pas l'envoi en 8bit, mais le problème concernera
autant Latin1 qu'UTF-8.



A priori, ça ne pose pas de problème : les MTA (Message Transfert
Agent) gérant les messages en 8bit (donc ESMTP) détectent si un MTA
particulier n'est que 7bit et savent alors convertir les messages en
7bit (via le quoted-printable) et l'encodage du message laisse alors
complètement indifférent le MTA.



J'ai déjà vu un antivirus qui donnait des résultats très...
désagréables, c'est à ça que je pensais, plus tous les autres services
qui existent aujourd'hui (anti-spam, extraction pj dans un dépot
central, ...)
Mais je ne connais pas assez bien le sujet pour être affirmatif
Avatar
Pierre Goiffon
Sergio wrote:
Quand même étonnant ? Le japonais, comme toutes les langues asiatiques
qui utilisent des caractères non-latins, sont les premiers demandeurs
d'UTF-8, ou me trompé-je ?



UTF-8, non : ce codage a été fait pour conserver une compatibilité avec
us-ascii, et par là même "favorise" grandement les scripts latins. Donc
pour les langues d'Asie c'est un mauvais choix en terme de taille (3
octets et plus)
Le jeux de caractères Unicode par contre, sans doute.

Mais de ce que j'ai compris, le consortium a mis du temps à se pencher
sur les langues correspondantes (à confirmer, c'est ce que j'ai compris
en discutant avec quelques interlocuteurs techniques), et les
implémentations sont arrivées tard (confirmé : rien que pour le
français, UTF-8 ne peut être utilisé que depuis relativement peu)
Avatar
Paul Gaborit
À (at) Fri, 12 Dec 2008 17:56:34 +0100,
Pierre Goiffon écrivait (wrote):
Paul Gaborit wrote:
A priori, ça ne pose pas de problème : les MTA (Message Transfert
Agent) gérant les messages en 8bit (donc ESMTP) détectent si un MTA
particulier n'est que 7bit et savent alors convertir les messages en
7bit (via le quoted-printable) et l'encodage du message laisse alors
complètement indifférent le MTA.



J'ai déjà vu un antivirus qui donnait des résultats
très... désagréables, c'est à ça que je pensais, plus tous les autres
services qui existent aujourd'hui (anti-spam, extraction pj dans un
dépot central, ...)
Mais je ne connais pas assez bien le sujet pour être affirmatif



C'est malheureusement tout à fait plausible. Mais on sort du rôle du
MTA.

En fait, les anti-virus, anti-spam et autres outils sont des greffons
qui s'intéressent au contenu des messages et qui ne sont évidemment
pas indifférents à leurs encodages. Mais ce n'est pas la chaîne de MTA
qui est en cause mais bien certains de ces greffons écrits avec les
pieds qui ne savent même pas respecter les RFC de ce qu'ils sont
censés savoir analyser.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Avatar
METIS
Olivier Miakinen wrote:
[...]
Et METIS, dans tout ça ? Eh bien son premier é est codé en Latin1, le
second en UTF-8, ce qui donne :



Mouai...
Alors quand je mets la balise META comme ça :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Et le fichier en PHP comme ça :
<?php
header('Content-Type: text/html; charset=UTF-8');

Ca suffit donc pas... et je ne sais toujours pas pourquoi...
(enfin si ça a été dit, je me suis embrouillé les pinceaux des yeux qui
n'ont rien vu ?)

--
<|[;o)) METIS
http://www.graphM.com
Pour m'écrire en privé,
moi c'est metis15 et
je tourne à l'Oranges...
Avatar
Bruno Desthuilliers
METIS a écrit :
Olivier Miakinen wrote:
[...]
Et METIS, dans tout ça ? Eh bien son premier é est codé en Latin1, le
second en UTF-8, ce qui donne :



Mouai...
Alors quand je mets la balise META comme ça :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Et le fichier en PHP comme ça :
<?php
header('Content-Type: text/html; charset=UTF-8');

Ca suffit donc pas... et je ne sais toujours pas pourquoi...



parce que (pour la troisième fois au moins) il faut que l'encodage que
tu *déclares* correspondent à l'encodage *effectivement utilisé* pour
enregistrer ton fichier. Il ne suffit pas de dire qu'un morceau de
camembert est de l'emmenthal pour qu'il devienne de l'emmenthal par magie.

C'est pourtant simple, non ?
Avatar
Bruno Desthuilliers
Olivier Miakinen a écrit :
Le 12/12/2008 20:51, METIS m'a répondu :
[...]
Et METIS, dans tout ça ? Eh bien son premier é est codé en Latin1, le
second en UTF-8, ce qui donne :


Mouai...
Alors quand je mets la balise META comme ça :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Et le fichier en PHP comme ça :
<?php
header('Content-Type: text/html; charset=UTF-8');

Ca suffit donc pas...



Grrmmlblmlbmll... :-(((((

et je ne sais toujours pas pourquoi...



J'abandonne. Si quelqu'un d'autre a le courage, je lui cède volontiers
ma place.



J'ai fait une dernière tentative, mais je n'irai pas plus loin...
Avatar
Olivier Miakinen
Le 12/12/2008 20:51, METIS m'a répondu :

[...]
Et METIS, dans tout ça ? Eh bien son premier é est codé en Latin1, le
second en UTF-8, ce qui donne :



Mouai...
Alors quand je mets la balise META comme ça :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Et le fichier en PHP comme ça :
<?php
header('Content-Type: text/html; charset=UTF-8');

Ca suffit donc pas...



Grrmmlblmlbmll... :-(((((

et je ne sais toujours pas pourquoi...



J'abandonne. Si quelqu'un d'autre a le courage, je lui cède volontiers
ma place.
Avatar
Olivier Miakinen
Le 12/12/2008 21:41, Bruno Desthuilliers répondait à METIS :

parce que (pour la troisième fois au moins) il faut que l'encodage que
tu *déclares* correspondent à l'encodage *effectivement utilisé* pour
enregistrer ton fichier. Il ne suffit pas de dire qu'un morceau de
camembert est de l'emmenthal pour qu'il devienne de l'emmenthal par magie.

C'est pourtant simple, non ?



Bonne idée, les MÀLC ! Du coup, puisque METIS est graphiste, ce qui suit
devrait mieux lui parler.

METIS, quand tu as un fichier au format GIF nommé bidule.gif, il ne
suffit pas de le renommer bidule.jpg pour qu'il devienne magiquement un
fichier au format JPEG. Pour cela, tu dois utiliser un logiciel qui va
lire l'image GIF, puis la sauver en JPEG, en changeant son format.

Eh bien là c'est pareil : il ne suffit pas de déclarer un Content-Type
avec UTF-8 pour que ton fichier Latin1 devienne magiquement un fichier
UTF-8. Il faut utiliser un logiciel qui va effectuer la conversion.

(Et moi qui avais dit que j'abandonnais... je suis décidément un
incurable optimiste...)
Avatar
SAM
Le 12/12/08 8:51 PM, METIS a écrit :
Olivier Miakinen wrote:
[...]
Et METIS, dans tout ça ? Eh bien son premier é est codé en Latin1, le
second en UTF-8, ce qui donne :



Mouai...
Alors quand je mets la balise META comme ça :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Et le fichier en PHP comme ça :
<?php
header('Content-Type: text/html; charset=UTF-8');

Ca suffit donc pas... et je ne sais toujours pas pourquoi...



ben ... il ne suffit pas de "déclarer" le charset ...
il faut aussi "l'utiliser" ...

utiliser :
- le texte (html ou autre) doit être dans le charset spécifié(*)
- le traitement côté serveur doit se faire dans cet encodage.
Ou alors : traducteur à l'entrée et à la sortie.

(*) ce n'est pas parce qu'on voit écrit dans son texteur
"téléphone"
qu'il ne sera pas lu "t?l?phone" dans un autre texteur.

NotePad permet à l'enregistrement du fichier
de spécifier le charset à utiliser

IE.6 a l'air de se dépatouiller en local d'un fichier html
écrit sous NotePad et dont
- le meta est ISO-8859-1
- le charset est UTF-8
en règlant/choisissant l'UTF alors que le meta précise autre chose
(ce qui n'est pas pour faciliter l'apprehension du pb)


--
sm