Et tant qu'on y est...
Quid de l'exemple en [Page 52] ?
Yes, Jim, I found it under "http://www.w3.org/Addressing/",
but you can probably pick it up from <ftp://foo.example.
com/rfc/>. Note the warning in <http://www.ics.uci.edu/pub/
ietf/uri/historical.html#WARNING>.
<https://www.ietf.org/rfc/rfc3986.txt>
Si l'interprétation est correcte, on devrait être informé que le
serveur <ftp.ics.uci.edu> n'existe pas.
Ce serait un peu maladroit de ne travailler qu'avec la place du mot dans la chaine d'origine, c'est sa recherche dans la chaine qu'il faudrait faire. -- Gilbert <https://maccafe-osx.pagesperso-orange.fr>
Le 19 octobre 2020 à 17:36, Jean-Pierre Kuypers a écrit :
Et cela va fonctionner aussi quand le champ Subject devient (par
exemple) ? :
Ce serait un peu maladroit de ne travailler qu'avec la place du mot dans la chaine d'origine, c'est sa recherche dans la chaine qu'il faudrait faire. -- Gilbert <https://maccafe-osx.pagesperso-orange.fr>
Gilbert OLIVIER
Le 19 octobre 2020 à 17:48, Fleuger a écrit :
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 partie "bleu" est le lien détecté par l'éditeur de 4D, il détecte une chaine qu'il considère comme une URL, je n'ai pas la main dessus. Pour les deux premières URL, la sélection (de l'URL entière bien sur) puis "Ouvrir URL" du menu contextuel corrige le contenu de la sélection en supprimant espaces et c/r. 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. -- Gilbert <https://maccafe-osx.pagesperso-orange.fr>
Le 19 octobre 2020 à 17:48, Fleuger a écrit :
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).
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 partie "bleu" est le lien détecté par l'éditeur de 4D, il détecte
une chaine qu'il considère comme une URL, je n'ai pas la main dessus.
Pour les deux premières URL, la sélection (de l'URL entière bien sur)
puis "Ouvrir URL" du menu contextuel corrige le contenu de la
sélection en supprimant espaces et c/r.
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.
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 partie "bleu" est le lien détecté par l'éditeur de 4D, il détecte une chaine qu'il considère comme une URL, je n'ai pas la main dessus. Pour les deux premières URL, la sélection (de l'URL entière bien sur) puis "Ouvrir URL" du menu contextuel corrige le contenu de la sélection en supprimant espaces et c/r. 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. -- Gilbert <https://maccafe-osx.pagesperso-orange.fr>
Fleuger
Le 19 octobre 2020 à 21:21, Gilbert OLIVIER a écrit ceci :
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 nuit porte conseil. Si tu arrives à corriger, ce sera tant mieux, mais à mon avis, rien ne presse car 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. Quand on prend une URL longue et quelle est collée dans l'éditeur de MacCafé, ça fonctionne correctement, avec ou sans chevrons. http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arriere-renault-super-5.html Tu avais raison en disant que cette adresse est "mal ficelée". 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. Nota : Mail non plus ne sais par traiter le lien, même en créant un lien hypertexte qui paraît correct mais n'ouvre que la première ligne. <https://www.dropbox.com/s/rpmg9ncssg38d1p/Snapshot%202020-10-20%20%C3%A0%2009.07.29.png?dl=0> -- Gérard FLEUROT
Le 19 octobre 2020 à 21:21, Gilbert OLIVIER a écrit ceci :
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 nuit porte conseil.
Si tu arrives à corriger, ce sera tant mieux, mais à mon avis, rien
ne presse car 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.
Quand on prend une URL longue et quelle est collée dans l'éditeur de
MacCafé, ça fonctionne correctement, avec ou sans chevrons.
Tu avais raison en disant que cette adresse est "mal ficelée".
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.
Nota : Mail non plus ne sais par traiter le lien, même en créant un
lien hypertexte qui paraît correct mais n'ouvre que la première ligne.
Le 19 octobre 2020 à 21:21, Gilbert OLIVIER a écrit ceci :
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 nuit porte conseil. Si tu arrives à corriger, ce sera tant mieux, mais à mon avis, rien ne presse car 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. Quand on prend une URL longue et quelle est collée dans l'éditeur de MacCafé, ça fonctionne correctement, avec ou sans chevrons. http://chris-pieces-auto-occaz.over-blog.com/2020/07/vitre-lunette-arriere-renault-super-5.html Tu avais raison en disant que cette adresse est "mal ficelée". 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. Nota : Mail non plus ne sais par traiter le lien, même en créant un lien hypertexte qui paraît correct mais n'ouvre que la première ligne. <https://www.dropbox.com/s/rpmg9ncssg38d1p/Snapshot%202020-10-20%20%C3%A0%2009.07.29.png?dl=0> -- Gérard FLEUROT
Jean-Pierre Kuypers
In article (Dans l'article) <rmm2em$qsf$, Fleuger wrote (écrivait) :
... 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.
Vraiment ? Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986 <https://tools.ietf.org/html/rfc3986#page-51>
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.
Tout cela est globalement considéré comme des "whitespaces", à négliger lors de l'extraction de l'URL.
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.
Toutafé ! Mais dans le présent cas, l'erreur n'est pas avérée. -- Jean-Pierre Kuypers Veuillez mettre les phrases dans leur con- texte avant de retourner sciemment.
In article (Dans l'article) <rmm2em$qsf$1@dont-email.me>, Fleuger
<g4fleurot@free.fr.invalid> wrote (écrivait) :
... 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.
Vraiment ?
Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986
<https://tools.ietf.org/html/rfc3986#page-51>
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.
Tout cela est globalement considéré comme des "whitespaces", à négliger
lors de l'extraction de l'URL.
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.
Toutafé !
Mais dans le présent cas, l'erreur n'est pas avérée.
--
Jean-Pierre Kuypers
Veuillez mettre les phrases dans leur con-
texte avant de retourner sciemment.
In article (Dans l'article) <rmm2em$qsf$, Fleuger wrote (écrivait) :
... 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.
Vraiment ? Les "line-breaks" sont pourtant explicitement prévus dans le RFC 3986 <https://tools.ietf.org/html/rfc3986#page-51>
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.
Tout cela est globalement considéré comme des "whitespaces", à négliger lors de l'extraction de l'URL.
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.
Toutafé ! Mais dans le présent cas, l'erreur n'est pas avérée. -- Jean-Pierre Kuypers Veuillez mettre les phrases dans leur con- texte avant de retourner sciemment.
Fleuger
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :
Vraiment ? 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) Parce que, à mon avis, un retour à la ligne dans une URL entre chevrons, c'est contradictoire. Mais alors, si c'est mentionné dans la RFC, je comprend ton intervention.
Toutafé ! Mais dans le présent cas, l'erreur n'est pas avérée.
Bien sur que si, puisque tu l'as signalée en ouverture de ce fil parce que tu savais qu'elle ne fonctionnait pas. -- Gérard FLEUROT
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :
Vraiment ?
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)
Parce que, à mon avis, un retour à la ligne dans une URL entre
chevrons, c'est contradictoire.
Mais alors, si c'est mentionné dans la RFC, je comprend ton
intervention.
Toutafé !
Mais dans le présent cas, l'erreur n'est pas avérée.
Bien sur que si, puisque tu l'as signalée en ouverture de ce fil
parce que tu savais qu'elle ne fonctionnait pas.
Le 20 octobre 2020 à 10:13, Jean-Pierre Kuypers a écrit ceci :
Vraiment ? 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) Parce que, à mon avis, un retour à la ligne dans une URL entre chevrons, c'est contradictoire. Mais alors, si c'est mentionné dans la RFC, je comprend ton intervention.
Toutafé ! Mais dans le présent cas, l'erreur n'est pas avérée.
Bien sur que si, puisque tu l'as signalée en ouverture de ce fil parce que tu savais qu'elle ne fonctionnait pas. -- Gérard FLEUROT
Jean-Pierre Kuypers
In article (Dans l'article) <rmmci1$qud$, Fleuger wrote (écrivait) :
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.
----- -- Jean-Pierre Kuypers Veuillez encadrer les phrases dans leur con- texte avant de placer sciemment.
In article (Dans l'article) <rmmci1$qud$1@dont-email.me>, Fleuger
<g4fleurot@free.fr.invalid> wrote (écrivait) :
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.
-----
--
Jean-Pierre Kuypers
Veuillez encadrer les phrases dans leur con-
texte avant de placer sciemment.
In article (Dans l'article) <rmmci1$qud$, Fleuger wrote (écrivait) :
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.
----- -- Jean-Pierre Kuypers Veuillez encadrer les phrases dans leur con- texte avant de placer sciemment.
Fleuger
Le 20 octobre 2020 à 12:30, Jean-Pierre Kuypers a écrit ceci :
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.
-----
OK ! Merci pour toutes ces explications. J'avais cherché "chevrons" au lieu de "angle brackets". Je sors : ma culture est ridicule par rapport à la tienne dans ce domaine. Et face à la loi, le bon sens ne suffit pas. -- Gérard FLEUROT
Le 20 octobre 2020 à 12:30, Jean-Pierre Kuypers a écrit ceci :
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.
-----
OK ! Merci pour toutes ces explications. J'avais cherché "chevrons"
au lieu de "angle brackets".
Je sors : ma culture est ridicule par rapport à la tienne dans ce
domaine. Et face à la loi, le bon sens ne suffit pas.
--
Gérard FLEUROT
Le 20 octobre 2020 à 12:30, Jean-Pierre Kuypers a écrit ceci :
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.
-----
OK ! Merci pour toutes ces explications. J'avais cherché "chevrons" au lieu de "angle brackets". Je sors : ma culture est ridicule par rapport à la tienne dans ce domaine. Et face à la loi, le bon sens ne suffit pas. -- Gérard FLEUROT
