Le bon charset...

Pierre Goiffon wrote:

Ce que j'en ai retenu, c'est que Unicode semble assez mal accepté en
[...] ou la zone Pacifique, [...]

Mouai...
J'utilise ce même form et son envoi.php dans différents site en France (Pas
le même résultat avec Orange et Yahoo) et un client/pote en Nouv. Calédonie,
où j'ai encore d'autres problèmes.

Donc ma solution, c'est de demander aux "clients" avec quoi ils lisent leur
emails, et d'adapter pour que ça aille chez eux !!
Ca se compliquerait sérieusement si je devais envoyer les emails sur
plusieurs destinataires qui liraient avec différents outils...

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

Olivier Miakinen <om+news@miakinen.net> écrivait :

Le 11/12/2008 18:54, Dominique Ottello a écrit :
>
>> Très drôle ! Essayez de citer cette ligne :
>>
>> 1 € = 100 ¢
> Rien que pour voir si Agent fait ça correctement sans rien changer aux
> réglages.

Oui, mais c'était un mauvais exemple puisque tous les caractères sont
dans Latin 9.

Plus difficile sans UTF-8 ni CP1252 :
J'ai acheté ½ œuf pour ¾ €.

Là, on va bien voir car, dans Agent, j'ai juste fait Répondre sans
toucher à quoi que ce soit d'autre.

Déjà, lors de la demande d'envoi, Agent me dit qu'il ne peut pas envoyer
€ (Euro) et œ (ligature oe) sans changer de jeux de caractères et, en
premier, il me propose ISO-8859-15, ce que je vais accepter.
--
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis

Le 12/12/2008 10:09, Pierre Goiffon a écrit :

Quand aux webmails...

Je n'ai plus les détails en mémoire (c'est quelque part sur le serveur
de fichier, ou dans mes archives, ou ...)
Mais oui beaucoup de webmail n'aiment pas UTF-8. Sergio cite le imp de
Free (autant imp que imp4.free.fr d'ailleurs si j'ai bonne mémoire ?),

Je n'ai pas de compte pour tester ce webmail. L'« Open WebMail Version
2.01 » qui tourne chez GalacSYS n'est pas gêné par la déclaration d'un
charset autre que Latin1, du moment que les caractères font bien partie
de Latin1 : il fait une conversion.

je crois me souvenir que yahoo (pas la version beta) idem.

D'après une réponse de METIS en privé, au contraire Yahoo semble s'en
sortir même quand l'encodage déclaré est incorrect, puisqu'il arrive à
tout afficher correctement malgré le mélange de charsets envoyé par METIS.

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.

Ensuite, de l'expérience que j'ai pu avoir, les choses sont très
différentes par pays. Des clients coréen (du Nord) n'avaient aucun prb
avec l'UTF-8 (alors qu'avec le Coréen ça fait gonfler la taille dans des
proportions déraisonnables), par contre pour des japonais ça n'était pas
acceptable.

Je ne peux pas te contredire sur ce point. Je sais que nos traducteurs
japonais traduisent les pages web dans l'encodage propriétaire Shift-JIS
au lieu de l'un des standards.

Le 12/12/2008 10:41, METIS a écrit :

Pierre Goiffon wrote:

Ce que j'en ai retenu, c'est que Unicode semble assez mal accepté en
[...] ou la zone Pacifique, [...]

Mouai...
J'utilise ce même form et son envoi.php dans différents site en France (Pas
le même résultat avec Orange et Yahoo) et un client/pote en Nouv. Calédonie,
où j'ai encore d'autres problèmes.

Oui, mais ta page est buguée. Que Yahoo arrive à s'en sortir quand même
c'est un exploit (ou un bug, si on considère que l'on puisse vouloir
écrire un à suivi d'un © sans qu'il l'interprète comme un é), mais il ne
faut pas demander l'impossible aux autres.

Donc ma solution, c'est de demander aux "clients" avec quoi ils lisent leur
emails, et d'adapter pour que ça aille chez eux !!

Non. La solution, c'est d'abord de faire une page non buguée. Note que
je t'avais déjà proposé trois solutions dans un précédent article
(<news:493e8a59$1@neottia.net>), les deux premières en UTF-8 et la
troisième en Latin1, mais que tu n'as pas dû les comprendre.

Le 12/12/2008 10:58, Dominique Ottello a écrit :

Plus difficile sans UTF-8 ni CP1252 :
J'ai acheté ½ ?uf pour ¾ ?.

Là, on va bien voir car, dans Agent, j'ai juste fait Répondre sans
toucher à quoi que ce soit d'autre.

Raté. ©

C'est du CP1252 déclaré ISO-8859-1. D'après Denis Liégeois, même Outlook
Express n'a pas ce bug (alors que Forte Agent et Thunderbird, oui -- et
d'ailleurs j'ai dû moi-même remplacer les caractères non-Latin1 par des
points d'interrogation).

Déjà, lors de la demande d'envoi, Agent me dit qu'il ne peut pas envoyer
? (Euro) et ? (ligature oe) sans changer de jeux de caractères et, en
premier, il me propose ISO-8859-15, ce que je vais accepter.

Il n'aurait pas dû te proposer ISO-8859-15 (qui ne contient pas les
caractères 1/2 et 3/4), mais UTF-8 (qui les contient tous). Ou alors
CP1252, même si c'est propriétaire, du moment que c'est ça qu'il envoie.

À (at) Fri, 12 Dec 2008 11:54:07 +0100,
Olivier Miakinen <om+news@miakinen.net> écrivait (wrote):

Le 12/12/2008 10:09, Pierre Goiffon a écrit :

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.

Les limitations ne sont donc pas (plus) sur le MTA. Si elles existent,
c'est à cause des MUA (que ce soit des agents sur la machine de
l'utilisateur ou de webmails).

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>

Pierre Goiffon a formulé ce vendredi :

Je n'ai pas compris pourquoi tu dis ça. OE et Thunderbird, ils n'ont à
ma connaissance aucun problème quel que soit le charset (Latin1, Latin9,
CP1252, UTF-8, Big5, et d'autres). Quand aux webmails...

Je n'ai plus les détails en mémoire (c'est quelque part sur le serveur de
fichier, ou dans mes archives, ou ...)
Mais oui beaucoup de webmail n'aiment pas UTF-8. Sergio cite le imp de Free
(autant imp que imp4.free.fr d'ailleurs si j'ai bonne mémoire ?), je crois me
souvenir que yahoo (pas la version beta) idem.

Si j'ai bonne mémoire, l'imp de Free, certes est en 8859-1, mais
interprète correctement l'UTF-8, pourvu qu'il n'y ait que des
caractères "occidentaux".

Ensuite, de l'expérience que j'ai pu avoir, les choses sont très différentes
par pays. Des clients coréen (du Nord) n'avaient aucun prb avec l'UTF-8
(alors qu'avec le Coréen ça fait gonfler la taille dans des proportions
déraisonnables), par contre pour des japonais ça n'était pas acceptable.

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 ?

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Olivier Miakinen wrote:

D'après une réponse de METIS en privé, au contraire Yahoo semble s'en
sortir même quand l'encodage déclaré est incorrect, puisqu'il arrive à
tout afficher correctement malgré le mélange de charsets envoyé par
METIS.

En fait, j'ai deux déclarations à faire, la balise META du fichier
contact.php et le "header" du fichier envoi.php.
(si je néglige l'entête HTTP qui est battue par ces 2 déclarations et qui
est resté par défaut, je ne sais pas sur quoi.)

J'ai même fait une recherche dans mes fichiers pour voir où traineraient
UTF-8 et ISO-8859-1.
Ya pas de problème, j'ai bien tout l'un ou tout l'autre...

Ah si, vous n'allez pas me dire que ça peut foutre le bokson :
J'ai fait mes essais comme ça :

header('Content-Type: text/html; charset=ISO-8859-1');
//header('Content-Type: text/html; charset=ISO-Latin-1');
//header('Content-Type: text/html; charset=UTF-8');

En changeant les //.
Alors ??

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

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
Format d'envoi des News > Texte brut > Parametres > Format du message MIME
Coder le texte: Aucun

En fait, comme je m'en rends compte de plus en plus au fil de ces
messages, le problème de METIS est qu'il ne voit que la déclaration
d'encodage et qu'il ne comprend rien à l'encodage réel.

Alors voici quelques petits mots d'explication, même si l'essentiel est
déjà dans <http://french.joelonsoftware.com/Articles/Unicode.html>, cité
précédemment comme une lecture indispensable avant de faire quoi que ce
soit d'autres.

Je vais prendre comme exemple la chaîne « Prénom : test é », et ne
parler que de trois encodages : ASCII, Latin1 et UTF-8.

----------------------------------------------------------------------

Dans la chaîne « Prénom : test é », presque tous les caractères
existaient déjà en ASCII, qui est l'ancètre commun de Latin1 et UTF-8.
Tous les caractères présents dans ASCII se codent avec un entier compris
entre 0 et 127 et tiennent dans un seul octet. Le numéro correspondant
au P majuscule est 80, le numéro correspondant au r minuscule est 114,
le numéro correspondant à l'espace est 32, etc. Parce que c'est plus
simple, on a l'habitude d'écrire ces nombres en hexadécimal sur deux
chiffres (entre 00 et 7f), avec 80 décimal = 50 hexa pour le P, 114
décimal = 72 hexa pour le r, etc.

Jetons un voile pudique sur les « é » pour le moment, et regardons ce
que cela donne pour les autres :

P r é n o m : t e s t é
50 72 ## 6e 6f 6d 20 3a 20 74 65 73 74 20 ## ; ASCII, Latin1, UTF-8

Tous les caractères ASCII ont le bon goût de se coder exactement de la
même manière dans Latin1 que dans ASCII, et de la même manière dans
UTF-8 que dans ASCII. So far, so good (oui, je parle auvergnat aussi).

----------------------------------------------------------------------

Qu'en est-il du é ?

En Latin1, il se code aussi sur un seul octet, avec la valeur e9. Donc :

P r é n o m : t e s t é
50 72 e9 6e 6f 6d 20 3a 20 74 65 73 74 20 e9 ; Latin1

Mais en UTF-8, il se code sur deux octets, c3 et a9. Donc :

P r é n o m : t e s t é
50 72 c3a9 6e 6f 6d 20 3a 20 74 65 73 74 20 c3a9 ; UTF-8

----------------------------------------------------------------------

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

P r [?] n o m : t e s t [?]
50 72 e9 6e 6f 6d 20 3a 20 74 65 73 74 20 c3a9 ; Affreux mélange

Quand on *déclare* Latin1 dans le Content-Type, celui qui reçoit le
texte n'a pas de problème pour décoder le premier é (e9 = é en Latin1)
mais le second devient un à (de code c3) suivi d'un © (de code a9).

Inversement, quand on *déclare* UTF-8 dans le Content-Type, celui qui
reçoit le texte n'a pas de problème pour décoder le second é (c3a9 = é
en UTF-8) alors que le premier (e9) est un encodage invalide en UTF-8.
À l'arrivée cela peut donner un point d'interrogation (Thunderbird,
Firefox), ou un carré vide (Outlook Express, Internet Explorer), mais il
semble que Yahoo dans ce cas se rabatte sur Latin1 pour montrer quand
même un é.

----------------------------------------------------------------------

En conclusion : relire dans <news:493e8a59$1@neottia.net> trois
solutions possibles pour éviter le mélange des encodages.