J'utilise une macro pour enregistrer automatiquement un lien hypertexte
dans une cellule.
Pour cela je converti certains caractères (espace en %20 par exemple).
Mais j'ai quelques problèmes pour certains caractères spéciaux:
exemple le retour à la ligne "utile et fonctionnel" sous Mac est %0D (13)
tandis qu'il faut %0A (10) sous windows. Y a-t-il un moyen de faire ces
conversions de façon dépendante du système et/ou de savoir sur quel système
on est (et s'adapter)... Car ma macro et mon fichier est utilisé sur Mac et
sur Win !
des idées ?
(sous mac, il arrive carrément parfois que ça plante lamentablement au
moment de créer l' " hyperlink ")
PS/ à l'heure actuelle je n'ai pas essayé encore toutes les façons sous
Mac
puisque je suis essentiellement sous Win... Il me reste en particulier à essayer la fonction ci-dessus, avec dans la chaîne initiale des vbNewLine. Mais pour le moment je vois mal comment me passer de la fonction de convertion.
Hello,
voila, j'ai trouvé ce que dit la norme, c'est la RFC 2822 qui définit le format des messages Internet: http://www.faqs.org/rfcs/rfc2822.html
Je cite ici le paragraphe 2.3, qui traîte spécifiquement de la partie Body (je cite ici exactement la RFC):
---------------------------------------------------------------------------- 2.3. Body
The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows:
- CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.
C'est parafaitement clair ici: "Les caractères CR et LF DOIVENT seulement apparaître ensemble, en tant qu'entité <CRLF>. Ils ne DOIVENT PAS apparaître séparément dans la section BODY."
La question ne se pose donc plus: un saut de ligne = <CRLF>
C'est au client de messagerie de se charger de l'affichage en fonction de l'OS.
-- Jean-marc
"dcdc2" <anonymous@discussions.microsoft.com> a écrit dans le message de
news:OO4Zw1ajEHA.2652@TK2MSFTNGP15.phx.gbl...
PS/ à l'heure actuelle je n'ai pas essayé encore toutes les façons sous
Mac
puisque je suis essentiellement sous Win... Il me reste en particulier à
essayer la fonction ci-dessus, avec dans la chaîne initiale des vbNewLine.
Mais pour le moment je vois mal comment me passer de la fonction de
convertion.
Hello,
voila, j'ai trouvé ce que dit la norme, c'est la RFC 2822 qui définit le
format des messages Internet:
http://www.faqs.org/rfcs/rfc2822.html
Je cite ici le paragraphe 2.3, qui traîte spécifiquement de la partie Body
(je cite ici exactement la RFC):
----------------------------------------------------------------------------
2.3. Body
The body of a message is simply lines of US-ASCII characters. The
only two limitations on the body are as follows:
- CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
C'est parafaitement clair ici:
"Les caractères CR et LF DOIVENT seulement apparaître ensemble, en tant
qu'entité <CRLF>.
Ils ne DOIVENT PAS apparaître séparément dans la section BODY."
La question ne se pose donc plus: un saut de ligne = <CRLF>
C'est au client de messagerie de se charger de l'affichage en fonction de
l'OS.
PS/ à l'heure actuelle je n'ai pas essayé encore toutes les façons sous
Mac
puisque je suis essentiellement sous Win... Il me reste en particulier à essayer la fonction ci-dessus, avec dans la chaîne initiale des vbNewLine. Mais pour le moment je vois mal comment me passer de la fonction de convertion.
Hello,
voila, j'ai trouvé ce que dit la norme, c'est la RFC 2822 qui définit le format des messages Internet: http://www.faqs.org/rfcs/rfc2822.html
Je cite ici le paragraphe 2.3, qui traîte spécifiquement de la partie Body (je cite ici exactement la RFC):
---------------------------------------------------------------------------- 2.3. Body
The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows:
- CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.
C'est parafaitement clair ici: "Les caractères CR et LF DOIVENT seulement apparaître ensemble, en tant qu'entité <CRLF>. Ils ne DOIVENT PAS apparaître séparément dans la section BODY."
La question ne se pose donc plus: un saut de ligne = <CRLF>
C'est au client de messagerie de se charger de l'affichage en fonction de l'OS.
-- Jean-marc
dcdc2
Merci beaucoup Jean-Marc c'est une réponse très instructive. Ceci dit, pour ma fonction, je suis quand même toujours obligé de l'utiliser car il faut quand même former l'URL complète avec mailto: et les caractères comme & au début (dans le sujet par exemple) se doivent d'être remplacés.
pour le saut de ligne, je suis heureux de ne plus avoir à distinguer de système
qui plus est pour les caractères autres (non ascii) le système s'en sort plutôt bien pour la conversion et les accents passent particulièrement bien (tant mieux).
Merci beaucoup Jean-Marc c'est une réponse très instructive.
Ceci dit, pour ma fonction, je suis quand même toujours obligé de
l'utiliser
car il faut quand même former l'URL complète avec mailto: et les caractères
comme & au début (dans le sujet par exemple) se doivent d'être remplacés.
pour le saut de ligne, je suis heureux de ne plus avoir à distinguer de
système
qui plus est pour les caractères autres (non ascii) le système s'en sort
plutôt bien pour la conversion et les accents passent particulièrement bien
(tant mieux).
Merci beaucoup Jean-Marc c'est une réponse très instructive. Ceci dit, pour ma fonction, je suis quand même toujours obligé de l'utiliser car il faut quand même former l'URL complète avec mailto: et les caractères comme & au début (dans le sujet par exemple) se doivent d'être remplacés.
pour le saut de ligne, je suis heureux de ne plus avoir à distinguer de système
qui plus est pour les caractères autres (non ascii) le système s'en sort plutôt bien pour la conversion et les accents passent particulièrement bien (tant mieux).
Jean-Marc
"dcdc2" a écrit dans le message de news:
Merci beaucoup Jean-Marc c'est une réponse très instructive. Ceci dit, pour ma fonction, je suis quand même toujours obligé de l'utiliser car il faut quand même former l'URL complète avec mailto: et les
caractères
comme & au début (dans le sujet par exemple) se doivent d'être remplacés.
pour le saut de ligne, je suis heureux de ne plus avoir à distinguer de système
De ce point de vue la lecture des RFC est souvent tout à fait instructive. J'essaie d'avoir le réflexe quand je me pose des questions de ce genre.
Je ne me rapellais plus exactement de ce que disait les RFC au sujet du CRLF, et c'est un sympathiqe contibuteur de fr.comp.mail qui m'a redonné la référence.
-- Jean-marc
"dcdc2" <anonymous@discussions.microsoft.com> a écrit dans le message de
news:uWSY31bjEHA.636@TK2MSFTNGP12.phx.gbl...
Merci beaucoup Jean-Marc c'est une réponse très instructive.
Ceci dit, pour ma fonction, je suis quand même toujours obligé de
l'utiliser
car il faut quand même former l'URL complète avec mailto: et les
caractères
comme & au début (dans le sujet par exemple) se doivent d'être remplacés.
pour le saut de ligne, je suis heureux de ne plus avoir à distinguer de
système
De ce point de vue la lecture des RFC est souvent tout à fait instructive.
J'essaie d'avoir le réflexe quand je me pose des questions de ce genre.
Je ne me rapellais plus exactement de ce que disait les RFC au sujet du
CRLF, et c'est un sympathiqe contibuteur de fr.comp.mail qui m'a redonné la
référence.
Merci beaucoup Jean-Marc c'est une réponse très instructive. Ceci dit, pour ma fonction, je suis quand même toujours obligé de l'utiliser car il faut quand même former l'URL complète avec mailto: et les
caractères
comme & au début (dans le sujet par exemple) se doivent d'être remplacés.
pour le saut de ligne, je suis heureux de ne plus avoir à distinguer de système
De ce point de vue la lecture des RFC est souvent tout à fait instructive. J'essaie d'avoir le réflexe quand je me pose des questions de ce genre.
Je ne me rapellais plus exactement de ce que disait les RFC au sujet du CRLF, et c'est un sympathiqe contibuteur de fr.comp.mail qui m'a redonné la référence.
-- Jean-marc
dcdc2
En l'occurence, ce n'est pas cette norme strict qui est appliquée, donc la lecture de la norme est (presque) décorative. En effet, il y a des parties utiles, puisque toujours employés et des parties caduques car le système transmet très bien les caractères internationaux... Séparer l'utile de l'inutile se fait rapidement en faisant quelques essais. Ou en partageant les expériences (d'où les forums pour demander à ceux qui l'ont déjà fait).
La norme n'est utile que pour un développement plus lourd ou pour sa culture générale. Pour une petite macro de 20 lignes, lire 5 docs en détail est idiot. Mon avis est donc plutôt que l'on prend en main cette culture et ces normes au fil des expériences. Au fil des années.
En l'occurence, ce n'est pas cette norme strict qui est appliquée, donc la
lecture de la norme est (presque) décorative. En effet, il y a des parties
utiles, puisque toujours employés et des parties caduques car le système
transmet très bien les caractères internationaux... Séparer l'utile de
l'inutile se fait rapidement en faisant quelques essais. Ou en partageant
les expériences (d'où les forums pour demander à ceux qui l'ont déjà fait).
La norme n'est utile que pour un développement plus lourd ou pour sa
culture générale. Pour une petite macro de 20 lignes, lire 5 docs en détail
est idiot. Mon avis est donc plutôt que l'on prend en main cette culture et
ces normes au fil des expériences. Au fil des années.
En l'occurence, ce n'est pas cette norme strict qui est appliquée, donc la lecture de la norme est (presque) décorative. En effet, il y a des parties utiles, puisque toujours employés et des parties caduques car le système transmet très bien les caractères internationaux... Séparer l'utile de l'inutile se fait rapidement en faisant quelques essais. Ou en partageant les expériences (d'où les forums pour demander à ceux qui l'ont déjà fait).
La norme n'est utile que pour un développement plus lourd ou pour sa culture générale. Pour une petite macro de 20 lignes, lire 5 docs en détail est idiot. Mon avis est donc plutôt que l'on prend en main cette culture et ces normes au fil des expériences. Au fil des années.
Jean-Marc
"dcdc2" a écrit dans le message de news:
En l'occurence, ce n'est pas cette norme strict qui est appliquée, donc la lecture de la norme est (presque) décorative. En effet, il y a des parties utiles, puisque toujours employés et des parties caduques car le système transmet très bien les caractères internationaux...
Je ne veux pas polémiquer, mais à mon sens tu te trompes sur ce point. La RFC 2822 n'est pas caduque. Elle dit si qui est légal et ce qui ne l'est pas. En particulier elle te garantit que ton message sera transmis et affiché proprement d'un bout à l'autre de la chaîne si tu emploies des caractères US ASCII 7 bits. Elle ne dit RIEN sur les autres.
Le petit test suivant prend 5 minutes à faire, et te convaincra que la norme n'est PAS du tout obsolète.
1/ lance une session dos, et fait un telnet sur le port 25 de ton serveur SMTP
TELNET relay.skynet.be 25 puis: EHLO trucmuche MAIL FROM: RCPT TO: DATA coucou éèà. QUIT
Maintenant, va lire ton mail dans ton client mail favori et regarde ce qui se passe. Chez moi, je reçois à l'affichage:
coucou ‚Š…
Et c'est normal! j'ai envoyé depuis une console dos un message pour SMTP avec les caractères éèà, pris dans le jeu de caractères utilisé par ma console DOS. Ceux ci ont été insérés (sous forme de leur code ASCII étendu (==> donc non portable)) et je les reçois dans un client windows, qui essaie d'afficher comme il peut ces caractères plus grands que 127 (ils les traduit donc pour l'affichage dans sa table à lui). Résultat, il m'affiche un contenu qui n'est pas ok (à l'affichage).
"dcdc2" <anonymous@discussions.microsoft.com> a écrit dans le message de
news:OarNVHejEHA.1512@TK2MSFTNGP10.phx.gbl...
En l'occurence, ce n'est pas cette norme strict qui est appliquée, donc la
lecture de la norme est (presque) décorative. En effet, il y a des parties
utiles, puisque toujours employés et des parties caduques car le système
transmet très bien les caractères internationaux...
Je ne veux pas polémiquer, mais à mon sens tu te trompes sur ce point. La
RFC 2822 n'est pas caduque. Elle dit si qui est légal et ce qui ne l'est
pas. En particulier elle te garantit que ton message sera transmis et
affiché proprement d'un bout à l'autre de la chaîne si tu emploies des
caractères US ASCII 7 bits. Elle ne dit RIEN sur les autres.
Le petit test suivant prend 5 minutes à faire, et te convaincra que la norme
n'est PAS du tout obsolète.
1/ lance une session dos, et fait un telnet sur le port 25 de ton serveur
SMTP
TELNET relay.skynet.be 25
puis:
EHLO trucmuche
MAIL FROM: mon_adresse@email
RCPT TO: mon_adresse@email
DATA
coucou
éèà.
QUIT
Maintenant, va lire ton mail dans ton client mail favori et regarde ce qui
se passe.
Chez moi, je reçois à l'affichage:
coucou
‚Š…
Et c'est normal! j'ai envoyé depuis une console dos un message pour SMTP
avec les caractères éèà, pris dans le jeu de caractères utilisé par ma
console DOS. Ceux ci ont été insérés (sous forme de leur code ASCII étendu
(==> donc non portable)) et je les reçois dans un client windows, qui essaie
d'afficher comme il peut ces caractères plus grands que 127 (ils les traduit
donc pour l'affichage dans sa table à lui). Résultat, il m'affiche un
contenu qui n'est pas ok (à l'affichage).
En l'occurence, ce n'est pas cette norme strict qui est appliquée, donc la lecture de la norme est (presque) décorative. En effet, il y a des parties utiles, puisque toujours employés et des parties caduques car le système transmet très bien les caractères internationaux...
Je ne veux pas polémiquer, mais à mon sens tu te trompes sur ce point. La RFC 2822 n'est pas caduque. Elle dit si qui est légal et ce qui ne l'est pas. En particulier elle te garantit que ton message sera transmis et affiché proprement d'un bout à l'autre de la chaîne si tu emploies des caractères US ASCII 7 bits. Elle ne dit RIEN sur les autres.
Le petit test suivant prend 5 minutes à faire, et te convaincra que la norme n'est PAS du tout obsolète.
1/ lance une session dos, et fait un telnet sur le port 25 de ton serveur SMTP
TELNET relay.skynet.be 25 puis: EHLO trucmuche MAIL FROM: RCPT TO: DATA coucou éèà. QUIT
Maintenant, va lire ton mail dans ton client mail favori et regarde ce qui se passe. Chez moi, je reçois à l'affichage:
coucou ‚Š…
Et c'est normal! j'ai envoyé depuis une console dos un message pour SMTP avec les caractères éèà, pris dans le jeu de caractères utilisé par ma console DOS. Ceux ci ont été insérés (sous forme de leur code ASCII étendu (==> donc non portable)) et je les reçois dans un client windows, qui essaie d'afficher comme il peut ces caractères plus grands que 127 (ils les traduit donc pour l'affichage dans sa table à lui). Résultat, il m'affiche un contenu qui n'est pas ok (à l'affichage).
dcdc2
Je ne dis pas que la norme est obsolète, je dis qu'elle n'est pas forcément la plus utile, du moins pas à elle seule pour profiter des applications pratiques. Car on ne fait pas un exo pour s'amuser mais une application pratique, n'est-ce pas ?
Je ne dis pas que la norme est obsolète, je dis qu'elle n'est pas forcément
la plus utile, du moins pas à elle seule pour profiter des applications
pratiques. Car on ne fait pas un exo pour s'amuser mais une application
pratique, n'est-ce pas ?
Je ne dis pas que la norme est obsolète, je dis qu'elle n'est pas forcément la plus utile, du moins pas à elle seule pour profiter des applications pratiques. Car on ne fait pas un exo pour s'amuser mais une application pratique, n'est-ce pas ?
jean-marc
"dcdc2" wrote in message news:
Je ne dis pas que la norme est obsolète, je dis qu'elle n'est pas
forcément
la plus utile, du moins pas à elle seule pour profiter des applications pratiques. Car on ne fait pas un exo pour s'amuser mais une application pratique, n'est-ce pas ?
Oui bien sur. Et pour que l'application soit "pratique", il faut qu'elle soit utilisable. Par extension, utilisable par le plus grand nombre. Les normes sont faites pour cela, pour donner un cadre aux implémentations. Mais bien entendu, chacun est libre de limiter volontairement l'utilisation d'une application, pour autant que les limites soient clairement exposées: "Mon application suppose que vous utilisez un système qui utilise et affiche les caractères étendus comme le jeu de caractères Windows-CP1152".
Voir à ce sujet une très utile table de correspondance, et l'article associé: http://openweb.eu.org/articles/jeux_caracteres/ http://worldserver3.oleane.com/tthomas/jeucar.html
-- Jean-marc
"dcdc2" <anonymous@discussions.microsoft.com> wrote in message
news:OdTsg3yjEHA.2948@TK2MSFTNGP11.phx.gbl...
Je ne dis pas que la norme est obsolète, je dis qu'elle n'est pas
forcément
la plus utile, du moins pas à elle seule pour profiter des applications
pratiques. Car on ne fait pas un exo pour s'amuser mais une application
pratique, n'est-ce pas ?
Oui bien sur. Et pour que l'application soit "pratique", il faut qu'elle
soit utilisable.
Par extension, utilisable par le plus grand nombre. Les normes sont faites
pour
cela, pour donner un cadre aux implémentations.
Mais bien entendu, chacun est libre de limiter volontairement l'utilisation
d'une
application, pour autant que les limites soient clairement exposées: "Mon
application
suppose que vous utilisez un système qui utilise et affiche les caractères
étendus comme
le jeu de caractères Windows-CP1152".
Voir à ce sujet une très utile table de correspondance, et l'article
associé:
http://openweb.eu.org/articles/jeux_caracteres/
http://worldserver3.oleane.com/tthomas/jeucar.html
Je ne dis pas que la norme est obsolète, je dis qu'elle n'est pas
forcément
la plus utile, du moins pas à elle seule pour profiter des applications pratiques. Car on ne fait pas un exo pour s'amuser mais une application pratique, n'est-ce pas ?
Oui bien sur. Et pour que l'application soit "pratique", il faut qu'elle soit utilisable. Par extension, utilisable par le plus grand nombre. Les normes sont faites pour cela, pour donner un cadre aux implémentations. Mais bien entendu, chacun est libre de limiter volontairement l'utilisation d'une application, pour autant que les limites soient clairement exposées: "Mon application suppose que vous utilisez un système qui utilise et affiche les caractères étendus comme le jeu de caractères Windows-CP1152".
Voir à ce sujet une très utile table de correspondance, et l'article associé: http://openweb.eu.org/articles/jeux_caracteres/ http://worldserver3.oleane.com/tthomas/jeucar.html
-- Jean-marc
dcdc2
J'ajoute ici mon expérience concrète après essais sous Win/Mac d'un même programme sous l'aspect pratique et l'usage de la méthode :
ActiveWorkbook.FollowHyperlink Address:=T$, AddHistory:úlse et éventuellement: ... , ExtraInfo:=T2$, Method:=msoMethodGet
on peut utiliser T="mailto: ?Subject=Toto%20Tata&Body=Début%20du%20message" qui fonctionne bien. Ou séparer en deux et ajouter un T2 T=mailto: et T2="Subject=Toto%20Tata&Body=Début%20du%20message"
La limite à 998 caractères (de la norme) est à respecter. Lorsqu'on le passe en paramètre Address, windows peut accepter un dépassement, mais pas sous le paramètre ExtraInfo (là il y a une limite de taille). Sous Mac la limite s'applique quel que soit l'argument. Sorti de ces cas excel plante ! (pas d'erreur, un plantage). (Conseil : ne pas déboguer mais Annuler le débogueur sinon excel continue de tourner en tâche de fond.) Donc il vaut mieux avoir un T = left(T,998) pour éviter un plantage.
Les caractères spéciaux peuvent avoir besoin d'être transformés par leurs codes ascii ( & ? = % ) qui servent déjà et ont un sens précis dans l'URL. En e qui concerne les sauts de ligne, n'en déplaise à la norme, mais IL NE FAUT PAS la respecter et envoyer la chaîne "%0A%0D" (ou l'inverse je ne sais plus l'ordre entre 13 et 10). Car sous Mac cela ajoute des petits carrés au début ou à la fin de la ligne sautée. Cela n'est pas acceptable. (oui respecter la norme ne fonctionne pas forcément en pratique, désolé !)
j'ai choisi d'insérer la chaîne vbNewLine (constante définie par vba) suivie d'une séquence: Spe_char = .Substitute(Spe_char, Chr(13), "%0D") Spe_char = .Substitute(Spe_char, Chr(10), "%0A") ainsi le saut de ligne apparaît bien sous les deux OS. (et pas autrement)
Enfin les caractères non ASCII (accents etc...) semblent très bien convertis et intégrés. On les retrouve comme voulu dans le client de messagerie ainsi ouvert.
Si quelqu'un a des moyens plus directs ou simples, ses remarques sont bienvenues.
J'ajoute ici mon expérience concrète après essais sous Win/Mac d'un même
programme
sous l'aspect pratique et l'usage de la méthode :
ActiveWorkbook.FollowHyperlink Address:=T$, AddHistory:úlse
et éventuellement:
... , ExtraInfo:=T2$, Method:=msoMethodGet
on peut utiliser
T="mailto: nom@domaine.pays?Subject=Toto%20Tata&Body=Début%20du%20message"
qui fonctionne bien.
Ou séparer en deux et ajouter un T2
T=mailto:nom@domaine.pays
et T2="Subject=Toto%20Tata&Body=Début%20du%20message"
La limite à 998 caractères (de la norme) est à respecter. Lorsqu'on le
passe en paramètre Address, windows peut accepter un dépassement, mais pas
sous le paramètre ExtraInfo (là il y a une limite de taille). Sous Mac la
limite s'applique quel que soit l'argument. Sorti de ces cas excel plante !
(pas d'erreur, un plantage). (Conseil : ne pas déboguer mais Annuler le
débogueur sinon excel continue de tourner en tâche de fond.) Donc il vaut
mieux avoir un T = left(T,998) pour éviter un plantage.
Les caractères spéciaux peuvent avoir besoin d'être transformés par leurs
codes ascii ( & ? = % ) qui servent déjà et ont un sens précis dans l'URL.
En e qui concerne les sauts de ligne, n'en déplaise à la norme, mais IL NE
FAUT PAS la respecter et envoyer la chaîne "%0A%0D" (ou l'inverse je ne sais
plus l'ordre entre 13 et 10). Car sous Mac cela ajoute des petits carrés au
début ou à la fin de la ligne sautée.
Cela n'est pas acceptable.
(oui respecter la norme ne fonctionne pas forcément en pratique, désolé !)
j'ai choisi d'insérer la chaîne vbNewLine (constante définie par vba)
suivie d'une séquence:
Spe_char = .Substitute(Spe_char, Chr(13), "%0D")
Spe_char = .Substitute(Spe_char, Chr(10), "%0A")
ainsi le saut de ligne apparaît bien sous les deux OS. (et pas autrement)
Enfin les caractères non ASCII (accents etc...) semblent très bien convertis
et intégrés.
On les retrouve comme voulu dans le client de messagerie ainsi ouvert.
Si quelqu'un a des moyens plus directs ou simples, ses remarques sont
bienvenues.
J'ajoute ici mon expérience concrète après essais sous Win/Mac d'un même programme sous l'aspect pratique et l'usage de la méthode :
ActiveWorkbook.FollowHyperlink Address:=T$, AddHistory:úlse et éventuellement: ... , ExtraInfo:=T2$, Method:=msoMethodGet
on peut utiliser T="mailto: ?Subject=Toto%20Tata&Body=Début%20du%20message" qui fonctionne bien. Ou séparer en deux et ajouter un T2 T=mailto: et T2="Subject=Toto%20Tata&Body=Début%20du%20message"
La limite à 998 caractères (de la norme) est à respecter. Lorsqu'on le passe en paramètre Address, windows peut accepter un dépassement, mais pas sous le paramètre ExtraInfo (là il y a une limite de taille). Sous Mac la limite s'applique quel que soit l'argument. Sorti de ces cas excel plante ! (pas d'erreur, un plantage). (Conseil : ne pas déboguer mais Annuler le débogueur sinon excel continue de tourner en tâche de fond.) Donc il vaut mieux avoir un T = left(T,998) pour éviter un plantage.
Les caractères spéciaux peuvent avoir besoin d'être transformés par leurs codes ascii ( & ? = % ) qui servent déjà et ont un sens précis dans l'URL. En e qui concerne les sauts de ligne, n'en déplaise à la norme, mais IL NE FAUT PAS la respecter et envoyer la chaîne "%0A%0D" (ou l'inverse je ne sais plus l'ordre entre 13 et 10). Car sous Mac cela ajoute des petits carrés au début ou à la fin de la ligne sautée. Cela n'est pas acceptable. (oui respecter la norme ne fonctionne pas forcément en pratique, désolé !)
j'ai choisi d'insérer la chaîne vbNewLine (constante définie par vba) suivie d'une séquence: Spe_char = .Substitute(Spe_char, Chr(13), "%0D") Spe_char = .Substitute(Spe_char, Chr(10), "%0A") ainsi le saut de ligne apparaît bien sous les deux OS. (et pas autrement)
Enfin les caractères non ASCII (accents etc...) semblent très bien convertis et intégrés. On les retrouve comme voulu dans le client de messagerie ainsi ouvert.
Si quelqu'un a des moyens plus directs ou simples, ses remarques sont bienvenues.
