Pour éviter les spams j'utilisais un tableau que j'avais trouvé sur le
web, je remplaçais des lettres par une expression qui commençait par %,
par exemple : %40f%72e%65%2E%66r pour @free.fr
Je ne trouve plus ce tableau.
Il y a ce codeur :
http://aspirine.org/emailcode.php
mais dans Komposer, je ne vois pas le nom du lien, alors qu'il est
visible et qu'il marche avec Opera)
Il y a celui-ci :
http://biblio.openbaz.be/txt2html/txt2crypt.php
mais dans le source je vois l'adresse complète, c'est à dire pas codée,
avec quelques %0A clairsemés dans l'adresse.
Le résultat en cliquant est une adresse hiéroglyphée, et il ne prend
pas en compte le sujet.
Sinon le tableau dont je parle au début me convient bien, savez vous où
on peut le trouver ? Je ne sais plus où il était, peut-être ici :
http://neokraft.net/sottises/mailencoder/
Ou alors les clients mails considèrent qu'ils reçoivent leurs URL en UTF-8, comme suggéré dans la RFC comme codage "par défaut" ?
Par example :
text/plain Noël
header =?ISO-8859-1?Q?Noël? HTML href %3D%3FISO-8859-1%3FQ%3FNo%3DEBl%3F%3D
B.M.
siger a écrit :
B.M. a écrit :
J'ai utilisé à une époque ce site : http://www.wbwip.com/wbw/emailencoder.html Mais je pense que la plupart des robots sont maintenant capables de décoder ça.
Ici : http://aspirine.org/cgi-bin/trouvemail.pl on peut tester, je l'ai fait sur des pages avec l'adresse écrite en ASCII et le test ne trouve rien. Mais je ne sais pas si ce test est valable.
Par contre, avec la méthode du site que je proposais il les trouve bien et il qualifie la méthode "d'encodage trivial". Donc oublions ce site. -- B. M.
siger a écrit :
B.M. a écrit :
J'ai utilisé à une époque ce site :
http://www.wbwip.com/wbw/emailencoder.html
Mais je pense que la plupart des robots sont maintenant capables de
décoder ça.
Ici : http://aspirine.org/cgi-bin/trouvemail.pl
on peut tester, je l'ai fait sur des pages avec l'adresse écrite en
ASCII et le test ne trouve rien. Mais je ne sais pas si ce test est
valable.
Par contre, avec la méthode du site que je proposais il les trouve bien
et il qualifie la méthode "d'encodage trivial". Donc oublions ce site.
--
B. M.
J'ai utilisé à une époque ce site : http://www.wbwip.com/wbw/emailencoder.html Mais je pense que la plupart des robots sont maintenant capables de décoder ça.
Ici : http://aspirine.org/cgi-bin/trouvemail.pl on peut tester, je l'ai fait sur des pages avec l'adresse écrite en ASCII et le test ne trouve rien. Mais je ne sais pas si ce test est valable.
Par contre, avec la méthode du site que je proposais il les trouve bien et il qualifie la méthode "d'encodage trivial". Donc oublions ce site. -- B. M.
Sergio
Olivier Miakinen vient de nous annoncer :
Attention : ainsi que le rappelle Pierre Goiffon, au delà de 7f règne un gros flou selon que le destinataire le comprendra comme de l'ISO-8859-1, de l'ISO-8859-15, du CP1252, du CP850, du MacRoman, de l'UTF-8, etc. Mais bon, pour une adresse de courriel chez free il ne devrait pas y avoir de souci.
Sauf à vraiment le vouloir, il est très rare d'avoir autre chose que du pure ASCII (< 0x7F) dans un email !
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Olivier Miakinen vient de nous annoncer :
Attention : ainsi que le rappelle Pierre Goiffon, au delà de 7f règne un
gros flou selon que le destinataire le comprendra comme de l'ISO-8859-1,
de l'ISO-8859-15, du CP1252, du CP850, du MacRoman, de l'UTF-8, etc.
Mais bon, pour une adresse de courriel chez free il ne devrait pas y
avoir de souci.
Sauf à vraiment le vouloir, il est très rare d'avoir autre chose que du
pure ASCII (< 0x7F) dans un email !
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Attention : ainsi que le rappelle Pierre Goiffon, au delà de 7f règne un gros flou selon que le destinataire le comprendra comme de l'ISO-8859-1, de l'ISO-8859-15, du CP1252, du CP850, du MacRoman, de l'UTF-8, etc. Mais bon, pour une adresse de courriel chez free il ne devrait pas y avoir de souci.
Sauf à vraiment le vouloir, il est très rare d'avoir autre chose que du pure ASCII (< 0x7F) dans un email !
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Pierre Goiffon
Olivier Miakinen wrote:
Cela m'amuserait de voir une page web en EBCDIC, tiens !
:) Cela dis, sans rire, j'en ai vu !
alors les clients mails considèrent qu'ils reçoivent leurs URL en UTF-8, comme suggéré dans la RFC comme codage "par défaut" ?
Peu importe tant que les caractères codés sont tous dans us-ascii
Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ? Des caractères hors us-ascii ça doit être rare mais c'est possible, non ? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
Et puis il y a aussi la possibilité de spécifier le sujet dans un lien mailto...
Olivier Miakinen wrote:
Cela m'amuserait de voir une page web
en EBCDIC, tiens !
:)
Cela dis, sans rire, j'en ai vu !
alors les clients mails considèrent qu'ils reçoivent leurs URL en UTF-8,
comme suggéré dans la RFC comme codage "par défaut" ?
Peu importe tant que les caractères codés sont tous dans us-ascii
Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ?
Des caractères hors us-ascii ça doit être rare mais c'est possible, non
? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
Et puis il y a aussi la possibilité de spécifier le sujet dans un lien
mailto...
Cela m'amuserait de voir une page web en EBCDIC, tiens !
:) Cela dis, sans rire, j'en ai vu !
alors les clients mails considèrent qu'ils reçoivent leurs URL en UTF-8, comme suggéré dans la RFC comme codage "par défaut" ?
Peu importe tant que les caractères codés sont tous dans us-ascii
Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ? Des caractères hors us-ascii ça doit être rare mais c'est possible, non ? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
Et puis il y a aussi la possibilité de spécifier le sujet dans un lien mailto...
Olivier Miakinen
Le 16/12/2008 10:45, Pierre Goiffon a écrit :
Peu importe tant que les caractères codés sont tous dans us-ascii
Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ? Des caractères hors us-ascii ça doit être rare mais c'est possible, non ? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
De façon expérimentale, peut-être. Si Nicolas Krebs passe dans le coin il nous redonnera sans doute les RFC (ou drafts) sur le sujet. Dans la réalité, les caractères autorisés sont un sous-ensemble d'us-ascii. Quand on pense que même le caractère « + » est encore rejeté par la plupart des formulaires demandant une adresse de courriel, cela donne une bonne idée du chemin encore à parcourir !
Voici un aperçu des caractères autorisés actuellement : <http://faqfclphp.free.fr/#rub5.3>.
Et puis il y a aussi la possibilité de spécifier le sujet dans un lien mailto...
Ok, mais tu t'écartes de la question d'origine.
Le 16/12/2008 10:45, Pierre Goiffon a écrit :
Peu importe tant que les caractères codés sont tous dans us-ascii
Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ?
Des caractères hors us-ascii ça doit être rare mais c'est possible,
non ? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
De façon expérimentale, peut-être. Si Nicolas Krebs passe dans le coin
il nous redonnera sans doute les RFC (ou drafts) sur le sujet. Dans la
réalité, les caractères autorisés sont un sous-ensemble d'us-ascii.
Quand on pense que même le caractère « + » est encore rejeté par la
plupart des formulaires demandant une adresse de courriel, cela donne
une bonne idée du chemin encore à parcourir !
Voici un aperçu des caractères autorisés actuellement :
<http://faqfclphp.free.fr/#rub5.3>.
Et puis il y a aussi la possibilité de spécifier le sujet dans un lien
mailto...
Peu importe tant que les caractères codés sont tous dans us-ascii
Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ? Des caractères hors us-ascii ça doit être rare mais c'est possible, non ? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
De façon expérimentale, peut-être. Si Nicolas Krebs passe dans le coin il nous redonnera sans doute les RFC (ou drafts) sur le sujet. Dans la réalité, les caractères autorisés sont un sous-ensemble d'us-ascii. Quand on pense que même le caractère « + » est encore rejeté par la plupart des formulaires demandant une adresse de courriel, cela donne une bonne idée du chemin encore à parcourir !
Voici un aperçu des caractères autorisés actuellement : <http://faqfclphp.free.fr/#rub5.3>.
Et puis il y a aussi la possibilité de spécifier le sujet dans un lien mailto...
Ok, mais tu t'écartes de la question d'origine.
Nicolas Krebs
Olivier Miakinen écrivit dans l'article news:49478620$
Le 16/12/2008 10:45, Pierre Goiffon a écrit : >> >> Peu importe tant que les caractères codés sont tous dans us-ascii > > Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ? > Des caractères hors us-ascii ça doit être rare mais c'est possible, > non ? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
De façon expérimentale, peut-être. Si Nicolas Krebs passe dans le coin il nous redonnera sans doute les RFC (ou drafts) sur le sujet.
C'est effectivement expérimental (« Category: Experimental »). Voir mes articles news:476aab32$0$4120$ (Nicolas Krebs, « projets de norme de courrier electronique (decembre 2007) », news:fr.comp.mail , 2007-12-20, | http://www.ietf.org/html.charters/eai-charter.html | http://www.bortzmeyer.org/4952.html | http://tools.ietf.org/wg/eai/ et news:ga6lnh$9qr$ (Nicolas Krebs, « projets de norme de courrier electronique (decembre 2007) », news:fr.comp.mail , 2008-09-09, | Ça y est, c'est publié et officiel : | Groupe de travail de l'IETF « Email Address Internationalization » | http://www.ietf.org/html.charters/eai-charter.html | http://tools.ietf.org/wg/eai/ | Normes publiées : | - « RFC 4952, Overview and Framework for Internationalized Email », | urn:ietf:rfc:4952 http://tools.ietf.org/html/rfc4952 | - « RFC 5335, Internationalized Email Headers », urn:ietf:rfc:5335 | http://tools.ietf.org/html/rfc5335 | - « RFC 5336, SMTP extension for internationalized email address », | urn:ietf:rfc:5336 http://tools.ietf.org/html/rfc5336 | - « RFC 5337, Internationalized Delivery Status and Disposition | Notifications », urn:ietf:rfc:5337 http://tools.ietf.org/html/rfc5337 | | Articles : | - Stéphane Bortzmeyer, « RFC 4952: Overview and Framework for | Internationalized Email », bortzmeyer.org, 2007-07-25 et 2008-09-07, | http://www.bortzmeyer.org/4952.html | - Stéphane Bortzmeyer, « RFC 5335: Internationalized Email Headers », | bortzmeyer.org, 2008-09-07, http://www.bortzmeyer.org/5335.html | - Stéphane Bortzmeyer, « RFC 5336: SMTP extension for internationalized | email address », bortzmeyer.org, 2008-09-07, | http://www.bortzmeyer.org/5336.html | - Stéphane Bortzmeyer, « RFC 5337: Internationalized Delivery Status and | Disposition Notifications », bortzmeyer.org, 2008-09-07, | http://www.bortzmeyer.org/5337.html | - Stéphane Bortzmeyer, « Les normes du courrier électronique enfin | entièrement internationalisées », bortzmeyer.org, 2008-09-07, | http://www.bortzmeyer.org/courrier-entierement-internationalise.html | | Ne restent plus qu'une demie douzaine de domaines à compléter | (cf. http://tools.ietf.org/wg/eai/ ), puis traiter FTP, puis SMTP et
Dans la réalité, les caractères autorisés sont un sous-ensemble d'us-ascii. Quand on pense que même le caractère « + » est encore rejeté par la plupart des formulaires demandant une adresse de courriel, cela donne une bonne idée du chemin encore à parcourir !
Voici un aperçu des caractères autorisés actuellement : <http://faqfclphp.free.fr/#rub5.3>.
Voir aussi Stéphane Bortzmeyer, « Arrêter d'interdire des adresses de courrier légales », bortzmeyer.org, http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html .
> Et puis il y a aussi la possibilité de spécifier le sujet dans un lien > mailto...
Ok, mais tu t'écartes de la question d'origine.
(pour les uri mailto voir la RFC 2368, « The mailto URL scheme », urn:ietf:2368 , http://tools.ietf.org/html/rfc2368 , et les projets de rfc http://tools.ietf.org/html/draft-duerst-mailto-bis-05 et http://tools.ietf.org/html/draft-ietf-eai-mailto-00 )
Olivier Miakinen écrivit dans l'article news:49478620$1@neottia.net
Le 16/12/2008 10:45, Pierre Goiffon a écrit :
>>
>> Peu importe tant que les caractères codés sont tous dans us-ascii
>
> Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ?
> Des caractères hors us-ascii ça doit être rare mais c'est possible,
> non ? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
De façon expérimentale, peut-être. Si Nicolas Krebs passe dans le coin
il nous redonnera sans doute les RFC (ou drafts) sur le sujet.
C'est effectivement expérimental (« Category: Experimental »). Voir mes
articles news:476aab32$0$4120$79c14f64@nan-newsreader-07.noos.net (Nicolas
Krebs, « projets de norme de courrier electronique (decembre 2007) »,
news:fr.comp.mail , 2007-12-20,
| http://www.ietf.org/html.charters/eai-charter.html
| http://www.bortzmeyer.org/4952.html
| http://tools.ietf.org/wg/eai/
et news:ga6lnh$9qr$1@news.le-studio75.com (Nicolas Krebs, « projets de norme
de courrier electronique (decembre 2007) », news:fr.comp.mail , 2008-09-09,
| Ça y est, c'est publié et officiel :
| Groupe de travail de l'IETF « Email Address Internationalization »
| http://www.ietf.org/html.charters/eai-charter.html
| http://tools.ietf.org/wg/eai/
| Normes publiées :
| - « RFC 4952, Overview and Framework for Internationalized Email »,
| urn:ietf:rfc:4952 http://tools.ietf.org/html/rfc4952
| - « RFC 5335, Internationalized Email Headers », urn:ietf:rfc:5335
| http://tools.ietf.org/html/rfc5335
| - « RFC 5336, SMTP extension for internationalized email address »,
| urn:ietf:rfc:5336 http://tools.ietf.org/html/rfc5336
| - « RFC 5337, Internationalized Delivery Status and Disposition
| Notifications », urn:ietf:rfc:5337 http://tools.ietf.org/html/rfc5337
|
| Articles :
| - Stéphane Bortzmeyer, « RFC 4952: Overview and Framework for
| Internationalized Email », bortzmeyer.org, 2007-07-25 et 2008-09-07,
| http://www.bortzmeyer.org/4952.html
| - Stéphane Bortzmeyer, « RFC 5335: Internationalized Email Headers »,
| bortzmeyer.org, 2008-09-07, http://www.bortzmeyer.org/5335.html
| - Stéphane Bortzmeyer, « RFC 5336: SMTP extension for internationalized
| email address », bortzmeyer.org, 2008-09-07,
| http://www.bortzmeyer.org/5336.html
| - Stéphane Bortzmeyer, « RFC 5337: Internationalized Delivery Status and
| Disposition Notifications », bortzmeyer.org, 2008-09-07,
| http://www.bortzmeyer.org/5337.html
| - Stéphane Bortzmeyer, « Les normes du courrier électronique enfin
| entièrement internationalisées », bortzmeyer.org, 2008-09-07,
| http://www.bortzmeyer.org/courrier-entierement-internationalise.html
|
| Ne restent plus qu'une demie douzaine de domaines à compléter
| (cf. http://tools.ietf.org/wg/eai/ ), puis traiter FTP, puis SMTP et
Dans la
réalité, les caractères autorisés sont un sous-ensemble d'us-ascii.
Quand on pense que même le caractère « + » est encore rejeté par la
plupart des formulaires demandant une adresse de courriel, cela donne
une bonne idée du chemin encore à parcourir !
Voici un aperçu des caractères autorisés actuellement :
<http://faqfclphp.free.fr/#rub5.3>.
Voir aussi Stéphane Bortzmeyer, « Arrêter d'interdire des adresses de
courrier légales », bortzmeyer.org,
http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html .
> Et puis il y a aussi la possibilité de spécifier le sujet dans un lien
> mailto...
Ok, mais tu t'écartes de la question d'origine.
(pour les uri mailto voir la RFC 2368, « The mailto URL scheme »,
urn:ietf:2368 , http://tools.ietf.org/html/rfc2368 , et les projets de rfc
http://tools.ietf.org/html/draft-duerst-mailto-bis-05 et
http://tools.ietf.org/html/draft-ietf-eai-mailto-00 )
Olivier Miakinen écrivit dans l'article news:49478620$
Le 16/12/2008 10:45, Pierre Goiffon a écrit : >> >> Peu importe tant que les caractères codés sont tous dans us-ascii > > Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ? > Des caractères hors us-ascii ça doit être rare mais c'est possible, > non ? (c'est un peu anecdotique mais tant qu'à chercher un peu...)
De façon expérimentale, peut-être. Si Nicolas Krebs passe dans le coin il nous redonnera sans doute les RFC (ou drafts) sur le sujet.
C'est effectivement expérimental (« Category: Experimental »). Voir mes articles news:476aab32$0$4120$ (Nicolas Krebs, « projets de norme de courrier electronique (decembre 2007) », news:fr.comp.mail , 2007-12-20, | http://www.ietf.org/html.charters/eai-charter.html | http://www.bortzmeyer.org/4952.html | http://tools.ietf.org/wg/eai/ et news:ga6lnh$9qr$ (Nicolas Krebs, « projets de norme de courrier electronique (decembre 2007) », news:fr.comp.mail , 2008-09-09, | Ça y est, c'est publié et officiel : | Groupe de travail de l'IETF « Email Address Internationalization » | http://www.ietf.org/html.charters/eai-charter.html | http://tools.ietf.org/wg/eai/ | Normes publiées : | - « RFC 4952, Overview and Framework for Internationalized Email », | urn:ietf:rfc:4952 http://tools.ietf.org/html/rfc4952 | - « RFC 5335, Internationalized Email Headers », urn:ietf:rfc:5335 | http://tools.ietf.org/html/rfc5335 | - « RFC 5336, SMTP extension for internationalized email address », | urn:ietf:rfc:5336 http://tools.ietf.org/html/rfc5336 | - « RFC 5337, Internationalized Delivery Status and Disposition | Notifications », urn:ietf:rfc:5337 http://tools.ietf.org/html/rfc5337 | | Articles : | - Stéphane Bortzmeyer, « RFC 4952: Overview and Framework for | Internationalized Email », bortzmeyer.org, 2007-07-25 et 2008-09-07, | http://www.bortzmeyer.org/4952.html | - Stéphane Bortzmeyer, « RFC 5335: Internationalized Email Headers », | bortzmeyer.org, 2008-09-07, http://www.bortzmeyer.org/5335.html | - Stéphane Bortzmeyer, « RFC 5336: SMTP extension for internationalized | email address », bortzmeyer.org, 2008-09-07, | http://www.bortzmeyer.org/5336.html | - Stéphane Bortzmeyer, « RFC 5337: Internationalized Delivery Status and | Disposition Notifications », bortzmeyer.org, 2008-09-07, | http://www.bortzmeyer.org/5337.html | - Stéphane Bortzmeyer, « Les normes du courrier électronique enfin | entièrement internationalisées », bortzmeyer.org, 2008-09-07, | http://www.bortzmeyer.org/courrier-entierement-internationalise.html | | Ne restent plus qu'une demie douzaine de domaines à compléter | (cf. http://tools.ietf.org/wg/eai/ ), puis traiter FTP, puis SMTP et
Dans la réalité, les caractères autorisés sont un sous-ensemble d'us-ascii. Quand on pense que même le caractère « + » est encore rejeté par la plupart des formulaires demandant une adresse de courriel, cela donne une bonne idée du chemin encore à parcourir !
Voici un aperçu des caractères autorisés actuellement : <http://faqfclphp.free.fr/#rub5.3>.
Voir aussi Stéphane Bortzmeyer, « Arrêter d'interdire des adresses de courrier légales », bortzmeyer.org, http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html .
> Et puis il y a aussi la possibilité de spécifier le sujet dans un lien > mailto...
Ok, mais tu t'écartes de la question d'origine.
(pour les uri mailto voir la RFC 2368, « The mailto URL scheme », urn:ietf:2368 , http://tools.ietf.org/html/rfc2368 , et les projets de rfc http://tools.ietf.org/html/draft-duerst-mailto-bis-05 et http://tools.ietf.org/html/draft-ietf-eai-mailto-00 )
Patrick 'Zener' Brunet
Bonjour.
"siger" a écrit dans le message de news
Pour éviter les spams j'utilisais un tableau que j'avais trouvé sur le web, je remplaçais des lettres par une expression qui commençait par %, par exemple : %40f%72e%65%2E%66r pour @free.fr
Il y a tout de même un truc qui me chagrine: quelle que soit la complexité additionnelle pour faire correspondre ces codes au charset spécifié, ce n'est jamais qu'une transposition directe du texte original.
Il n'y a vraiment aucune robot collecteur qui soit capable d'interpréter ça ?
En fait j'ai vu des codages plus retors, qui ont tous le même objectif, avec des succès divers: faire en sorte que l'adresse email soit lisible humainement (visuellement), mais sans que le texte figure directement dans le code source, même à une transposition près. * Evidemment on renonce à faire ainsi un lien mailto: qui fonctionne. Le visiteur est invité à saisir l'adresse lui-même.
Sinon amha il n'est pas très complexe d'écrire un robot qui sache récupérer ce qui suit le mailto:.
Donc dans cette optique, on peut imaginer plusieurs stratégies plus ou moins tordues:
* Assembler l'adresse dynamiquement en Javascript et l'injecter en DHTML. - ce qui nécessite Javascript.
* Fournir l'adresse ou au moins le @ sous la forme d'une image, sans équivalement dans l'attribut alt bien entendu.
* Découper l'adresse en morceaux logés dans des tags HTML dispersés, et les repositionner en absolu par CSS.
* Fournir l'adresse d'un seul tenant, mais découpée en spans afin d'introduire des tags au milieu dans le code source.
* Variante: rajouter du texte parasite au milieu dans des spans avec display:none;
Tout ceci devrait rendre le décodage du code source par un robot beaucoup plus complexe (mais pas impossible), cependant au prix du sacrifice de certains points importants: - accessibilité (aux aveugles notamment), - nécessité de la CSS ou du Javascript selon le cas, avec des aléas de rendu.
L'avant-dernière solution me semble être la plus robuste, assez protectrice mais aussi relativement accessible en lecture vocale...
-- Cordialement.
* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com * E-mail: lien sur http://zener131.eu/ContactMe
Bonjour.
"siger" <guinness@hic.invalid> a écrit dans le message
de news Xns9B7565C63C624sigerfreefr@127.0.0.1
Pour éviter les spams j'utilisais un tableau que j'avais trouvé sur
le web, je remplaçais des lettres par une expression qui commençait
par %, par exemple : %40f%72e%65%2E%66r pour @free.fr
Il y a tout de même un truc qui me chagrine: quelle que soit la complexité
additionnelle pour faire correspondre ces codes au charset spécifié, ce
n'est jamais qu'une transposition directe du texte original.
Il n'y a vraiment aucune robot collecteur qui soit capable d'interpréter ça
?
En fait j'ai vu des codages plus retors, qui ont tous le même objectif, avec
des succès divers: faire en sorte que l'adresse email soit lisible
humainement (visuellement), mais sans que le texte figure directement dans
le code source, même à une transposition près.
* Evidemment on renonce à faire ainsi un lien mailto: qui fonctionne. Le
visiteur est invité à saisir l'adresse lui-même.
Sinon amha il n'est pas très complexe d'écrire un robot qui sache récupérer
ce qui suit le mailto:.
Donc dans cette optique, on peut imaginer plusieurs stratégies plus ou moins
tordues:
* Assembler l'adresse dynamiquement en Javascript et l'injecter en DHTML.
- ce qui nécessite Javascript.
* Fournir l'adresse ou au moins le @ sous la forme d'une image, sans
équivalement dans l'attribut alt bien entendu.
* Découper l'adresse en morceaux logés dans des tags HTML dispersés, et les
repositionner en absolu par CSS.
* Fournir l'adresse d'un seul tenant, mais découpée en spans afin
d'introduire des tags au milieu dans le code source.
* Variante: rajouter du texte parasite au milieu dans des spans avec
display:none;
Tout ceci devrait rendre le décodage du code source par un robot beaucoup
plus complexe (mais pas impossible), cependant au prix du sacrifice de
certains points importants:
- accessibilité (aux aveugles notamment),
- nécessité de la CSS ou du Javascript selon le cas, avec des aléas de
rendu.
L'avant-dernière solution me semble être la plus robuste, assez protectrice
mais aussi relativement accessible en lecture vocale...
--
Cordialement.
* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com
* E-mail: lien sur http://zener131.eu/ContactMe
Pour éviter les spams j'utilisais un tableau que j'avais trouvé sur le web, je remplaçais des lettres par une expression qui commençait par %, par exemple : %40f%72e%65%2E%66r pour @free.fr
Il y a tout de même un truc qui me chagrine: quelle que soit la complexité additionnelle pour faire correspondre ces codes au charset spécifié, ce n'est jamais qu'une transposition directe du texte original.
Il n'y a vraiment aucune robot collecteur qui soit capable d'interpréter ça ?
En fait j'ai vu des codages plus retors, qui ont tous le même objectif, avec des succès divers: faire en sorte que l'adresse email soit lisible humainement (visuellement), mais sans que le texte figure directement dans le code source, même à une transposition près. * Evidemment on renonce à faire ainsi un lien mailto: qui fonctionne. Le visiteur est invité à saisir l'adresse lui-même.
Sinon amha il n'est pas très complexe d'écrire un robot qui sache récupérer ce qui suit le mailto:.
Donc dans cette optique, on peut imaginer plusieurs stratégies plus ou moins tordues:
* Assembler l'adresse dynamiquement en Javascript et l'injecter en DHTML. - ce qui nécessite Javascript.
* Fournir l'adresse ou au moins le @ sous la forme d'une image, sans équivalement dans l'attribut alt bien entendu.
* Découper l'adresse en morceaux logés dans des tags HTML dispersés, et les repositionner en absolu par CSS.
* Fournir l'adresse d'un seul tenant, mais découpée en spans afin d'introduire des tags au milieu dans le code source.
* Variante: rajouter du texte parasite au milieu dans des spans avec display:none;
Tout ceci devrait rendre le décodage du code source par un robot beaucoup plus complexe (mais pas impossible), cependant au prix du sacrifice de certains points importants: - accessibilité (aux aveugles notamment), - nécessité de la CSS ou du Javascript selon le cas, avec des aléas de rendu.
L'avant-dernière solution me semble être la plus robuste, assez protectrice mais aussi relativement accessible en lecture vocale...
-- Cordialement.
* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com * E-mail: lien sur http://zener131.eu/ContactMe
Pierre Goiffon
Nicolas Krebs wrote:
Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ?
De façon expérimentale, peut-être. Si Nicolas Krebs passe dans le coin il nous redonnera sans doute les RFC (ou drafts) sur le sujet.
C'est effectivement expérimental
(...)
Merci Nicolas de tous ces pointeurs ! J'irai lire tout ça !
Nicolas Krebs wrote:
Si j'ai bonne mémoire on peut trouver tous les caractères avant le @ ?
De façon expérimentale, peut-être. Si Nicolas Krebs passe dans le coin
il nous redonnera sans doute les RFC (ou drafts) sur le sujet.
C'est effectivement expérimental
(...)
Merci Nicolas de tous ces pointeurs ! J'irai lire tout ça !
Et puis il y a aussi la possibilité de spécifier le sujet dans un lien mailto...
Ok, mais tu t'écartes de la question d'origine.
Je n'en parlais pas mais je ne l'excluais pas. Je viens de voir qu'il faut écrire en toutes lettres le sujet sinon il faut partie de l'adresse :
*******%2E%66%72?subject=subscribe
-- siger
SAM
Le 12/25/08 10:09 PM, siger a écrit :
Je viens de voir qu'il faut écrire en toutes lettres le sujet sinon il faut partie de l'adresse :
*******%2E%66%72?subject=subscribe
J'avais, à une époque, commis ceci : <http://pagesperso-orange.fr/stephane.moriaux/truc/mailto_texte_htm> (qui ne parle pas du codage de l'adresse e-mail)
Le 12/25/08 10:09 PM, siger a écrit :
Je viens de voir qu'il
faut écrire en toutes lettres le sujet sinon il faut partie de
l'adresse :
*******%2E%66%72?subject=subscribe
J'avais, à une époque, commis ceci :
<http://pagesperso-orange.fr/stephane.moriaux/truc/mailto_texte_htm>
(qui ne parle pas du codage de l'adresse e-mail)
Je viens de voir qu'il faut écrire en toutes lettres le sujet sinon il faut partie de l'adresse :
*******%2E%66%72?subject=subscribe
J'avais, à une époque, commis ceci : <http://pagesperso-orange.fr/stephane.moriaux/truc/mailto_texte_htm> (qui ne parle pas du codage de l'adresse e-mail)
