Espaces dans les liens

Hello,

C’est encore moi avec cette fois un bug dans le zmarkdown je crois. On ne peut pas avoir de liens avec un espace, alors que c’était possible avant. Ainsi, [Jérôme Deuchnord](https://zestedesavoir.com/membres/voir/Jérôme Deuchnord/) n’est pas bien rendu.

Salut,

Je ne considère pas ça comme un bug (ou une régression). Un lien ne peut pointer que vers une URL ou un path.

Ça pose problème pour donner un lien vers certains profils. En fait, ça ne pose plus trop problème dans ZdS, vu qu’on peut avoir un lien vers un profil avec du ping.

Jérôme Deuchnord

Devrait fonctionner, une URI ne peut pas contenir d’espace.

[Jérôme Deuchnord](https://zestedesavoir.com/membres/voir/Jérôme%20Deuchnord/)

Après franchement ça coûte rien d’en parler au créateur de remark, @woorm

Ok, ni gfm ni commonmark, ni le markdown de base ne supporte la syntaxe. Même si je propose, ça ne sera jamais accepté.

Au début, je pensais que cela était dû au fait que "Deuchnord/" était le titre du lien. Mais non car il faut mettre des guillemets (simple ou double) autour du titre.

Une des vrais syntaxes d’un lien est : [Description](lien 'titre') mais il se trouve que [Description](lien titre) n’est reconnu par aucun des parsers de MD que je connaisse.

@cepus: :/ Je trouve que tu as un avis bien tranché. Je suis assez d’accord avec le fait qu’hériter de bug n’est pas le but. Reproduire des comportements idiots non plus. Mais si une fonctionnalité est couramment implémentée dans les parseurs "célèbres" et qu’elle se révèle utilise à l’utilisateur. Même si techniquement inexacte comme c’est le cas ici, je ne vois rien à redire, amha. Je sens que tu ne va pas être d’accord avec moi mais ce qui me pousse à ne pas faire la proposition est surtout de manière à garder la compatibilité avec les autres parseurs.

Une des vrais syntaxes d’un lien est : [Description](lien 'titre') mais il se trouve que [Description](lien titre) n’est reconnu par aucun des parsers de MD que je connaisse.

@cepus: :/ Je trouve que tu as un avis bien tranché. Je suis assez d’accord avec le fait qu’hériter de bug n’est pas le but. Reproduire des comportements idiots non plus. Mais si une fonctionnalité est couramment implémentée dans les parseurs "célèbres" et qu’elle se révèle utilise à l’utilisateur. Même si techniquement inexacte comme c’est le cas ici, je ne vois rien à redire, amha.

Tu n’as pas complètement tort et je veux bien tes exemples du coup. Ni commonmark ni gfm ne permet [foo](http://example.com coucou), dans quels parseurs "célèbres" cette fonctionnalité est couramment implémentée ?

J’ai effectivement un avis tranché, je te l’accorde. Si tu veux ne te décourage pas, propose ça à ceux qui travaillent sur une spec markdown (que ce soit l’originale de daringfireball, commonmark, gfm…) ou sur une implémentation (que ce soit commonmark, gfm, remark…) et compte combien n’ont pas un avis tranché en défaveur de cette proposition. (Dans le sens : peut-être que c’est pas tant une question d’avis tranché qu’une idée d’utiliser une syntaxe de base commune.)

A part ça, je n’ai que Firefox, Chrome et Safari sous la main, faisons l’expérience, prenez une URL qui contient une espace, par exemple cliquez ici : https://zestedesavoir.com/membres/voir/Jérôme%20Deuchnord/ . Copiez-collez le contenu de la barre d’adresse. Dans les 3 navigateurs en question, mon presse-papier contient une URL valide. (Normal : j’ai copié l’URL de la page sur laquelle je me trouvais, conséquence l’URL est une URL valide.)

Je colle donc cette URL ici : https://zestedesavoir.com/membres/voir/Jérôme%20Deuchnord/ et paf. Tout va bien.

Personnellement quand je copie l’URL du profil de Jérôme Deuchnord depuis Firefox, j’obtiens cette URL https://zestedesavoir.com/membres/voir/J%C3%A9r%C3%B4me%20Deuchnord/ où les accents sont encodés en %xx. Je ne connaît pas les spécifications exactes d’une URI ou d’une URL mais est-ce que les accents bruts sont acceptés ?

En tous cas, si la décision est prise de rester sur le comportement actuel où les espaces doivent être encodés, il faudrait modifier l’éditeur pour que le bouton pour créer un lien fasse la transformation automatiquement (car d’accord quand on copie depuis un navigateur c’est déjà encodé, mais ce n’est pas le cas partout).

@cepus: :/ Je trouve que tu as un avis bien tranché. Je suis assez d’accord avec le fait qu’hériter de bug n’est pas le but. Reproduire des comportements idiots non plus. Mais si une fonctionnalité est couramment implémentée dans les parseurs "célèbres" et qu’elle se révèle utilise à l’utilisateur. Même si techniquement inexacte comme c’est le cas ici, je ne vois rien à redire, amha.

Des bibliothèques comme ffmpeg donnent un bon exemple de pourquoi c’est parfois mauvais de vouloir supporter plus que ce qui devrait être le cas.

Typiquement, beaucoup de fichiers sont produits à partir de logiciels testés avec ffmpeg, qui lisait le fichier correctement en ignorant des parties de la norme xxxxx lié au demux ou décodeur. Derrière ce sont des bugs répercutés sur les logiciels qui essayent de respecter la norme, et tu te retrouves dans une situation où la norme/spec est devenue inutile parce que le marché est inondé de fichiers qui ne la respectent pas. Finalement tu dois introduire des workaround dégueu dans les lecteurs un peu plus avancés pour parser ces fichiers spéciaux au cas par cas, sans avoir de référence qui te dit comment les supporter. Dans le cas de zmarkdown ça revient à perdre les avantages de la réécriture sans workaround.

Dans cette situation, le problème pour moi n’est pas tant le zmarkdown qui doit supporter l’échappement des caractères spéciaux (dont la RFC est une plaie à comprendre), mais plutôt l’éditeur qui devrait signaler cela/faire l’échappement automatique. Après le fait que les URLs soient pas user-friendly pour les utilisateurs c’est la source du problème et tu peux aussi le corriger en étant certain de toujours générer des urls user-friendly.

Personnellement quand je copie l’URL du profil de Jérôme Deuchnord depuis Firefox, j’obtiens cette URL https://zestedesavoir.com/membres/voir/J%C3%A9r%C3%B4me%20Deuchnord/ où les accents sont encodés en %xx. Je ne connaît pas les spécifications exactes d’une URI ou d’une URL mais est-ce que les accents bruts sont acceptés ?

Oui : <http://example.com/éöuhelloïøhey>: http://example.com/éöuhelloïøhey

Absolument d’accord avec toi. (Pour ce faire tu peux ouvrir un ticket côté ZdS, ça ne concerne pas zmarkdown.)

tu peux aussi le corriger en étant certain de toujours générer des urls user-friendly.

Absolument ! Ce qui est user input et qu’on flanque dans une URL, ça devrait être slugified, pas en brute comme ça avec des espaces ! (C’est à dire : ce qu’on fait subir aux titres de topics dans l’URL, c’est ça qu’il aurait fallu appliquer aux URLs vers les profils de membres. (Et c’est pas parce que ça a été fait faux y’a 5 ans à la création de ZdS qu’il faut exprès reproduire la faute dans zmarkdown "parce que c’est pratique". ))

Tu n’as pas complètement tort et je veux bien tes exemples du coup. Ni commonmark ni gfm ne permet [foo](http://example.com coucou), dans quels parseurs "célèbres" cette fonctionnalité est couramment implémentée ?

Aucun justement ! Comme je l’ai dis, je n’en ai trouvé aucun qui est capable de lire cette syntaxe (j’en ai testé 3 mais 1 seul suffisait pour me décourager de le faire) . Et donc pour des raisons de portabilité compatibilité je n’irais pas proposer cette syntaxe.

En fait non, cf la page 15 de la RFC 3986. C’est juste que pour des raisons pratiques, la plupart des clients gèrent automatiquement la traduction « caractère UTF-8 ↔ version encodée avec un % devant », et Firefox a fait le choix de mettre la version encodée dans le presse-papier.

L’une des conséquences, c’est que 99% du travail de « slugification » qu’on trouve dans le monde est parfaitement inutile, les seuls caractères qu’il est vraiment utile de corriger, c’est ceux qui sont réellement spéciaux/interdits dans une URL (espace, point d’interrogation, slash… mais pas tous les caractères UTF-8 non ASCII dont le cas est déjà très bien géré par défaut). Cf, par exemple, toutes les URLs de Wikipedia.

Sous Firefox j’ai : http://example.com/%C3%A9%C3%B6uhello%C3%AF%C3%B8hey avec http://example.com/éöuhelloïøhey

Tu devrais être plus précis, l’auteur n’a peut être pas le recule suffisant pour comprendre que tu fais mention à la spécificité de l’espace qui est encodé en %20.

NB : Le bouton aperçu va finir coupé en morceau

Tu devrais relire le sujet. OP décrit ce qu’il croit être un bug. Je réponds que je ne considère pas comme bug ce qu’il croit être un bug et j’explique pourquoi.

Ben, c’est peut-être pas un bug, mais c’est quand même plutôt chiant vu que dans mes contenus, j’écris certains liens à la main. Comme je l’ai dit plus haut, pour les profils c’est OK vu qu’on peut maintenant utiliser le ping.

Si on est d’accord que produire des urls avec des espaces est pourri, on peut remplacer voir/{pseudo} par voir/{id}/{slug-pseudo} par exemple (pour les autres pages qui posent problème) et corriger le problème pour Zestedesavoir. Après ça me parait difficile de vouloir corriger ça pour d’autres cas que Zestedesavoir sans un éditeur qui te signale ça, et en en reparlant ça me parait plus être une feature du navigateur (via extension ou stuff pour convertir tes liens ou autre) qu’une feature du parseur markdown.

Je vois deux solutions pragmatiques au problème de @Karnaj : retenir %20 et l’écrire à la main, ou ne pas écrire manuellement d’url contenant des espaces.