À mon avis, ce n'est pas irrémédiable. Puisque MacCafé est déjÍ capable d'interroger le serveur pour retrouver le message qui a précédé un FU2, il devrait pourvoir en faire autant pour n'importe quel M-ID. Qu'en penses-tu, Gilbert ?
Que c'est peut-être encore une ligne Í la todo-list ;-))
Ils sont épuisants, ces testeurs, hein ? ;-)
Et la limite est comme pour le cas du Followup-To, la rétention du serveur.
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un serveur offrant une longue durée de rétention. -- Denis
Gilbert OLIVIER a écrit ceci :
Le 12 décembre 2020 Í 11:07, DV a écrit :
À mon avis, ce n'est pas irrémédiable. Puisque MacCafé est déjÍ capable
d'interroger le serveur pour retrouver le message qui a précédé un
FU2, il devrait pourvoir en faire autant pour n'importe quel M-ID.
Qu'en penses-tu, Gilbert ?
Que c'est peut-être encore une ligne Í la todo-list ;-))
Ils sont épuisants, ces testeurs, hein ? ;-)
Et la limite est comme pour le cas du Followup-To, la rétention du
serveur.
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un
serveur offrant une longue durée de rétention.
À mon avis, ce n'est pas irrémédiable. Puisque MacCafé est déjÍ capable d'interroger le serveur pour retrouver le message qui a précédé un FU2, il devrait pourvoir en faire autant pour n'importe quel M-ID. Qu'en penses-tu, Gilbert ?
Que c'est peut-être encore une ligne Í la todo-list ;-))
Ils sont épuisants, ces testeurs, hein ? ;-)
Et la limite est comme pour le cas du Followup-To, la rétention du serveur.
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un serveur offrant une longue durée de rétention. -- Denis
Jean-Pierre Kuypers
In article (Dans l'article) <rr2dsp$3n9$, Gilbert OLIVIER wrote (écrivait)Â :
Le 12 décembre 2020 Í 10:37, DV a écrit :
En l'absence de chevrons ou d'espace avant la parenthèse fermante, cette dernière est considérée par MacCafé comme faisant partie de l'URL
Moi-même je me fais souvent attraper quand je clique sur ces URL non chevronnés et suivis d'un caractère tel que parenthèse, point, virgule, etc. Et je rÍ¢le alors d'arriver sur une page "404 Not Found". Cela démontre encore - pour autant qu'il le faille - l'utilité des chevrons, tels que recommandés fortement dans le RFC 3986 <https://tools.ietf.org/html/rfc3986>
MesNews et Thunderbird ne se laissent pas prendre Í ce piège et ne soulignent que https://www.big-8.org/ , sans inclure la parenthèse.
AKE très forts sur ce coup-lÍ ils sont.
Note que l'on rencontrerait le même problème si, dans la phrase ci-dessus, je n'avais pas saisi d'espace entre l'URL et la virgule : celle-ci se serait retrouvée incluse dans l'URL.
Même la détection d'URL de 4D se fait avoir.
Le RFC sus-cité propose l'expression rationnelle ci-dessous pour découper en ses composants, un URL correctement formé : ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(?([^#]*))?(#(.*))? <https://tools.ietf.org/html/rfc3986#page-50>
La seule chose que l'on puisse filtrer comme caractère faisant office de fin d'URL sans qu'elle soit encadrée est un caractère interdit dans une URL. Et la parenthèse ne semble pas en faire partie.
Et d'autres caractères non plus. La partie droite de l'URL - i.e. Í droite du caractère deux points - dépendant de la méthode - i.e. Í gauche du caractère deux points - on peut s'attendre Í bien des choses. <https://tools.ietf.org/html/rfc3986#page-7> -- Jean-Pierre Kuypers Veuillez encadrer les phrases dans leur con- texte avant de filtrer sciemment.
In article (Dans l'article) <rr2dsp$3n9$2@shakotay.alphanet.ch>,
Gilbert OLIVIER <gilbert.olivier@orange.fr> wrote (écrivait)Â :
Le 12 décembre 2020 Í 10:37, DV a écrit :
> En l'absence de chevrons ou d'espace avant la parenthèse fermante, cette
> dernière est considérée par MacCafé comme faisant partie de l'URL
Moi-même je me fais souvent attraper quand je clique sur ces URL non
chevronnés et suivis d'un caractère tel que parenthèse, point, virgule,
etc. Et je r͢le alors d'arriver sur une page "404 Not Found".
Cela démontre encore - pour autant qu'il le faille - l'utilité des
chevrons, tels que recommandés fortement dans le RFC 3986
<https://tools.ietf.org/html/rfc3986>
> MesNews et Thunderbird ne se laissent pas prendre Í ce piège et ne
> soulignent que https://www.big-8.org/ , sans inclure la parenthèse.
AKE très forts sur ce coup-lÍ ils sont.
> Note que l'on rencontrerait le même problème si, dans la phrase
> ci-dessus, je n'avais pas saisi d'espace entre l'URL et la virgule :
> celle-ci se serait retrouvée incluse dans l'URL.
>
Même la détection d'URL de 4D se fait avoir.
Le RFC sus-cité propose l'expression rationnelle ci-dessous pour
découper en ses composants, un URL correctement formé :
La seule chose que l'on puisse filtrer comme caractère faisant office de
fin d'URL sans qu'elle soit encadrée est un caractère interdit dans
une URL. Et la parenthèse ne semble pas en faire partie.
Et d'autres caractères non plus.
La partie droite de l'URL - i.e. Í droite du caractère deux points -
dépendant de la méthode - i.e. Í gauche du caractère deux points - on
peut s'attendre Í bien des choses.
<https://tools.ietf.org/html/rfc3986#page-7>
--
Jean-Pierre Kuypers
Veuillez encadrer les phrases dans leur con-
texte avant de filtrer sciemment.
In article (Dans l'article) <rr2dsp$3n9$, Gilbert OLIVIER wrote (écrivait)Â :
Le 12 décembre 2020 Í 10:37, DV a écrit :
En l'absence de chevrons ou d'espace avant la parenthèse fermante, cette dernière est considérée par MacCafé comme faisant partie de l'URL
Moi-même je me fais souvent attraper quand je clique sur ces URL non chevronnés et suivis d'un caractère tel que parenthèse, point, virgule, etc. Et je rÍ¢le alors d'arriver sur une page "404 Not Found". Cela démontre encore - pour autant qu'il le faille - l'utilité des chevrons, tels que recommandés fortement dans le RFC 3986 <https://tools.ietf.org/html/rfc3986>
MesNews et Thunderbird ne se laissent pas prendre Í ce piège et ne soulignent que https://www.big-8.org/ , sans inclure la parenthèse.
AKE très forts sur ce coup-lÍ ils sont.
Note que l'on rencontrerait le même problème si, dans la phrase ci-dessus, je n'avais pas saisi d'espace entre l'URL et la virgule : celle-ci se serait retrouvée incluse dans l'URL.
Même la détection d'URL de 4D se fait avoir.
Le RFC sus-cité propose l'expression rationnelle ci-dessous pour découper en ses composants, un URL correctement formé : ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(?([^#]*))?(#(.*))? <https://tools.ietf.org/html/rfc3986#page-50>
La seule chose que l'on puisse filtrer comme caractère faisant office de fin d'URL sans qu'elle soit encadrée est un caractère interdit dans une URL. Et la parenthèse ne semble pas en faire partie.
Et d'autres caractères non plus. La partie droite de l'URL - i.e. Í droite du caractère deux points - dépendant de la méthode - i.e. Í gauche du caractère deux points - on peut s'attendre Í bien des choses. <https://tools.ietf.org/html/rfc3986#page-7> -- Jean-Pierre Kuypers Veuillez encadrer les phrases dans leur con- texte avant de filtrer sciemment.
Jean-Pierre Kuypers
In article (Dans l'article) <1p1b1p8.12rmh9s1rahygiN%, MV wrote (écrivait)Â :
Jean-Pierre Kuypers wrote:
MacSOUP a-t-il aussi cette limitation ?
MacSOUP ne sait pas quoi faire avec <rr21qh$ck4$ et donc il ne fait rien et ne propose rien !
Merci d'avoir testé. Du coup j'ai ressorti mon vieux MacSOUP Settings et testé moi aussi. Un Cmd-clic qque part entre les chevrons me signale que «Â MT-NewsWatcher needs Open Transport to run. You probably need to upgrade your System software. » Bienvenue dans le futur du millénaire pasé... Par contre un Cmd-clic qque part dans http://michelvauquois.fr m'ouvre bien la page idoine. -- Jean-Pierre Kuypers Veuillez proposer les phrases dans leur con- texte avant de savoir sciemment.
In article (Dans l'article)
<1p1b1p8.12rmh9s1rahygiN%mv@gmail.com.invalid>, MV
<mv@gmail.com.invalid> wrote (écrivait)Â :
Jean-Pierre Kuypers <Kuypers@address.invalid> wrote:
> MacSOUP a-t-il aussi cette limitation ?
MacSOUP ne sait pas quoi faire avec <rr21qh$ck4$1@dont-email.me> et donc
il ne fait rien et ne propose rien !
Merci d'avoir testé.
Du coup j'ai ressorti mon vieux MacSOUP Settings et testé moi aussi.
Un Cmd-clic qque part entre les chevrons me signale que
«Â MT-NewsWatcher needs Open Transport to run. You probably need to
upgrade your System software. »
Bienvenue dans le futur du millénaire pasé...
Par contre un Cmd-clic qque part dans http://michelvauquois.fr m'ouvre
bien la page idoine.
--
Jean-Pierre Kuypers
Veuillez proposer les phrases dans leur con-
texte avant de savoir sciemment.
In article (Dans l'article) <1p1b1p8.12rmh9s1rahygiN%, MV wrote (écrivait)Â :
Jean-Pierre Kuypers wrote:
MacSOUP a-t-il aussi cette limitation ?
MacSOUP ne sait pas quoi faire avec <rr21qh$ck4$ et donc il ne fait rien et ne propose rien !
Merci d'avoir testé. Du coup j'ai ressorti mon vieux MacSOUP Settings et testé moi aussi. Un Cmd-clic qque part entre les chevrons me signale que «Â MT-NewsWatcher needs Open Transport to run. You probably need to upgrade your System software. » Bienvenue dans le futur du millénaire pasé... Par contre un Cmd-clic qque part dans http://michelvauquois.fr m'ouvre bien la page idoine. -- Jean-Pierre Kuypers Veuillez proposer les phrases dans leur con- texte avant de savoir sciemment.
Gilbert OLIVIER
Le 12 décembre 2020 Í 14:09, DV a écrit :
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un serveur offrant une longue durée de rétention.
Mais tel quel pour ce qui est de la recherche du message d'origine d'un Followup-To dans MacCafé, le serveur utilisé est celui du profil actif. Il faudrait réécrire la commande pour faire l'inventaire des serveurs (plusieurs profils pouvant avoir le même serveur) et tenter la relève sur la liste jusqu'Í une éventuelle réussite. -- Gilbert <https://maccafe-osx.pagesperso-orange.fr>
Le 12 décembre 2020 Í 14:09, DV a écrit :
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un
serveur offrant une longue durée de rétention.
Mais tel quel pour ce qui est de la recherche du message d'origine d'un
Followup-To dans MacCafé, le serveur utilisé est celui du profil actif.
Il faudrait réécrire la commande pour faire l'inventaire des serveurs
(plusieurs profils pouvant avoir le même serveur) et tenter la relève
sur la liste jusqu'Í une éventuelle réussite.
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un serveur offrant une longue durée de rétention.
Mais tel quel pour ce qui est de la recherche du message d'origine d'un Followup-To dans MacCafé, le serveur utilisé est celui du profil actif. Il faudrait réécrire la commande pour faire l'inventaire des serveurs (plusieurs profils pouvant avoir le même serveur) et tenter la relève sur la liste jusqu'Í une éventuelle réussite. -- Gilbert <https://maccafe-osx.pagesperso-orange.fr>
DV
Gilbert OLIVIER a écrit ceci :
Le 12 décembre 2020 Í 14:09, DV a écrit :
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un serveur offrant une longue durée de rétention.
Mais tel quel pour ce qui est de la recherche du message d'origine d'un Followup-To dans MacCafé, le serveur utilisé est celui du profil actif.
Certes, mais si la recherche ne donne rien, je peux basculer sur mon profil d'archivage (avec ses cinq ans de rétention) et recommencer.
Il faudrait réécrire la commande pour faire l'inventaire des serveurs (plusieurs profils pouvant avoir le même serveur) et tenter la relève sur la liste jusqu'Í une éventuelle réussite.
C'est sͻr, ce serait encore mieux. -- Denis
Gilbert OLIVIER a écrit ceci :
Le 12 décembre 2020 Í 14:09, DV a écrit :
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un
serveur offrant une longue durée de rétention.
Mais tel quel pour ce qui est de la recherche du message d'origine d'un
Followup-To dans MacCafé, le serveur utilisé est celui du profil actif.
Certes, mais si la recherche ne donne rien, je peux basculer sur mon
profil d'archivage (avec ses cinq ans de rétention) et recommencer.
Il faudrait réécrire la commande pour faire l'inventaire des serveurs
(plusieurs profils pouvant avoir le même serveur) et tenter la relève
sur la liste jusqu'Í une éventuelle réussite.
Tout Í fait. D'o͹ l'intérêt de se créer au moins un profil Í partir d'un serveur offrant une longue durée de rétention.
Mais tel quel pour ce qui est de la recherche du message d'origine d'un Followup-To dans MacCafé, le serveur utilisé est celui du profil actif.
Certes, mais si la recherche ne donne rien, je peux basculer sur mon profil d'archivage (avec ses cinq ans de rétention) et recommencer.
Il faudrait réécrire la commande pour faire l'inventaire des serveurs (plusieurs profils pouvant avoir le même serveur) et tenter la relève sur la liste jusqu'Í une éventuelle réussite.
C'est sͻr, ce serait encore mieux. -- Denis
DV
Jean-Pierre Kuypers a écrit ceci :
Il y a moyen de modifier cette relation URI - application, mais je ne sais plus o͹ dans le Système.
Je fais ça avec SwiftDefaultApps : <https://github.com/Lord-Kamina/SwiftDefaultApps> mais concernant les URI news, ça n'a guère d'utilité, car les lecteurs de news que je connais (MacSOUP compris) ne savent qu'en faire.
Par ailleurs, la partie Í gauche du deux-points d'un URI, "scheme" en anglais, n'a rien d'un "schéma", figure donnant une représentation simplifiée et fonctionnelle. Mais ce faux-ami n'est pas rare, hélas ! <https://fr.wikipedia.org/wiki/Discussion:Uniform_Resource_Locator#schém a_vs._scheme>
C'est bien beau de dire que le vocable est inapproprié, mais si on n'en propose pas d'autre, on n'est guère avancé. Wikipédia non plus, d'ailleurs : <https://fr.wikipedia.org/wiki/Schéma_d'URI> Pour en revenir aux URL récalcitrantes, MacCafé refuse d'ouvrir celle que tu as donnée ci-dessus. Je subodore que c'est Í cause du «Â # » qui définit une ancre dans la page, et si c'est le cas, c'est vraiment gênant. -- Denis
Jean-Pierre Kuypers a écrit ceci :
Il y a moyen de modifier cette relation URI - application, mais je ne
sais plus o͹ dans le Système.
Je fais ça avec SwiftDefaultApps :
<https://github.com/Lord-Kamina/SwiftDefaultApps>
mais concernant les URI news, ça n'a guère d'utilité, car les lecteurs
de news que je connais (MacSOUP compris) ne savent qu'en faire.
Par ailleurs, la partie Í gauche du deux-points d'un URI, "scheme" en
anglais, n'a rien d'un "schéma", figure donnant une représentation
simplifiée et fonctionnelle. Mais ce faux-ami n'est pas rare, hélas !
C'est bien beau de dire que le vocable est inapproprié, mais si on n'en
propose pas d'autre, on n'est guère avancé. Wikipédia non plus,
d'ailleurs :
<https://fr.wikipedia.org/wiki/Schéma_d'URI>
Pour en revenir aux URL récalcitrantes, MacCafé refuse d'ouvrir celle
que tu as donnée ci-dessus. Je subodore que c'est Í cause du «Â #Â »
qui définit une ancre dans la page, et si c'est le cas, c'est
vraiment gênant.
Il y a moyen de modifier cette relation URI - application, mais je ne sais plus o͹ dans le Système.
Je fais ça avec SwiftDefaultApps : <https://github.com/Lord-Kamina/SwiftDefaultApps> mais concernant les URI news, ça n'a guère d'utilité, car les lecteurs de news que je connais (MacSOUP compris) ne savent qu'en faire.
Par ailleurs, la partie Í gauche du deux-points d'un URI, "scheme" en anglais, n'a rien d'un "schéma", figure donnant une représentation simplifiée et fonctionnelle. Mais ce faux-ami n'est pas rare, hélas ! <https://fr.wikipedia.org/wiki/Discussion:Uniform_Resource_Locator#schém a_vs._scheme>
C'est bien beau de dire que le vocable est inapproprié, mais si on n'en propose pas d'autre, on n'est guère avancé. Wikipédia non plus, d'ailleurs : <https://fr.wikipedia.org/wiki/Schéma_d'URI> Pour en revenir aux URL récalcitrantes, MacCafé refuse d'ouvrir celle que tu as donnée ci-dessus. Je subodore que c'est Í cause du «Â # » qui définit une ancre dans la page, et si c'est le cas, c'est vraiment gênant. -- Denis
Jean-Pierre Kuypers
In article (Dans l'article) <rr2ur2$bdn$, DV wrote (écrivait)Â :
... SwiftDefaultApps :
Merci.
Par ailleurs, la partie Í gauche du deux-points d'un URI, "scheme" en anglais, n'a rien d'un "schéma"
C'est bien beau de dire que le vocable est inapproprié, mais si on n'en propose pas d'autre, on n'est guère avancé. Wikipédia non plus, d'ailleurs : <https://fr.wikipedia.org/wiki/Schéma_d'URI>
Considérant ce que les anglophones en comprennent <https://dictionary.cambridge.org/fr/dictionnaire/anglais-francais/schem e> j'ai choisi de traduire par "méthode". Et je constate que je ne suis pas le seul <https://www.lionbridge.com/fr/blog/global-marketing/choosing-multilingu al-url-structure-5-things-consider/> Justement il y a une note dans la Discussion <https://fr.wikipedia.org/wiki/Discussion:Schéma_d%27URI>
Pour en revenir aux URL récalcitrantes, MacCafé refuse d'ouvrir celle que tu as donnée ci-dessus. Je subodore que c'est Í cause du «Â #Â » qui définit une ancre dans la page, et si c'est le cas, c'est vraiment gênant.
Je pense que le problème ne vient pas de l'ancre. Par exemple : <https://tools.ietf.org/html/rfc8089#page-3 Par contre, j'incriminerais plutÍ´t le caractère non ASCII et accentué dans Schéma. -- Jean-Pierre Kuypers Veuillez ancrer les phrases dans leur con- texte avant de refuser sciemment.
In article (Dans l'article) <rr2ur2$bdn$2@shakotay.alphanet.ch>, DV
<dv@reply-to.not.invalid> wrote (écrivait)Â :
... SwiftDefaultApps :
Merci.
> Par ailleurs, la partie Í gauche du deux-points d'un URI, "scheme" en
> anglais, n'a rien d'un "schéma"
C'est bien beau de dire que le vocable est inapproprié, mais si on n'en
propose pas d'autre, on n'est guère avancé. Wikipédia non plus,
d'ailleurs :
<https://fr.wikipedia.org/wiki/Schéma_d'URI>
Considérant ce que les anglophones en comprennent
<https://dictionary.cambridge.org/fr/dictionnaire/anglais-francais/schem
e>
j'ai choisi de traduire par "méthode".
Et je constate que je ne suis pas le seul
<https://www.lionbridge.com/fr/blog/global-marketing/choosing-multilingu
al-url-structure-5-things-consider/>
Justement il y a une note dans la Discussion
<https://fr.wikipedia.org/wiki/Discussion:Schéma_d%27URI>
Pour en revenir aux URL récalcitrantes, MacCafé refuse d'ouvrir celle
que tu as donnée ci-dessus. Je subodore que c'est Í cause du «Â #Â »
qui définit une ancre dans la page, et si c'est le cas, c'est
vraiment gênant.
Je pense que le problème ne vient pas de l'ancre.
Par exemple : <https://tools.ietf.org/html/rfc8089#page-3
Par contre, j'incriminerais plutÍ´t le caractère non ASCII et accentué
dans Schéma.
--
Jean-Pierre Kuypers
Veuillez ancrer les phrases dans leur con-
texte avant de refuser sciemment.
In article (Dans l'article) <rr2ur2$bdn$, DV wrote (écrivait)Â :
... SwiftDefaultApps :
Merci.
Par ailleurs, la partie Í gauche du deux-points d'un URI, "scheme" en anglais, n'a rien d'un "schéma"
C'est bien beau de dire que le vocable est inapproprié, mais si on n'en propose pas d'autre, on n'est guère avancé. Wikipédia non plus, d'ailleurs : <https://fr.wikipedia.org/wiki/Schéma_d'URI>
Considérant ce que les anglophones en comprennent <https://dictionary.cambridge.org/fr/dictionnaire/anglais-francais/schem e> j'ai choisi de traduire par "méthode". Et je constate que je ne suis pas le seul <https://www.lionbridge.com/fr/blog/global-marketing/choosing-multilingu al-url-structure-5-things-consider/> Justement il y a une note dans la Discussion <https://fr.wikipedia.org/wiki/Discussion:Schéma_d%27URI>
Pour en revenir aux URL récalcitrantes, MacCafé refuse d'ouvrir celle que tu as donnée ci-dessus. Je subodore que c'est Í cause du «Â #Â » qui définit une ancre dans la page, et si c'est le cas, c'est vraiment gênant.
Je pense que le problème ne vient pas de l'ancre. Par exemple : <https://tools.ietf.org/html/rfc8089#page-3 Par contre, j'incriminerais plutÍ´t le caractère non ASCII et accentué dans Schéma. -- Jean-Pierre Kuypers Veuillez ancrer les phrases dans leur con- texte avant de refuser sciemment.
DV
Jean-Pierre Kuypers a écrit ceci :
Je pense que le problème ne vient pas de l'ancre. Par exemple : <https://tools.ietf.org/html/rfc8089#page-3
Pas l'ancre seule, mais l'ancre plus le découpage de l'URL. Cela dit, ce n'est qu'une hypothèse.
Par contre, j'incriminerais plutÍ´t le caractère non ASCII et accentué dans Schéma.
Non, parce que l'URLÂ : <https://fr.wikipedia.org/wiki/Schéma_d'URI> s'ouvre sans problème. -- Denis
Jean-Pierre Kuypers a écrit ceci :
Je pense que le problème ne vient pas de l'ancre.
Par exemple : <https://tools.ietf.org/html/rfc8089#page-3
Pas l'ancre seule, mais l'ancre plus le découpage de l'URL. Cela dit, ce
n'est qu'une hypothèse.
Par contre, j'incriminerais plutÍ´t le caractère non ASCII et accentué
dans Schéma.
In article (Dans l'article) <rr355f$2g1$, DV wrote (écrivait)Â :
Pas l'ancre seule, mais l'ancre plus le découpage de l'URL. Cela dit, ce n'est qu'une hypothèse.
Intéressant. À surveiller -- Jean-Pierre Kuypers
M.V.
Le 12 décembre 2020 Í 19 h 55, Jean-Pierre Kuypers s'est exprimé en ces termes :
Je pense que le problème ne vient pas de l'ancre. Par exemple : <https://tools.ietf.org/html/rfc8089#page-3 Par contre, j'incriminerais plutÍ´t le caractère non ASCII et accentué dans Schéma.
<https://fr.wikipedia.org/wiki/Discussion:Uniform_Resource_Locator#schéma_vs._scheme> fonctionne sans problème et amène bien au paragraphe «schéma vs. scheme». -- Michel VAUQUOISÂ -Â <http://michelvauquois.fr>
Le 12 décembre 2020 Í 19 h 55, Jean-Pierre Kuypers s'est exprimé en ces
termes :
Je pense que le problème ne vient pas de l'ancre.
Par exemple : <https://tools.ietf.org/html/rfc8089#page-3
Par contre, j'incriminerais plutÍ´t le caractère non ASCII et accentué
dans Schéma.
<https://fr.wikipedia.org/wiki/Discussion:Uniform_Resource_Locator#schéma_vs._scheme>
fonctionne sans problème et amène bien au paragraphe «schéma vs.
scheme».
--
Michel VAUQUOISÂ -Â <http://michelvauquois.fr>
Le 12 décembre 2020 Í 19 h 55, Jean-Pierre Kuypers s'est exprimé en ces termes :
Je pense que le problème ne vient pas de l'ancre. Par exemple : <https://tools.ietf.org/html/rfc8089#page-3 Par contre, j'incriminerais plutÍ´t le caractère non ASCII et accentué dans Schéma.
<https://fr.wikipedia.org/wiki/Discussion:Uniform_Resource_Locator#schéma_vs._scheme> fonctionne sans problème et amène bien au paragraphe «schéma vs. scheme». -- Michel VAUQUOISÂ -Â <http://michelvauquois.fr>
