Le bon charset...
METIS
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...
Olivier Miakinen
>
> 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) ?
Oui. Ne surtout pas oublier de le doubler par des entêtes HTTP
correspondants (httpd.conf ou .htaccess pour Apache, entête header
dans PHP, etc.)
> Vous allez me dire que ça dépend...?
Non. Ceux qui auraient besoin d'avoir un autre encodage (Latin1,
Shift-JIS, ou quoi que ce soit d'autre) devront savoir jongler avec
deux charsets. Pour ceux qui ne sont pas des as en problèmes de
transcodage et en programmation, il vaut mieux avoir un charset
unique, et UTF-8 est celui qui rendra les choses les plus simples
possibles. Il n'y a qu'à voir les problèmes que tu avais toi-même
avec un formulaire en UTF-8 et une page de traitement en Latin1 !
METIS
> Le 11/12/2008 10:17, METIS a écrit :
>> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
>> Est-ce que c'est pertinent (en général) ?
>
> Oui. Ne surtout pas oublier de le doubler par des entêtes HTTP
> correspondants (httpd.conf ou .htaccess pour Apache, entête header
> dans PHP, etc.)
OK.
Est-ce que tu aurai un lien vers une page d'explications claire sur le
comment faire pour cette histoire d'entête.
Si tu n'as pas, je vais fouiller le net avec Gogol
>> Vous allez me dire que ça dépend...?
>
> ... Il n'y a qu'à voir les problèmes que tu avais toi-même
> avec un formulaire en UTF-8 et une page de traitement en Latin1 !
Oui, d'autant que j'ai dû modifier le charset d'une autre page à cause du
renvoi vers la page merci.php... (ça foutait le bazar dans le reste de la
page avec UTF-8)
Je pense que tu vois ce que je veux dire.
Olivier Miakinen
>
> Est-ce que tu aurai un lien vers une page d'explications claire sur le
> comment faire pour cette histoire d'entête.
Ouiii !
Je n'en avais pas, mais une recherche rapide m'a donnée une excellente
page que je me suis empressé de ranger dans mes signets :
http://www.w3.org/International/O-HTTP-charset
(et en plus, si ton navigateur est bien configuré, tu la verras en
français).
>> ... Il n'y a qu'à voir les problèmes que tu avais toi-même
>> avec un formulaire en UTF-8 et une page de traitement en Latin1 !
>
> Oui, d'autant que j'ai dû modifier le charset d'une autre page à cause du
> renvoi vers la page merci.php... (ça foutait le bazar dans le reste de la
> page avec UTF-8)
> Je pense que tu vois ce que je veux dire.
Je vois parfaitement. Et j'espère pour toi que tu as choisi UTF-8
partout, parce que sinon tu auras des problèmes curieux le jour où
quelqu'un voudra écrire un € ou un œ dans le formulaire.
METIS
> Le 11/12/2008 11:09, METIS a écrit :
>>
>> Est-ce que tu aurai un lien vers une page d'explications claire sur
>> le comment faire pour cette histoire d'entête.
>
> Ouiii !
Super, t'es un chef
>> Je pense que tu vois ce que je veux dire.
>
> Je vois parfaitement. Et j'espère pour toi que tu as choisi UTF-8
> partout, parce que sinon tu auras des problèmes curieux le jour où
> quelqu'un voudra écrire un ¤ ou un ½ dans le formulaire.
Bé non, j'ai mis la page du formulaire, le fichier php qui envoie et la page
merci.php sur...
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
...sinon, je n'arrive pas à avoir tous les champs correctement.
Dans la page merci.php, ça me mettait é dans les menus, mais pas dans le
corps de page (avec le é)!!
Là franchement je me demande pourquoi.
Le form, c'était soit...
Téléphone : téléphone
soit...
Tlphone : téléphone
ou...
T?l?phone...
Avec champ De : qui dit é quand je mets é
Etc., je ne sais plus dans quel ordre, j'ai fait le ménage.
Prise de tête de pôv'graphiste...
(je fais ça pour un pote qui n'a pas les moyens de se payer un dév.)
METIS
> Je vois parfaitement. Et j'espère pour toi que tu as choisi UTF-8
> partout, parce que sinon tu auras des problèmes curieux le jour où
Non, pas partout.
Sinon, problèmes avec le form contact.php.
J'ai fait un coup de...
http://web-sniffer.net/
...sur la page contact.php
Ca dit..:
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7[CRLF]
Je n'ai pas UTF-8 dans le code de cette page puisque je l'ai mise
en ISO-8859-1
Moi pas comprendre.
D'autre part, c'est quoi q=0.7,*;q=0.7 ?
Un rapport avec les langues utilisées peut-être..?
Bon, ceci dit, l'entête HTTP est prtout en UTF-8 par défaut.
J'ai par défaut...
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Et le fichier d'envoi PHP est déclaré...
header('Content-Type: text/html; charset=UTF-8');
Bon là, ça déconne un max comme expliqué précédemment.
Pierre Goiffon
>> 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) ?
>
> Oui. Ne surtout pas oublier de le doubler par des entêtes HTTP
> correspondants (httpd.conf ou .htaccess pour Apache, entête header
> dans PHP, etc.)
Très juste !
Il faut aussi s'assurer que Dreamweaver enregistre vraiment les fichiers
en UTF-8 ! (déjà vu un paquet d'éditeurs qui indiquent un meta avec un
codage qui n'est pas celui utilisé pour enregistrer le fichier édité...)
>> Vous allez me dire que ça dépend...?
>
> Non. Ceux qui auraient besoin d'avoir un autre encodage (Latin1,
> Shift-JIS, ou quoi que ce soit d'autre) devront savoir jongler avec
> deux charsets.
Olivier, ta réponse me parait un peu lapidaire. J'aurais dis, moi, "ça
dépend". Mais Metis, si vous n'utilisez que des langues latines, et
considérant que visiblement vous n'avez pas trop envie de vous plonger
dans le sujet, vous pouvez considérer que dans votre cadre d'utilisation
UTF-8 conviendra bien pour vos pages Web.
Mais notez bien que ce n'est pas toujours le cas...
METIS
>> Oui. Ne surtout pas oublier de le doubler par des entêtes HTTP
>> correspondants (httpd.conf ou .htaccess pour Apache, entête header
>> dans PHP, etc.)
>
> Très juste !
> Il faut aussi s'assurer que Dreamweaver enregistre vraiment les
> fichiers en UTF-8 ! (déjà vu un paquet d'éditeurs qui indiquent un
> meta avec un codage qui n'est pas celui utilisé pour enregistrer le
> fichier édité...)
En ce qui me concerne, quand je regarde le source de chaque page, le charset
est bien celui que j'ai mis.
>>> Vous allez me dire que ça dépend...?
>>
>> Non. Ceux qui auraient besoin d'avoir un autre encodage (Latin1,
>> Shift-JIS, ou quoi que ce soit d'autre) devront savoir jongler avec
>> deux charsets.
>
> Mais notez bien que ce n'est pas toujours le cas...
Voilà, oui, impossible de faire coincider tout.
J'ai toujours un truc qui déconne quelque part.
Faut dire qu'entre le client messagerie OE, les différents navigateurs et
les interfaces Orange ou Yahoo... Ya de quoi s'amuser.
Par exemple, je n'ai pas le même résultat pour un message lu chez Yahoo et
chez Orange (et dans OE).
Pour ce qui est du symbole euro Olivier, je reçois pas mal de pubs et je
vois plus souvent "?" que euro (le symbole).
Pierre Goiffon
>>> Oui. Ne surtout pas oublier de le doubler par des entêtes HTTP
>>> correspondants
>> Il faut aussi s'assurer que Dreamweaver enregistre vraiment les
>> fichiers en UTF-8 !
>
> En ce qui me concerne, quand je regarde le source de chaque page, le charset
> est bien celui que j'ai mis.
Ce n'est pas ce que Olivier et moi voulions dire !
Il faut choisir un codage puis :
- faire en sorte que son éditeur enregistre bien les fichiers en
utilisant ce codage
- spécifier le codage dans les entêtes http (config serveur)
- éventuellement ajouter le codage en balise meta
> Faut dire qu'entre le client messagerie OE, les différents navigateurs et
> les interfaces Orange ou Yahoo... Ya de quoi s'amuser.
> Par exemple, je n'ai pas le même résultat pour un message lu chez Yahoo et
> chez Orange (et dans OE).
Commencez par ne pas tout mélanger dans vos messages !
Vous parliez de pages Web, nous vous avons répondu sur ce sujet. J'ai
bien précisé dans ma réponse "conviendra bien pour vos pages Web". Je ne
recommande pas du tout UTF-8 pour du mail.
METIS
> Commencez par ne pas tout mélanger dans vos messages !
> Vous parliez de pages Web, nous vous avons répondu sur ce sujet. J'ai
> bien précisé dans ma réponse "conviendra bien pour vos pages Web". Je
> ne recommande pas du tout UTF-8 pour du mail.
Ah bé voilà, les problèmes viennent plutôt de là donc.
J'ai un formulaire (contact.php), je le fais partir en email (avec
envoi.php).
Mais il va être lu soit avec OE, soit ThunderB, soit sur Internet messagerie
Orange ou Yahoo, voire encore autre chose.
Je n'arrive pas à être nickel partout.
Avec UTF-8 ça déconne bien.
Avec ISO-8859-1 ça va assez bien, sauf sur Orange (le site) et sauf pour le
symbole euro (au minimum).
Andreas Prilop
> X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
> Subject: Le bon charset...
>
> Vous allez me dire que ?a d?pend...?
Très drôle ! Essayez de citer cette ligne :
1 € = 100 ¢
Dominique Ottello
> 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.
--
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
Olivier Miakinen
>
>> 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 ¾ €.
METIS
> Le 11/12/2008 18:54, Dominique Ottello a écrit :
>>
>>> Très drôle ! Essayez de citer cette ligne :
>>>
>> 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 :
Z'êtes sympa de rire sur mon dos...(;o)))))))))))
Mais à part ces propos de spécialistes, que dois-je conclure??
Olivier Miakinen
>>
>> Plus difficile sans UTF-8 ni CP1252 :
>> J'ai acheté ½ ouf pour ¾ ?.
>
> Z'êtes sympa de rire sur mon dos...(;o)))))))))))
> Mais à part ces propos de spécialistes, que dois-je conclure??
... du fait que tu aies acheté un demi ouf pour trois quarts de points
d'interrogation ? Tu peux en conclure qu'il y a des cas où il n'y a pas
de solution sans UTF-8.
METIS
Voui...
Donc on ne peut pas afficher correctement les saisies d'un form dans OE,
ThunderB, et les messageries sur le Net, en même temps...
Olivier Miakinen
>
> Donc on ne peut pas afficher correctement les saisies d'un form dans OE,
> ThunderB, et les messageries sur le Net, en même temps...
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... donne-moi donc
les adresses de quelques-unes, et je me charge d'y envoyer un message
dans chacun des charsets que tu voudrais tester. Tu peux m'écrire en
privé si tu ne veux pas les donner en public, mon adresse est valide.
P.-S. : tu as vraiment une adresse chez mandarine.fr ? Si oui c'est très
joli, mais sinon il est recommandé de la terminer par .invalid :
m...@mandarine.fr.invalid (sans e, c'est un nom de domaine spécialement
réservé à cet usage).
--
Olivier Miakinen
Sergio
>> Donc on ne peut pas afficher correctement les saisies d'un form dans OE,
>> ThunderB, et les messageries sur le Net, en même temps...
> 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... donne-moi donc
> les adresses de quelques-unes, et je me charge d'y envoyer un message
> dans chacun des charsets que tu voudrais tester. Tu peux m'écrire en
> privé si tu ne veux pas les donner en public, mon adresse est valide.
imp.free.fr au hasard...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Pierre Goiffon
>> Donc on ne peut pas afficher correctement les saisies d'un form dans OE,
>> ThunderB, et les messageries sur le Net, en même temps...
>
> 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.
Mais de toute façon il n'y a pas que le client mail utilisé au final qui
importent : toutes les passerelles comptent...
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.
Pierre Goiffon
> Tu peux en conclure qu'il y a des cas où il n'y a pas
> de solution sans UTF-8.
Oh que non !
Je ne suis pas un expert et je ne parle que de quelques expériences que
j'ai eu avec un client grand groupe international, et des différentes
lectures dans lesquelles je me suis plongé pour comprendre.
Ce que j'en ai retenu, c'est que Unicode semble assez mal accepté en
Asie du SE. Pour le reste, pas eu cette impression pour l'Amérique du
Nord et Sud ou la zone Pacifique, et pas été confronté à échelle
pertinente avec l'Afrique ou les pays Baltes.
Je ne connais pas les raisons profondes, mais visiblement il y a eu un
manque de représentation des pays concernés dans le consortium (?)... Et
aussi les implémentations seraient arrivées un peu tard.
Des solutions comme ISO 2022 (http://en.wikipedia.org/wiki/ISO_2022)
sont très utilisées. Et je ne parle pas d'il y a 10 ans mais de projets
remontant à 1 ou 2 ans, en particulier au Japon.
C'est à creuser et je manque de temps pour avancer, mais le sentiment
que les solutions Unicode ne sont pas une réponse universelle m'est
apparu de manière assez persistante.
METIS
> Mais oui beaucoup de webmail n'aiment pas UTF-8.
Ah ok, j'ai donc raison de me poser la question car je n'arrive pas à
afficher le résultat de ce form, ne serait-ce que sur Orange et Yahoo. Sur
Yahoo, ça va, sur Orange non.
Je ne peux pas tout tester car je ne suis que chez le FAI Orange.
METIS
> Ce que j'en ai retenu, c'est que Unicode semble assez mal accepté en
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...
Dominique Ottello
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.
Olivier Miakinen
>>
>> 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.
Olivier Miakinen
> 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.
Olivier Miakinen
>>
>> Plus difficile sans UTF-8 ni CP1252 :
>
> 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.
Paul Gaborit
À (at) Fri, 12 Dec 2008 11:54:07 +0100,
Olivier Miakinen <om+...@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/>
Sergio
>> 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 ?
METIS
> 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 ??
Andreas Prilop
> 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
Olivier Miakinen
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.
METIS
> 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
> 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..?
Pierre Goiffon
>>> Mais de toute fa�on il n'y a pas que le client mail utilis� au final qui
>> 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
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
Pierre Goiffon
> 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)
Paul Gaborit
À (at) Fri, 12 Dec 2008 17:56:34 +0100,
Pierre Goiffon <pgoi...@free.fr.invalid> é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
>
> 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
> 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.
METIS
[...]
> 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 ?)
Olivier Miakinen
>
> [...]
>> 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.
Bruno Desthuilliers
> 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 ?
Bruno Desthuilliers
J'ai fait une dernière tentative, mais je n'irai pas plus loin...
Olivier Miakinen
>
> 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...)
SAM
> 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
SAM
Faut lui demander l'accès VNC à son poste et lui montrer de visu avec
ses outils en lui expliquant bien oralement en même temps.
Puis lui faire faire des exos au tableau.
Vous avez tout le week-end pour y arriver ;-)
M'enfin ... aussi ... y sont bêtes ces trucs d'ordinateurs à ne pas voir
que c'est du camenbert bien qu'on l'ait mis dans un emballage de gruyère.
Alors que l'idiot d'IE ne se laisse pas prendre au subterfuge.
(enfin ... si on n'a pas mis le tampon de la mauvaise laiterie en plus)
Ha! au fait, Olivier, tu n'es pas à l'heure.
(ou alors c'est Bruno, mais je penche pour ton côté)
--
sm
Olivier Miakinen
>
> Ha! au fait, Olivier, tu n'es pas à l'heure.
> (ou alors c'est Bruno, mais je penche pour ton côté)
Non, c'est Bruno. D'ailleurs mon ordinateur est synchronisé
sur un serveur de temps.
Moi :
Date: Fri, 12 Dec 2008 22:20:40 +0100
X-Trace: neottia.net ... (12 Dec 2008 22:20:40 +0100)
Bruno :
Date: Fri, 12 Dec 2008 21:43:13 +0100
NNTP-Posting-Date: 12 Dec 2008 22:41:44 MET
Bernd
> ben ... il ne suffit pas de "déclarer" le charset ...
> il faut aussi "l'utiliser" ...
Juste une petite question qui me turlupine :
Si tous les réglages sont bien fait en utf-8, que se passe t-il si des
utilisateurs lamda ont réglé leur butineur sur iso latin 1 (ils se sont
aperçu un jour que comme cela ils pouvait lire - par hasard - certaines
pages) plutôt que "par défaut" comme c'est le cas je crois à
l'installation du browser.
Ils vont sûrement se retrouver avec des caractères illisibles. Existe
t-il alors un moyen de forcer le browser à passer d'autorité sur "par
défaut" ?
--
A+
Romer
SAM
> Le 12/12/2008 23:43, SAM a écrit :
>> Ha! au fait, Olivier, tu n'es pas à l'heure.
>> (ou alors c'est Bruno, mais je penche pour ton côté)
>
> Non, c'est Bruno. D'ailleurs mon ordinateur est synchronisé
> sur un serveur de temps.
comme le mien aussi et que je ne te suis pas à la trace et qu'il m'avait
semblé par ailleurs ...
> Moi :
> Date: Fri, 12 Dec 2008 22:20:40 +0100
> X-Trace: neottia.net ... (12 Dec 2008 22:20:40 +0100)
Boudiou ! Neottia ça trace !
moi :
Date: Fri, 12 Dec 2008 23:43:06 +0100
NNTP-Posting-Date: 12 Dec 2008 23:43:07 CET
ça a pris 1 seconde
> Bruno :
> Date: Fri, 12 Dec 2008 21:43:13 +0100
> NNTP-Posting-Date: 12 Dec 2008 22:41:44 MET
et ?
ça a pris près de 2 mn à passer
(avec Bruno, c'est à peu près normal, non ?)
Ha! Oh! c'est le contraire !
Il a prévu le coup et mis de l'avance pour cacher l'attente.
Manque de chance ce n'est pas parti depuis son site-ou-serveur web qui
n'a pas eu l'heur de mouliner longuement.
(sans doute ?)
--
sm
Olivier Miakinen
>
> Juste une petite question qui me turlupine :
> Si tous les réglages sont bien fait en utf-8, que se passe t-il si des
> utilisateurs lamda ont réglé leur butineur sur iso latin 1 (ils se sont
> aperçu un jour que comme cela ils pouvait lire - par hasard - certaines
> pages) plutôt que "par défaut" comme c'est le cas je crois à
> l'installation du browser.
Le réglage du butineur, c'est uniquement pour les pages web qui ne
déclarent rien (juste "text/html" sans aucun charset). Quand la
déclaration est correcte, ce réglage de charset par défaut est tout
simplement ignoré.
> Ils vont sûrement se retrouver avec des caractères illisibles. Existe
> t-il alors un moyen de forcer le browser à passer d'autorité sur "par
> défaut" ?
Dans Firefox et assimilés, comme choix de charset par défaut on peut
choisir « détection automatique / universel » qui marche très bien. Mais
encore une fois ça ne sert que pour les pages sans aucune déclaration
d'encodage.
Olivier Miakinen
>
> moi :
> Date: Fri, 12 Dec 2008 23:43:06 +0100
> NNTP-Posting-Date: 12 Dec 2008 23:43:07 CET
>
>> Date: Fri, 12 Dec 2008 21:43:13 +0100
>> NNTP-Posting-Date: 12 Dec 2008 22:41:44 MET
>
> et ?
>
> ça a pris près de 2 mn à passer
Ben non, ça a pris plus d'une heure. D'après ce que je crois comprendre,
MET est l'ancien nom du fuseau horaire +0100, et CET et CEST sont les
noms actuels, CET étant à l'heure d'hiver (donc +0100 comme MET) et CEST
à l'heure d'été (+0200).
> Ha! Oh! c'est le contraire !
> Il a prévu le coup et mis de l'avance pour cacher l'attente.
> Manque de chance ce n'est pas parti depuis son site-ou-serveur web qui
> n'a pas eu l'heur de mouliner longuement.
> (sans doute ?)
Gni ?
SAM
Niakemi que dô cumprendr' cha.
(et encore ? si je ne me trompe)
--
sm
SAM
(typo !)
Miakinen comprin po nin plus.
Ou si eut' prefer' :
Mi y a qui n'en comprend pas nin plus.
Bon ... avant de sortir ...
J'ai dit ça ?
Non c'est pas moi, j'ai rien dit.
--
sm
Pascale
news:4942e722$0$914$ba4a...@news.orange.fr:
> NotePad permet à l'enregistrement du fichier
> de spécifier le charset à utiliser
Glurps... Je viens de m'apercevoir que j'avais laissé le paramètre par
défaut (ANSI)... dans les en-têtes de mes programmes, j'ai charset=iso-
8859-15 et la même chose dans l'en-tête des courriels envoyés par la
fonction mail...
Donc c'est MAL ?...
--
Pascale
SAM
> Donc c'est MAL ?...
J'en sais rien ... je n'ai pas Windows et ne sais ce qu'est l'ANSI
Après avoir relu son message
<4940daa6$0$948$ba4a...@news.orange.fr>
ou
<49427d92$1...@neottia.net>
ou
<http://groups.google.com/group/fr.comp.infosystemes.www.auteurs/msg/a160d33b87e04cb0>
d'Olivier Miakinen
peut-être lui demander ?
Re jouer avec son outil ?
<http://www.miakinen.net/vrac/charsets/>
Où il n'y a pas l'ANSI
pour cause ... : <http://fr.wikipedia.org/wiki/ANSI>
ce n'est qu'une accréditation normalisante US ... (10 000 ANSI !)
(un peu comme si on disait "ISO" ou "NF")
C'est bien du style à M$ de mélanger n'importe quoi ... le respect d'une
norme et des choix d'encodages ... :-(
(en tous cas mon texteur, en encodage, ne me propose pas "ANSI" pourtant
il semble il y en avoir près d'une 100aine)
Bon ... finalement l'ANSI serait du ISO-8859-1
(ou plus vraissemblablement était (W95) mais plutôt du Windows-1252)
<http://www.docmemo.com/informatique/codesansi.php>
c'est le truc qui permet de taper sur son clavier Windows tous les
caractères un peu spess (enfin ... ceux connus par ce charset).
Tu ne devrais pas avoir l'€ (euro) --> Alt + 0244
si on en croit docmemo.
--
sm
SAM
>
> Tu ne devrais pas avoir l'€ (euro) --> Alt + 0244
heu ... Alt + 0200
--
sm
METIS
[...]
> J'en sais rien ... je n'ai pas Windows ...
J'ai l'impression que tout ceux qui essayent de me faire comprendre quelque
chose ici, sont sur Mac...?
Ca ne facilite pas les choses !
Moi j'ai été Mac longtemps (jusqu'au G3 en desktop et G4 titanium en
portable).
Mais j'ai opté pour les PC en production surtout Internet pour être le plus
proche possible de la plus grande masse d'utilisateurs.
METIS
> 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.
Voui... Alors là tu vois, je ne comprends pas ce que tu dis.
Tu vois l'ampleur du problème ?
Est-ce que ça veux dire que ça viendrait de mon (mes navigateur/système...)
Les test étant merdiques avec OE, ThunderB, webmail Orange dans Firefox et
webmail Yahoo dans IE7... tous en réglage par défaut le jour de
l'installation, ce qui est le cas de 95% des utilisateurs lambda.
Noubliez pas que vous, les spécialistes, vous avez souvent une approche des
problèmes très spéciale, du fait de vos connaissance et de votre façon de
torturer les logiciels.
Vous m'expliquez tous des trucs mais je suis comme quand on parle des
éléments d'un moteur à une femme qui n'a jamais soulevé un capot de
voiture...
(;o)))))))))))))
METIS
Et question subsidiaire :
Peut-on obtenir ce que je cherche à avoir avec des butineurs ou clients mail
en réglage "sortie du carton" (95% des utilisateurs non spécialisés)
METIS
> 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
> (Et moi qui avais dit que j'abandonnais... je suis décidément un
> incurable optimiste...)
OK Bruno.
OK Olivier.
Comment je fais donc...?
Je ne vois pas où et à quel niveau j'ai le problème.
C'est quand j'envoie ?
Quand j'écris...
Je prépare les 2 fichiers, j'envoie en FTP et basta...
C'est ce que vous ne comprenez pas que je ne comprends pas que vous
comprenez pas que je sais pas vomment comprendre...(;o))))))
SAM
> Le 12/13/08 11:22 AM, SAM a écrit :
>>
>> Tu ne devrais pas avoir l'€ (euro) --> Alt + 0244
>
> heu ... Alt + 0200
comme quoi docmemo racconte n'importe quoi,
l'ANSI est bien du Windows-Latin1 ou CP1252
et probablement ça va poser problème avec l'euro qui n'a pas le même
code en ANSI ou en ISO-8859-15 (sauf si le e-maileur à l'envoi traduit
en fonction, ce qui doit être le cas)
L'euro en Windows :
<http://www.miakinen.net/vrac/charsets/?hv=h&o6=MacRoman&or=4&pr=128>
L'euro en ISO-Latin-étendu :
<http://www.miakinen.net/vrac/charsets/?hv=h&o6=MacRoman&or=3&pr=164>
où il manque l'octal pour aide frappe clavier Windows.
--
sm
Christian
> Je ne vois pas où et à quel niveau j'ai le problème.
> C'est quand j'envoie ?
> Quand j'écris...
c'est quand tu écris.
si tu écris en utf-8 tu déclares de l'utf-8
si tu écris en latin 9 tu déclares du latin 9
--
Christian
SAM
> SAM wrote:
>>
>> 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.
>
> Voui... Alors là tu vois, je ne comprends pas ce que tu dis.
> Tu vois l'ampleur du problème ?
Bon, de mon côté, je ne sais pas trop ce que tu veux faire.
M'enfin, le principe :
(ça va pas être facile sous Windows où tout fonctionne en "ANSI"
c'est à dire en Window-Latin1 ou CP1252)
(ça va pa être facile, dans la mesure où les texteurs reconnaissent
d'eux-même le charset et t'affichent tout bien comme il faut)
Hors donc :
- Les anglais écrivent sans accents, (l'ASCII devrait leur suffire)
- les européens (ouest) écrivent avec des accents, (ISO-8859)
(et pas mal d'autres trucs bien compliqués)
- les européens de l'Est ont leur propre alphabet, (Cyrilic)
les grecques aussi, les arabes, les ...
à cela se rajoutent les particularismes des plate-formes :
- Windows (Window_Latin1)
- Mac (Mac Roman)
Il faut bien trouver un système pour "traduire" tous ces
particularismes, ce sont les charsets ou tables de caratères
(le caractère ou glyphe <--> son code *dans CE charset là*)
Voir et jouer avec qques-une de ces tables les + utilisés en hémisphère
Ouest principalement
<http://www.miakinen.net/vrac/charsets/>
Une dernière table regroupe tous les caractères de la planète, c'est
l'UTF-8.
Sur le lien donné ci-haut on n'a que la partie commune avec celles
utilisée habituellement en France.
à partir de maintenant tu dois commencer à comprendre qu'il faut pour un
bon suivi de tes données texte qu'elles soient toutes codées dans le
même charset.
Qu'il faut distinguer :
- déclaration de la table (header, meta)
qui n'est qu'un indicatif pour aider le serveur et le navigateur
- format du texte (encodage)
qui est le fichier rempli d'octets et de chiffres (hexadécimaux)
que le texteur, le navigateur, l'e-maileur, traduiront en caractères
"normaux" en se guidant sur la table choisie.
- format préféré utilisé sur le serveur
(si base de donnée étoussa, sinon on s'en moque un peu)
Les 3 doivent se servir de la même table, du même encodage.
Côté pratique :
Tu utilses quoi pour fabriquer tes fichiers HTML ?
Quoi qu'on utilise, quand on tape au clavier, enregistre, ré-ouvre, on
ne voit que des caractère "normaux".
Cependant, soit à l'enregistrement, soit par un réglage au menu, on doit
pouvoir choisir en quel encodage (quelle table) on veut le fichier final.
C'est là qu'il faut que tu fasses hyper attention :
- choisir UTF-8 et déclarer ensuite en PHP et en HTML UTF-8
- choisir "ANSI" et déclarer CP1252
par exemple.
Avoir l'emballage qui corresponde au produit !
--
sm
SAM
>
> Et question subsidiaire :
> Peut-on obtenir ce que je cherche à avoir avec des butineurs ou clients
> mail en réglage "sortie du carton" (95% des utilisateurs non spécialisés)
si tu as headéré en un encodage X,
le butineur-maileur travaille alors dans cet encodage X
c'est complètement transparent pour l'utilisateur.
Bon ... maintenant s'ils ont tout bricolé sans rien y comprendre ... ce
n'est plus de ton ressort.
On ne peut vraiment rien y faire.
--
sm
SAM
> SAM wrote:
> [...]
>> J'en sais rien ... je n'ai pas Windows ...
>
> J'ai l'impression que tout ceux qui essayent de me faire comprendre
> quelque chose ici, sont sur Mac...?
> Ca ne facilite pas les choses !
> Moi j'ai été Mac longtemps (jusqu'au G3 en desktop et G4 titanium en
> portable).
>
> Mais j'ai opté pour les PC en production surtout Internet pour être le
> plus proche possible de la plus grande masse d'utilisateurs.
Alors essaie-tente de ne pas te casser le tronc et re-écrit tout en brut
de fonderie (en mode par défaut) et passes tes déclarations à
Windos_Latin1 ou CP1252
Les non-windowsiens devraient s'en dépatouiller
L'essentiel EST de DECLARER ce qu'il convient.
--
sm
METIS
(;o))))))))))))
Z'êtes tous pareils !
Moi j'écris rien.
Je fais un formulaire qui sera envoiyé sous forme d'email.
...et je mets ça en ligne dans un site.
Des gens viennent et s'incrivent.
Le destinataire (mon pote/client) lit avec ce qu'il veut. en l'occurrence,
il lit avec le Webmail Yahoo sur PC. Moi je le reçois aussi en copie et je
lis la copie avec OE ou ThunderB (je suis sur PC sous XPfam).
Les gens qui remplissent le formulaire... je ne sais pas si ça a quelque
chose à voir dans tout ça ? Je pense que non.
Chui pas débutant, je suis non spécialiste. Mon domaine c'est le graphisme.
Il me faut des explications complètes...(;o))))))))
Excusez-moi tous, je crois que j'énerve un peu ici, mais comment faire
autrement ?
Bernd
> Mais j'ai opté pour les PC en production surtout Internet pour être le plus
> proche possible de la plus grande masse d'utilisateurs.
Un Mac Intel t'aurait rendu le même service...
--
A+
Romer
Pascale
news:49439a77$0$880$ba4a...@news.orange.fr:
> comme quoi docmemo racconte n'importe quoi,
> l'ANSI est bien du Windows-Latin1 ou CP1252
> et probablement ça va poser problème avec l'euro qui n'a pas le même
> code en ANSI ou en ISO-8859-15 (sauf si le e-maileur à l'envoi traduit
> en fonction, ce qui doit être le cas)
C'est vrai que l'euro semble parfois poser un problème... Souvent, je
préfère écrir eur ou euro(s) (méthode feignasse).
--
Pascale
Pascale
news:49438cdb$0$908$ba4a...@news.orange.fr:
> <http://forum.alsacreations.com/faq/faq-98-S039y-retrouver-entre-ASCII-
> ANSI-Latin1-ISO-8859-1-MacRoman-Windows-1252-etc.html>
Merci pour ce lien. Mais ce que je ne comprends pas, ce sont les différents
niveaux de déclaration. Ce que je n'arrive pas à comprendre, c'est qui fait
quoi : mes programmes sont censés être enregistrés en ANSI, mais je mets
ISO-8859-15 dans mes en-têtes, ainsi que dans l'en-tête des mails envoyés
par la fonction mail de PHP.
Faut-il que je réenregistre tous mes programmes en UTF8 ?!
> C'est bien du style à M$ de mélanger n'importe quoi ... le respect
> d'une norme et des choix d'encodages ... :-(
> (en tous cas mon texteur, en encodage, ne me propose pas "ANSI"
> pourtant il semble il y en avoir près d'une 100aine)
Notepad++ a fait ça à l'insu de mon plein gré... (:
--
Pascale
Pascale
news:49439a77$0$880$ba4a...@news.orange.fr:
> comme quoi docmemo racconte n'importe quoi,
> l'ANSI est bien du Windows-Latin1 ou CP1252
> et probablement ça va poser problème avec l'euro qui n'a pas le même
> code en ANSI ou en ISO-8859-15 (sauf si le e-maileur à l'envoi traduit
> en fonction, ce qui doit être le cas)
C'est vrai que l'euro semble parfois poser un problème... Souvent, je
préfère écrire eur ou euro(s) (méthode feignasse).
--
Pascale
METIS
Oui, je vois.
Alors c'est peut-être moi avec mes outils qui a un problème.
En fait je ne pense pas car je viens de réinstaller un nouveau DD, avec un
nouveau système tout neuf (Win XPfam SP3 à jour). Je travaille avec un
Dreamweaver CS3 tout neuf et je n'ai rien réglé en particulier ni dans
Firefox, ni dans IE6 (que je garde au lieu de mettre IE7 car il y a encore
beaucoup d'utilisateur de IE6).
Pour ce qui concerne les clients mail OE6 et ThunderB, je n'ai pas fait de
réglage particulier, enfin je ne me souviens pas d'avoir bidouillé là
dedans, justement pour être comme l'utilisateur lambda en mode "sortie du
carton".
Mon pote/client lit les emails résultant du formulaire dans son navigateur
IE7 par le webmail Yahoo. Pour lui ça va. Moi, le même email dans Firefox
sur webmail Orange, j'ai des "?" à la place des "é" ou autre chose selon les
chaset choisis...
SAM
> Christian wrote:
>> METIS a écrit :
>>
>>> Je ne vois pas où et à quel niveau j'ai le problème.
>>> C'est quand j'envoie ?
>>> Quand j'écris...
>>
>> c'est quand tu écris.
>>
>> si tu écris en utf-8 tu déclares de l'utf-8
>> si tu écris en latin 9 tu déclares du latin 9
>
> (;o))))))))))))
> Z'êtes tous pareils !
> Moi j'écris rien.
> Je fais un formulaire
Et ton formulaire tu le fais en Legos ou en sucettes ?
Il faut bien que tu l'écrives, non ?
Il faut bien que ton DW ou je ne sais quel truc wzizziwig te place les
éléments et même que tu y tapes du texte, non ?
C'est pas Allah possible ! ça !
Ou bien t'es magicien ou sorcier et le formulaire surgit du néant sur
ton serveur,
ou bien tu le crées et l'écris comme le commun des mortels.
--
sm
SAM
> SAM <stephanemor...@wanadoo.fr.invalid> écrivait
> news:49438cdb$0$908$ba4a...@news.orange.fr:
>
>> <http://forum.alsacreations.com/faq/faq-98-S039y-retrouver-entre-ASCII-
>> ANSI-Latin1-ISO-8859-1-MacRoman-Windows-1252-etc.html>
>
> Merci pour ce lien. Mais ce que je ne comprends pas, ce sont les différents
> niveaux de déclaration. Ce que je n'arrive pas à comprendre, c'est qui fait
> quoi : mes programmes sont censés être enregistrés en ANSI, mais je mets
> ISO-8859-15 dans mes en-têtes, ainsi que dans l'en-tête des mails envoyés
> par la fonction mail de PHP.
> Faut-il que je réenregistre tous mes programmes en UTF8 ?!
Non, l'ISO-8859-15 est couvert par le ANSI à l'exception de l'euro (et
autres broutilles) qui n'est pas rangé au même endroit.
Si l'euro a été écrit en htlm_entité ( € ) il n'y a aucune crainte
à avoir.
>> C'est bien du style à M$ de mélanger n'importe quoi ... le respect
>> d'une norme et des choix d'encodages ... :-(
>> (en tous cas mon texteur, en encodage, ne me propose pas "ANSI"
>> pourtant il semble il y en avoir près d'une 100aine)
>
> Notepad++ a fait ça à l'insu de mon plein gré... (:
Oui, c'est réglé comme ça par défaut (comme tout ce qui tourne sous
Windows j'imagine)
Sur Mac à une époque c'était Mac Roman par défaut.
à chacun sa galère quoi.
--
sm
SAM
Normalement l'email est encodé et on peut choisir son encodage (à
n'importe quel moment avant d'envoyer) menu : Options / Encodage
ou approchant.
et donc tu peux alors taper directement €
si € est bien existant dans cet encodage.
Les principaux encodages (leurs tables de correspondance)
<http://www.miakinen.net/vrac/charsets/>
et en rappel,
L'euro en Windows :
<http://www.miakinen.net/vrac/charsets/?hv=h&or=4&pr=128>
L'euro en ISO-Latin-étendu :
<http://www.miakinen.net/vrac/charsets/?hv=h&or=3&pr=164>
Jongler entre les 2 tables et voir que pas mal de choses sont
identiquement placées (et donc codées pareil).
Seuls les glypes à fond jaune ou bleu sont différents d'une table à
l'autre et peuvent poser problème, tous les autres sont communs.
--
sm
SAM
>
> Mon pote/client lit les emails résultant du formulaire dans son
> navigateur IE7 par le webmail Yahoo. Pour lui ça va. Moi, le même email
> dans Firefox sur webmail Orange, j'ai des "?" à la place des "é" ou
> autre chose selon les chaset choisis...
Ha ! ?
Mais là tu es en train de parler de la messagerie lue sur le site Orange ?
Mais mon pôvre, chez Orange ils n'ont jamais su faire une page web (et
ça date de Wanadoo) tu ne vas quand même pas t'étonner que ça ne
fonctionne pas ?
(ce serait plutot le contraire dont il faudrait s'étonner!).
--
sm
METIS
> Le 12/13/08 12:10 PM, METIS a écrit :
>> Tu vois l'ampleur du problème ?
>
> Bon, de mon côté, je ne sais pas trop ce que tu veux faire.
Je souhaite que dans un certain site, des gens inscrivent des infos dans un
formulaire et envoyer ce form à mon pote/client et à moi-même en copie.
Mais comme ce form et son fichier php d'envoi, je suis susceptible de m'en
servir dans d'autres sites, en France chez d'autre hébergeur qu'OVH ou dans
les îles (Nouv. Calédonie), je souhaite que l'email envoyé puisse être lu
n'importe par n'importe quel moyen avec des accents et symboles qui
marchent. Vala, vala...
> M'enfin, le principe :
> (ça va pas être facile sous Windows où tout fonctionne en "ANSI"
> c'est à dire en Window-Latin1 ou CP1252)
Donc essai à faire avec charset=CP1252
> Voir et jouer avec qques-une de ces tables les + utilisés en
> hémisphère Ouest principalement
> http://www.miakinen.net/vrac/charsets/
Tchappa !!!! Chui pas dan la merde moi....
(;o))))))))))
> à partir de maintenant tu dois commencer à comprendre qu'il faut pour
> un bon suivi de tes données texte qu'elles soient toutes codées dans
> le même charset.
Ca oui...
> Côté pratique :
> Tu utilses quoi pour fabriquer tes fichiers HTML ?
Dreamweaver CS3 installé depuis 3 mois.
J'ai laissé le réglage des prèf. quasiment tel qu'à la livraison car ça
couvre 99% des besoin standard.
Mais la prtie qui me tracasse, c'est ça :
http://img339.imageshack.us/my.php?image=prefdwcs3ec2.jpg
...Comment démarrer un nouveau document.
Et là, j'ai quelques doute.
(et je ne pige pas le menu déroulant)
> Quoi qu'on utilise, quand on tape au clavier, enregistre, ré-ouvre, on
> ne voit que des caractère "normaux".
> Cependant, soit à l'enregistrement, soit par un réglage au menu, on
> doit pouvoir choisir en quel encodage (quelle table) on veut le
> fichier final.
Oui, mais où...?
> C'est là qu'il faut que tu fasses hyper attention :
> - choisir UTF-8 et déclarer ensuite en PHP et en HTML UTF-8
> - choisir "ANSI" et déclarer CP1252
> par exemple.
OK, mais où et comment faire ça le mieux...?
Les prèf. de Dreamweaver doivent permettre ça logiquement, mais j'ai un peu
de mal à comprendre la boite de dialogue
(je remets le lien)
http://img339.imageshack.us/my.php?image=prefdwcs3ec2.jpg
METIS
Ah d'accord.
Donc on commence à dire que "ça peut pas être clean partout à 100%"
OK, si ça se confirme, j'arrête de me faire chier à rendre ces envois
d'email lisible partout.
J'explique ensuite au client avec quoi il faut le lire...
J'en ai un par exemple qui lit avec Windows Mail
(OE de XP revu pour Vista)
METIS
> Le 12/13/08 1:12 PM, METIS a écrit :
>> Z'êtes tous pareils !
>> Moi j'écris rien.
>> Je fais un formulaire
>
> Et ton formulaire tu le fais en Legos ou en sucettes ?
> Il faut bien que tu l'écrives, non ?
> Il faut bien que ton DW ou je ne sais quel truc wzizziwig te place les
> éléments et même que tu y tapes du texte, non ?
Ouai, cool SAM ! (;o)))))
Ca doit être là le noeud du problème...
(en plus du reste)
METIS
Ah bon ?
Un Mac Intel avec un système 10.... quelque chose, c'est comme un PC
Windows..?
Pascale
news:4943bafd$0$862$ba4a...@news.orange.fr:
> [...]
Je te remercie. Je vais aller voir et/ou revoir tout ça.
--
Pascale
Pascale
news:4943bad9$0$951$ba4a...@news.orange.fr:
> Non, l'ISO-8859-15 est couvert par le ANSI à l'exception de l'euro (et
> autres broutilles) qui n'est pas rangé au même endroit.
> Si l'euro a été écrit en htlm_entité ( € ) il n'y a aucune crainte
> à avoir.
C'est le cas.
> Oui, c'est réglé comme ça par défaut (comme tout ce qui tourne sous
> Windows j'imagine)
>
> Sur Mac à une époque c'était Mac Roman par défaut.
>
> à chacun sa galère quoi.
Je vois ça (-:
--
Pascale
Paul Gaborit
À (at) Sat, 13 Dec 2008 14:38:32 +0100,
SAM <stephanemor...@wanadoo.fr.invalid> écrivait (wrote):
> Non, l'ISO-8859-15 est couvert par le ANSI à l'exception de l'euro (et
> autres broutilles) qui n'est pas rangé au même endroit.
Avec de telles affirmations, on peut aussi dire que la quasi totalité
des encodages sont identiques puisqu'ils utilisent tous la même base
(l'ASCII). Les autres broutilles ne comptent pas !
> Si l'euro a été écrit en htlm_entité ( € ) il n'y a aucune
> crainte à avoir.
Et si on écrit "é" pour les "é", "è" pour les "è", etc.,
on peut tout faire juste avec de l'ASCII et donc ne pas se préoccuper
de l'encodage !
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
SAM
> À (at) Sat, 13 Dec 2008 14:38:32 +0100,
> SAM <stephanemor...@wanadoo.fr.invalid> écrivait (wrote):
>> Non, l'ISO-8859-15 est couvert par le ANSI à l'exception de l'euro (et
>> autres broutilles) qui n'est pas rangé au même endroit.
>
> Avec de telles affirmations, on peut aussi dire que la quasi totalité
> des encodages sont identiques puisqu'ils utilisent tous la même base
> (l'ASCII). Les autres broutilles ne comptent pas !
Oui, bon ... j'ai donné un lien afin qu'on se rende compte par soi-même.
>> Si l'euro a été écrit en htlm_entité ( € ) il n'y a aucune
>> crainte à avoir.
>
> Et si on écrit "é" pour les "é", "è" pour les "è", etc.,
> on peut tout faire juste avec de l'ASCII et donc ne pas se préoccuper
> de l'encodage !
C'est bien ce qu'on faisait il n'y a pas si longtemps, non ?
J'avais même mon soft de ftp qui était réglé par défaut pour tout
remouliner en ASCII (et html-entités).
--
sm
SAM
> SAM wrote:
>
>> C'est là qu'il faut que tu fasses hyper attention :
>> - choisir UTF-8 et déclarer ensuite en PHP et en HTML UTF-8
>> - choisir "ANSI" et déclarer CP1252
>> par exemple.
>
> OK, mais où et comment faire ça le mieux...?
> Les prèf. de Dreamweaver doivent permettre ça logiquement, mais j'ai un
> peu de mal à comprendre la boite de dialogue
> (je remets le lien)
> http://img339.imageshack.us/my.php?image=prefdwcs3ec2.jpg
Ou bien tu le fais exprès pour nous distraire.
Ou bien tu fais un très très grave blocage pour lequel je ne vois que 3
remèdes (au choix) :
- 3 à 6 mois de congès dans les îles
(mais pas là, tu y connais trop de monde)
- 3 à 6 mois de retraite dans une lamasserie à 5000 m d'altitude
(une fois congelé et décongelé ça remettra les choses d'aplomb)
- un bon coup de sabot derrière la tête.
(je penche plus pour cette option)
(et s'il en faut plus d'un, pas de blème : tous à ton service)
Pour en revenir à ta capture-écran,
ça m'a l'air tout bon si tu veux vraiment de l'UTF-8,
- je cocherais la case "no BOM"
- je mettrais "C" à "Formulaire de normalisation"
Vu que je ne sais pas de quoi ils causent, je suis allé voir :
<http://livedocs.adobe.com/dreamweaver/8_fr/using/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=13_pag34.htm>
--
sm
SAM
> SAM wrote:
>>
>> Ha ! ?
>> Mais là tu es en train de parler de la messagerie lue sur le site
>> Orange ?
>> Mais mon pôvre, chez Orange ils n'ont jamais su faire une page web
>
> Donc on commence à dire que "ça peut pas être clean partout à 100%"
L'envoi et la réception "normaux" de mail ne doit pas être à peu près
clean, tout est prévu pour être nickel.
Là on est sur un site ouaibe, ça n'a plus rien à voir, il suffit qu'une
moulinette n'ait pas été bien faite ou oubliée entre la BdD et
l'affichage pour voir apparaitre des défauts.
> OK, si ça se confirme, j'arrête de me faire chier à rendre ces envois
> d'email lisible partout.
Tu te contentes que ce soit lisible sur un e-maileur.
(à mon idée !
car tu ne peux être responsable de défaillances de sites web)
> J'explique ensuite au client avec quoi il faut le lire...
> J'en ai un par exemple qui lit avec Windows Mail
> (OE de XP revu pour Vista)
Je m'en contre... je n'ai pas cette rareté sublime.
Et le maileur employé n'a aucune importance si le mail est envoyé comme
il faut.
(et je pense que l'envoi de mail c'est un peu un métier, en tous cas
c'est une autre paire de manches que de faire une simple page html)
--
sm
Olivier Miakinen
>
>> <http://forum.alsacreations.com/faq/faq-98-S039y-retrouver-entre-ASCII-ANSI-Latin1-ISO-8859-1-MacRoman-Windows-1252-etc.html>
>
> Merci pour ce lien.
Note que, comme le supposait Stéphane (SAM), la dénomination ANSI est
une microsofterie pour désigner CP1252. C'est d'ailleurs dit dans le
document ci-dessus, et aussi dans la doc de ma propre page (cliquer sur
« documentation » tout en bas) :
<cit. http://www.miakinen.net/vrac/charsets/>
Note : dans les documentations Microsoft, on appelle ANSI les tables
utilisées à travers l'interface graphique Windows (CP1252 pour le
français) et OEM celles utilisées dans une fenêtre DOS (CP850 pour la
langue française).
</cit.>
> Mais ce que je ne comprends pas, ce sont les différents
> niveaux de déclaration. Ce que je n'arrive pas à comprendre, c'est qui fait
> quoi : mes programmes sont censés être enregistrés en ANSI, mais je mets
> ISO-8859-15 dans mes en-têtes, ainsi que dans l'en-tête des mails envoyés
> par la fonction mail de PHP.
Tout ira bien si tu n'utilises que la partie commune entre Windows-1252
(ANSI donc) et ISO-8859-15. Exit donc les €, œ, Œ et Ÿ, mais aussi les
fractions 1/4, 1/2 et 3/4 (que je n'inclus pas dans ce message pour ne
pas avoir besoin de passer en UTF-8). Du coup, tu ferais tout aussi bien
de déclarer ISO-8859-1 puisque tu n'utilises aucun caractère spécifique
à ISO-8859-15.
> Faut-il que je réenregistre tous mes programmes en UTF8 ?!
Tout dépend de tes besoins. Tant que ça fonctionne comme ça, autant ne
rien changer. Mais tu dois savoir que si tu veux un jour écrire un € ou
un œ directement plutôt qu'avec € ou œ ça risque de ne pas
marcher et tu pourrais t'arracher les cheveux pour comprendre pourquoi.
>> C'est bien du style à M$ de mélanger n'importe quoi ... le respect
>> d'une norme et des choix d'encodages ... :-(
Ben oui. En même temps, c'est assez pratique pour eux car « ANSI » et
« OEM » sont des termes génériques variables d'une langue à une autre.
>> (en tous cas mon texteur, en encodage, ne me propose pas "ANSI"
>> pourtant il semble il y en avoir près d'une 100aine)
C'est normal, puisque ce terme est lié à la config de chaque Windows.
Le « ANSI » d'un Windows en grec ne sera pas le même que le « ANSI »
d'un Windows en russe. Et donc, en dehors d'une machine Windows donnée
il ne veut rien dire. L'identité « Windows-ANSI = Windows-1252 » n'est
valable que dans quelques pays, y compris chez les Ricains, et comme
ils croient être au centre du monde il n'est pas étonnant qu'ils ne
sachent pas que d'autres existent.
http://blogs.msdn.com/shawnste/archive/2006/09/29/list-of-ansi-code-pages-used-by-windows.aspx
> Notepad++ a fait ça à l'insu de mon plein gré... (:
Je ne sais pas si Notepad++ connaît ISO-8859-15. Alors le choix est
simple : si tu te fiches de pouvoir ou non rentrer un € ou un œ
directement, laisse l'encodage comme il est, si ce n'est que tu peux
bien le déclarer ISO-8859-1 ; si au contraire tu veux pouvoir le faire,
alors choisis UTF-8 (qui est probablement nommé Unicode dans ton
éditeur, de façon tout aussi inappropriée que le nom ANSI).
SAM
> Le 13/12/2008 13:33, Pascale répondait à SAM :
>
>
> Je ne sais pas si Notepad++ connaît ISO-8859-15. Alors le choix est
> simple : si tu te fiches de pouvoir ou non rentrer un € ou un œ
> directement, laisse l'encodage comme il est, si ce n'est que tu peux
> bien le déclarer ISO-8859-1 ; si au contraire tu veux pouvoir le faire,
> alors choisis UTF-8 (qui est probablement nommé Unicode dans ton
> éditeur, de façon tout aussi inappropriée que le nom ANSI).
Le NotePad "normal" brut de fonderie XP connait 'UTF-8'
curieusement il n'est pas renommé, M$ a dû oublier ? ;-)
en tous cas celui que j'ai ...
Je pense que le NotePad ++
- intègre la coloration syntaxique
- un peu plus de charsets
--
sm
Bruno Desthuilliers
(snip)
> Ha! au fait, Olivier, tu n'es pas à l'heure.
> (ou alors c'est Bruno, mais je penche pour ton côté)
Je crains que ce ne soit moi.
Bruno Desthuilliers
(snip)
> Alors c'est peut-être moi avec mes outils qui a un problème.
Non, sans blague ?
Bruno Desthuilliers
> SAM wrote:
>> J'en sais rien ... je n'ai pas Windows ...
>
> J'ai l'impression que tout ceux qui essayent de me faire comprendre
> quelque chose ici, sont sur Mac...?
Pas moi en tous cas.
> Moi j'ai été Mac longtemps
(snip)
> Mais j'ai opté pour les PC
Ma machine est un PC, et je n'ai pas Windows. Que peux-tu en conclure ?
SAM
> Bernd wrote:
>> METIS <m...@mandarine.fr.invalid> wrote:
>>
>>> Mais j'ai opté pour les PC en production surtout Internet pour être
>>> le plus proche possible de la plus grande masse d'utilisateurs.
>>
>> Un Mac Intel t'aurait rendu le même service...
>
> Ah bon ?
> Un Mac Intel avec un système 10.... quelque chose, c'est comme un PC
> Windows..?
Pour taper du texte (un fichier html n'est que du texte) un ordi est un
ordi et peu importe son origine.
Il suffit de savoir que les charsets existent ;-)
et ... s'en servir à bon est sciant :-)
--
sm
Bruno Desthuilliers
> Le 12/13/08 6:01 PM, METIS a écrit :
>> SAM wrote:
>>
>>> C'est là qu'il faut que tu fasses hyper attention :
>>> - choisir UTF-8 et déclarer ensuite en PHP et en HTML UTF-8
>> OK, mais où et comment faire ça le mieux...?
>> Les prèf. de Dreamweaver doivent permettre ça logiquement, mais j'ai
>> un peu de mal à comprendre la boite de dialogue
>> (je remets le lien)
>> http://img339.imageshack.us/my.php?image=prefdwcs3ec2.jpg
(snip)
> Ou bien tu fais un très très grave blocage pour lequel je ne vois que 3
> remèdes (au choix) :
(snip)
> - un bon coup de sabot derrière la tête.
> (je penche plus pour cette option)
> (et s'il en faut plus d'un, pas de blème : tous à ton service)
Pas de problème, à ce stade, je suis même prêt à aller acheter une paire
de sabots pour participer !-)
SAM
ça n'a pas l'air de s'arranger ... :-(
ça me fout un peu le souk dans le suivi des posts.
--
sm
SAM
>
> Ma machine est un PC, et je n'ai pas Windows. Que peux-tu en conclure ?
Qu'en fait c'est un aquarium.
(C'était trop facile ! PC = PisciCulture tt l'monde sait ça)
J'ai bon ?
Non ?
Un Permis de Conduire ?
Un Permis de Construire ?
Un Permis de Chasse ?
Un Permis de C...r ? (c'est en projet au Sénat)
Un Projet de Circulaire (en utf-72)
Un Pote à Charenton ?
Un Poêle à Charbon ?
Une Poêle à Crèpes ?
Non? toujours pas ? j'suis sûr que ce n'est même pas en Français!
Ça vaut pas !
--
sm
Paul Gaborit
À (at) Sat, 13 Dec 2008 19:58:35 +0100,
SAM <stephanemor...@wanadoo.fr.invalid> écrivait (wrote):
> Le 12/13/08 6:52 PM, Paul Gaborit a écrit :
>> À (at) Sat, 13 Dec 2008 14:38:32 +0100,
>> SAM <stephanemor...@wanadoo.fr.invalid> écrivait (wrote):
>>> Non, l'ISO-8859-15 est couvert par le ANSI à l'exception de l'euro (et
>>> autres broutilles) qui n'est pas rangé au même endroit.
>>
>> Avec de telles affirmations, on peut aussi dire que la quasi totalité
>> des encodages sont identiques puisqu'ils utilisent tous la même base
>> (l'ASCII). Les autres broutilles ne comptent pas !
>
> Oui, bon ... j'ai donné un lien afin qu'on se rende compte par soi-même.
L'une des broutilles qui n'est pas rangé au même endroit est
l'apostrophe (la vraie selon Microsoft - pas celle que j'utilise ici)
et on voit encore de nombreuses pages web qui considèrent que ANSI et
ISO-8859-15 sont indentiques, s'afficher avec des apostrophes boguées.
>>> Si l'euro a été écrit en htlm_entité ( € ) il n'y a aucune
>>> crainte à avoir.
>>
>> Et si on écrit "é" pour les "é", "è" pour les "è", etc.,
>> on peut tout faire juste avec de l'ASCII et donc ne pas se préoccuper
>> de l'encodage !
>
> C'est bien ce qu'on faisait il n'y a pas si longtemps, non ?
> J'avais même mon soft de ftp qui était réglé par défaut pour tout
> remouliner en ASCII (et html-entités).
Oui. C'est ce qu'on faisait pour ne pas se préoccuper de
l'encodage. Mais dans certaines langues, le passage systématique par
des entités va multiplier la taille du document par 7 ou 8...
METIS
> METIS a écrit :
>> Moi j'ai été Mac longtemps
> (snip)
>> Mais j'ai opté pour les PC
>
> Ma machine est un PC, et je n'ai pas Windows.
> Que peux-tu en conclure?
...Que tu es sur Linux et tant que codeur, ça m'étonne pas !! (;o)))))
METIS
> (et je pense que l'envoi de mail c'est un peu un métier, en tous cas
> c'est une autre paire de manches que de faire une simple page html)
Certes !
Je suis PAOiste papier. Je me suis mis à Internet il y 10 ans avec les
moyens de l'époque et ça allait assez bien pour les sites simples.
D'où l'utilisation assez systématique de Dreamweaver car je n'ai jamais
appris à coder, de toute façon je suis allergique (c'est pas faute d'avoir
essayé des dizaines de fois).
Mais la confection de sites devient de + en + une affaire de codeur...
METIS
(;o))))))))))))
Mouai... te moques pas hein.
J'ai d'autres cordes à mes arcs !!
(;o)))))))
METIS
> Alors essaie-tente de ne pas te casser le tronc et re-écrit tout en
> brut de fonderie (en mode par défaut) et passes tes déclarations à
> Windos_Latin1 ou CP1252
C'est la même chose ?
(Windows_latin1 plutôt ? Non ?)
Et CP1252 comme ça charset=CP1252 ?
SAM
> SAM wrote:
>> Alors essaie-tente de ne pas te casser le tronc et re-écrit tout en
>> brut de fonderie (en mode par défaut) et passes tes déclarations à
>> Windos_Latin1 ou CP1252
>
> C'est la même chose ?
> (Windows_latin1 plutôt ? Non ?)
On s'en moque des maj/minus tiret haut/bas
puisque mon soft me met :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="fr">
<head>
<meta http-equiv="content-type"
content="text/html; charset=windows-1252">
Et toi ? Ton DW il met quoi ?
> Et CP1252 comme ça charset=CP1252 ?
Pas essayé, de ttes façons moi je suis en Mac Roman ;-)
(non, je mets tout en utf-8)
De toutes façons, et à ce que je comprends, il n'y aura pas que le
formulaire à bien ficeler.
Le PHP qui reçoit ce formulaire et l'envoie par mail sera à bien
verrouiller aussi je présume ?
Je vois qu'il y a un exemple assez complet ici :
<http://fr.php.net/manual/fr/function.mail.php#85772>
et un autre (plus simple ?) ici :
Même page, exemple N°4.
Faire ce qu'il faut pour récupérer le résultat de la fonction mail
(false/true) sur la page html de retour
$mail_OK = $mail_sent = @mail( $to, $subject, $message, $headers );
if($mail_OK) echo 'Le mail est bien parti';
else echo '<h2><blink>Erreur !</blink></h2>';
--
sm
Olivier Miakinen
>
>>> Alors essaie-tente de ne pas te casser le tronc et re-écrit tout en
>>> brut de fonderie (en mode par défaut) et passes tes déclarations à
>>> Windos_Latin1 ou CP1252
>>
>> C'est la même chose ?
>> (Windows_latin1 plutôt ? Non ?)
Le seul nom officiellement déclaré auprès de l'IANA est « windows-1252 »
(à ceci près que la casse n'a pas d'importance). En tout cas, « CP1252 »
ne sera pas plus reconnu que « Windows_Latin1 » ou toute autre variante
que l'on pourrait inventer.
<cit. http://www.iana.org/assignments/character-sets>
Name: windows-1252
MIBenum: 2252
Source: Microsoft
(http://www.iana.org/assignments/charset-reg/windows-1252) [Wendt]
Alias: None
</cit.>
> On s'en moque des maj/minus tiret haut/bas
Non. Des maj/min oui, mais le fait qu'il y ait le choix entre ISO_8859-1
et ISO-8859-1 est officialisé par des alias.
<cit. http://www.iana.org/assignments/character-sets>
Name: ISO_8859-1:1987 [RFC1345,KXS2]
MIBenum: 4
Source: ECMA registry
Alias: iso-ir-100
Alias: ISO_8859-1
Alias: ISO-8859-1 (preferred MIME name)
Alias: latin1
Alias: l1
Alias: IBM819
Alias: CP819
Alias: csISOLatin1
</cit.>
> puisque mon soft me met :
>
> [...]
> content="text/html; charset=windows-1252">
Il emploie donc la seule forme reconnue.
>> Et CP1252 comme ça charset=CP1252 ?
>
> Pas essayé, de ttes façons moi je suis en Mac Roman ;-)
Là, c'est encore plus bizarre. Non seulement il n'y a aucun nom
ressemblant de près ou de loin à « Mac Roman », mais il y a trois noms
possibles (un officiel et deux alias) que presque personne ne connaît :
<cit. http://www.iana.org/assignments/character-sets>
Name: macintosh [RFC1345,KXS2]
MIBenum: 2027
Source: The Unicode Standard ver1.0, ISBN 0-201-56788-1, Oct 1991
Alias: mac
Alias: csMacintosh
</cit>
> (non, je mets tout en utf-8)
;-)
Mickaël Wolff
> ...Que tu es sur Linux et tant que codeur, ça m'étonne pas !! (;o)))))
Comme s'il n'y avait que Linux dans la vie :D
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
METIS
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html lang="fr">
> <head>
> <meta http-equiv="content-type"
> content="text/html; charset=windows-1252">
>
>
> Et toi ? Ton DW il met quoi ?
windows-1250 qu'il me met...
Avec ces réglages pour l'ouverture de nouveaux documents :
http://img261.imageshack.us/my.php?image=prefdw1250oz6.gif
(je mets sur ImageShack car ça reste indéfiniment)
> De toutes façons, et à ce que je comprends, il n'y aura pas que le
> formulaire à bien ficeler.
> Le PHP qui reçoit ce formulaire et l'envoie par mail sera à bien
> verrouiller aussi je présume ?
Tout à fait c'était un peu la question tout au départ, mis à part les
question de sécurité (c'est encore autre chose).
En fait, je dois mettre le même charset partout pour résoudre ce problème
d'affichage.
J'ai pas encore essayé sur le webmail d'Orange avec
charset=windows-1252
> Je vois qu'il y a un exemple assez complet ici :
> <http://fr.php.net/manual/fr/function.mail.php#85772>
> et un autre (plus simple ?) ici :
> Même page, exemple N°4.
Oui, alors là, je dois faire confiance car je ne suis pas capable de donner
un avis sur le code.
Je peux juste donner un avis sur le côté pratique de la préparation du
résultat envoyé par email.
> Faire ce qu'il faut pour récupérer le résultat de la fonction mail
> (false/true) sur la page html de retour
>
> $mail_OK = $mail_sent = @mail( $to, $subject, $message, $headers );
>
> if($mail_OK) echo 'Le mail est bien parti';
> else echo '<h2><blink>Erreur !</blink></h2>';
Moui...(;o))))))))
METIS
> Je vois qu'il y a un exemple assez complet ici :
> <http://fr.php.net/manual/fr/function.mail.php#85772>
Chui pas cap de juger du code...(;o)))))
Actuellement, j'envoie avec ça :
http://cjoint.com/?mpkP7KIILS
Avec le captcha, la sécurité me suffit.
(sauf si on me dit que ça ne le fait pas du tout).