Et cela va fonctionner aussi quand le champ Subject devient (par
exemple) ? :
Re: correction du sujet (fut: [MacCafé] URL long)
Et cela va fonctionner aussi quand le champ Subject devient (par
exemple) ? :
Re: correction du sujet (fut: [MacCafé] URL long)
Et cela va fonctionner aussi quand le champ Subject devient (par
exemple) ? :
Re: correction du sujet (fut: [MacCafé] URL long)
Le 19 octobre 2020 à 17:11, Gilbert OLIVIER a écrit ceci :Si je comprends bien, un tu cherches comment coller un lien mal
"ficelé" mais que tu peux ouvrir avec MacCafé en un lien correct dans
un nouveau message.
Non, je cherche à démontrer que le lien est "bien ficelé" puisqu'il
présente un caractère CR en fin de la première ligne, mais que
MacCafé interprète ce caractère comme une espace.La solution dans ce cas, tu ouvres le lien à partir du message en
lecture, dans le navigateur tu copies le contenu du champ de l'URL et
tu le colle dans le nouveau message.
Oui, OK : comme cela ça marche.
Mais comment avoir le le bon lien si MacCafé ne l'ouvre pas ?
Je copie la partie entre chevrons
http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arri
ere-renault-super-5.html
et je la colle dans la barre d'adresse du navigateur, mais avant
d'appuyer sur envoi, je supprime l'espace entre le i et le e de
arrière, et comme cela, ça marche.
Je copie dans MacCafé le lien de JPK dans son message initiale et je
le colle ici.
<http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arri
ere-renault-super-5.html>
Il est identique au message initial et il n'ouvre pas la bonne page.
Pour qu'il soit bon, il faut placer le curseur au début de la seconde
ligne et appuyer sur la touche d'effacement pour que le lien se
reconstitue correctement. (en modifiant l'emplacement de la coupure).
<http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arriere-renault-super-5.html>
Et cette manipulation n'est pas possible en mode lecture pour ouvrir
le lien. (et c'est normal puisqu'on est en mode lecture).
Il faudrait que MacCafé sache interpréter ce caractère lorsqu'il est
présent dans une URL longue. Ou alors le supprimer.
Le 19 octobre 2020 à 17:11, Gilbert OLIVIER a écrit ceci :
Si je comprends bien, un tu cherches comment coller un lien mal
"ficelé" mais que tu peux ouvrir avec MacCafé en un lien correct dans
un nouveau message.
Non, je cherche à démontrer que le lien est "bien ficelé" puisqu'il
présente un caractère CR en fin de la première ligne, mais que
MacCafé interprète ce caractère comme une espace.
La solution dans ce cas, tu ouvres le lien à partir du message en
lecture, dans le navigateur tu copies le contenu du champ de l'URL et
tu le colle dans le nouveau message.
Oui, OK : comme cela ça marche.
Mais comment avoir le le bon lien si MacCafé ne l'ouvre pas ?
Je copie la partie entre chevrons
http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arri
ere-renault-super-5.html
et je la colle dans la barre d'adresse du navigateur, mais avant
d'appuyer sur envoi, je supprime l'espace entre le i et le e de
arrière, et comme cela, ça marche.
Je copie dans MacCafé le lien de JPK dans son message initiale et je
le colle ici.
<http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arri
ere-renault-super-5.html>
Il est identique au message initial et il n'ouvre pas la bonne page.
Pour qu'il soit bon, il faut placer le curseur au début de la seconde
ligne et appuyer sur la touche d'effacement pour que le lien se
reconstitue correctement. (en modifiant l'emplacement de la coupure).
<http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arriere-renault-super-5.html>
Et cette manipulation n'est pas possible en mode lecture pour ouvrir
le lien. (et c'est normal puisqu'on est en mode lecture).
Il faudrait que MacCafé sache interpréter ce caractère lorsqu'il est
présent dans une URL longue. Ou alors le supprimer.
Le 19 octobre 2020 à 17:11, Gilbert OLIVIER a écrit ceci :Si je comprends bien, un tu cherches comment coller un lien mal
"ficelé" mais que tu peux ouvrir avec MacCafé en un lien correct dans
un nouveau message.
Non, je cherche à démontrer que le lien est "bien ficelé" puisqu'il
présente un caractère CR en fin de la première ligne, mais que
MacCafé interprète ce caractère comme une espace.La solution dans ce cas, tu ouvres le lien à partir du message en
lecture, dans le navigateur tu copies le contenu du champ de l'URL et
tu le colle dans le nouveau message.
Oui, OK : comme cela ça marche.
Mais comment avoir le le bon lien si MacCafé ne l'ouvre pas ?
Je copie la partie entre chevrons
http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arri
ere-renault-super-5.html
et je la colle dans la barre d'adresse du navigateur, mais avant
d'appuyer sur envoi, je supprime l'espace entre le i et le e de
arrière, et comme cela, ça marche.
Je copie dans MacCafé le lien de JPK dans son message initiale et je
le colle ici.
<http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arri
ere-renault-super-5.html>
Il est identique au message initial et il n'ouvre pas la bonne page.
Pour qu'il soit bon, il faut placer le curseur au début de la seconde
ligne et appuyer sur la touche d'effacement pour que le lien se
reconstitue correctement. (en modifiant l'emplacement de la coupure).
<http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arriere-renault-super-5.html>
Et cette manipulation n'est pas possible en mode lecture pour ouvrir
le lien. (et c'est normal puisqu'on est en mode lecture).
Il faudrait que MacCafé sache interpréter ce caractère lorsqu'il est
présent dans une URL longue. Ou alors le supprimer.
La solution est de corriger le texte des URL à l'affichage plutôt que
de travailler au niveau de la détection de l'URL à l'ouverture* du
menu contextuel, de façon à ce que la détection de l'éditeur (qui
gère la coloration en bleu) présente lui aussi l'URL entière.
(*): c'est au moment du clic contextuel que l'application essaie de
détecter si la chaine sous la souris est une URL, un M-ID, ou une
adresse courrier.
La solution est de corriger le texte des URL à l'affichage plutôt que
de travailler au niveau de la détection de l'URL à l'ouverture* du
menu contextuel, de façon à ce que la détection de l'éditeur (qui
gère la coloration en bleu) présente lui aussi l'URL entière.
(*): c'est au moment du clic contextuel que l'application essaie de
détecter si la chaine sous la souris est une URL, un M-ID, ou une
adresse courrier.
La solution est de corriger le texte des URL à l'affichage plutôt que
de travailler au niveau de la détection de l'URL à l'ouverture* du
menu contextuel, de façon à ce que la détection de l'éditeur (qui
gère la coloration en bleu) présente lui aussi l'URL entière.
(*): c'est au moment du clic contextuel que l'application essaie de
détecter si la chaine sous la souris est une URL, un M-ID, ou une
adresse courrier.
... ce n'est pas normal de trouver un caractère CR dans une URL
entourée de chevrons.
À mon avis, c'est même contradictoire.
Et, dans la construction de cette URL, il y a confusion quelque part
entre "mise à la ligne" du traitement de texte et "retour à la ligne"
qui résulte soit de la volonté de l'opérateur ou alors d'un défaut du
logiciel qui crée l'adresse.
Et si l'emetteur du message souhaite être compris, il doit faire
l'effort de proposer une URL conforme, plutôt que de demander à un
logiciel de décrypter l'erreur.
... ce n'est pas normal de trouver un caractère CR dans une URL
entourée de chevrons.
À mon avis, c'est même contradictoire.
Et, dans la construction de cette URL, il y a confusion quelque part
entre "mise à la ligne" du traitement de texte et "retour à la ligne"
qui résulte soit de la volonté de l'opérateur ou alors d'un défaut du
logiciel qui crée l'adresse.
Et si l'emetteur du message souhaite être compris, il doit faire
l'effort de proposer une URL conforme, plutôt que de demander à un
logiciel de décrypter l'erreur.
... ce n'est pas normal de trouver un caractère CR dans une URL
entourée de chevrons.
À mon avis, c'est même contradictoire.
Et, dans la construction de cette URL, il y a confusion quelque part
entre "mise à la ligne" du traitement de texte et "retour à la ligne"
qui résulte soit de la volonté de l'opérateur ou alors d'un défaut du
logiciel qui crée l'adresse.
Et si l'emetteur du message souhaite être compris, il doit faire
l'effort de proposer une URL conforme, plutôt que de demander à un
logiciel de décrypter l'erreur.
Vraiment ?
Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
Toutafé !
Mais dans le présent cas, l'erreur n'est pas avérée.
Vraiment ?
Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
Toutafé !
Mais dans le présent cas, l'erreur n'est pas avérée.
Vraiment ?
Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
Toutafé !
Mais dans le présent cas, l'erreur n'est pas avérée.
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
January 2005
Est-ce qu'à cette date les chevrons avaient été mis en place pour
encadrer les URL longues ? (je n'ai pas trouvé chevrons dans la page,
ni dans les updates)
In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified.
Parce que, à mon avis, un retour à la ligne dans une URL entre
chevrons, c'est contradictoire.
In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
need to be added to break long URLs across lines. The whitespace
should be ignored when extracting the URL.
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :
> Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
> <https://tools.ietf.org/html/rfc3986#page-51>
January 2005
Est-ce qu'à cette date les chevrons avaient été mis en place pour
encadrer les URL longues ? (je n'ai pas trouvé chevrons dans la page,
ni dans les updates)
In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified.
Parce que, à mon avis, un retour à la ligne dans une URL entre
chevrons, c'est contradictoire.
In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
need to be added to break long URLs across lines. The whitespace
should be ignored when extracting the URL.
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
January 2005
Est-ce qu'à cette date les chevrons avaient été mis en place pour
encadrer les URL longues ? (je n'ai pas trouvé chevrons dans la page,
ni dans les updates)
In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified.
Parce que, à mon avis, un retour à la ligne dans une URL entre
chevrons, c'est contradictoire.
In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
need to be added to break long URLs across lines. The whitespace
should be ignored when extracting the URL.
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
January 2005
Est-ce qu'à cette date les chevrons avaient été mis en place pour
encadrer les URL longues ? (je n'ai pas trouvé chevrons dans la page,
ni dans les updates)
Les chevrons sont mentionnés explicitement en fin de page 51 et au 4e
paragraphe de la page 52.
En décembre 1994, le 1er RFC sur ce sujet "Uniform Resource Locators
(URL)"
<https://tools.ietf.org/html/rfc1738>,
les chevrons sont déjà mentionnés explicitement en page 21 :
-----In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified.
-----Parce que, à mon avis, un retour à la ligne dans une URL entre
chevrons, c'est contradictoire.
Qu'est-ce que nous pouvons savoir des multiples possibilités de trouver
un URL dans un document transféré sur l'Internet ?
Et l'URL précité prévoit explicitement la possibilité de trouver des
mises à la ligne dans un URL.
-----In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
need to be added to break long URLs across lines. The whitespace
should be ignored when extracting the URL.
-----
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :
Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
January 2005
Est-ce qu'à cette date les chevrons avaient été mis en place pour
encadrer les URL longues ? (je n'ai pas trouvé chevrons dans la page,
ni dans les updates)
Les chevrons sont mentionnés explicitement en fin de page 51 et au 4e
paragraphe de la page 52.
En décembre 1994, le 1er RFC sur ce sujet "Uniform Resource Locators
(URL)"
<https://tools.ietf.org/html/rfc1738>,
les chevrons sont déjà mentionnés explicitement en page 21 :
-----
In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified.
-----
Parce que, à mon avis, un retour à la ligne dans une URL entre
chevrons, c'est contradictoire.
Qu'est-ce que nous pouvons savoir des multiples possibilités de trouver
un URL dans un document transféré sur l'Internet ?
Et l'URL précité prévoit explicitement la possibilité de trouver des
mises à la ligne dans un URL.
-----
In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
need to be added to break long URLs across lines. The whitespace
should be ignored when extracting the URL.
-----
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
January 2005
Est-ce qu'à cette date les chevrons avaient été mis en place pour
encadrer les URL longues ? (je n'ai pas trouvé chevrons dans la page,
ni dans les updates)
Les chevrons sont mentionnés explicitement en fin de page 51 et au 4e
paragraphe de la page 52.
En décembre 1994, le 1er RFC sur ce sujet "Uniform Resource Locators
(URL)"
<https://tools.ietf.org/html/rfc1738>,
les chevrons sont déjà mentionnés explicitement en page 21 :
-----In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified.
-----Parce que, à mon avis, un retour à la ligne dans une URL entre
chevrons, c'est contradictoire.
Qu'est-ce que nous pouvons savoir des multiples possibilités de trouver
un URL dans un document transféré sur l'Internet ?
Et l'URL précité prévoit explicitement la possibilité de trouver des
mises à la ligne dans un URL.
-----In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
need to be added to break long URLs across lines. The whitespace
should be ignored when extracting the URL.
-----