New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liens et caractères spéciaux #68

Closed
Florianboux opened this Issue Jun 18, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@Florianboux

Florianboux commented Jun 18, 2015

Remonté par Holomos sur le forum :

Plop,

J'arrive pas à bien utiliser ce lien dans les balises : https://fr.wikipedia.org/wiki/Compactifié_d%27Alexandrov

Quand je le fais là par exemple ça fait … autre chose qui ne passe pas.

Et effectivement dans le lien cliquable, le lien, bug.. C'est notamment dû aux caractères spéciaux je pense, car dans le premier cas le %27 de l'url est correctement interprété, alors que dans le second cas, non !

@yapper-git

This comment has been minimized.

Show comment
Hide comment
@yapper-git

yapper-git Jun 22, 2015

Actuellement le parseur markdown échappe les caractères spéciaux de l'url lorsque l'on utilise la syntaxe [texte](lien). Je me demande si ce comportement est vraiment souhaitable.
D'ailleurs le parseur markdown par défaut n'échappe pas les caractères spéciaux.

J'ai repéré ce comportement en voulant corriger un bug sur zds-site, voir zestedesavoir/zds-site#2301
Le lien vers la page de profil d'un membre donné par le backend, est déjà quoté, prêt à l'emploi. C'est notamment utilisé lorsque l'on signale une typo dans un article ou un tutoriel. ZdS envoie un mail à l'auteur en mettant un lien sur le pseudo de l'auteur.
Du coup l'URL (dans le MP envoyé) est à nouveau quotée par le parseur markdown, donc doublement quoté au final. Actuellement la page de profil accepte des paramètres doublement quotés, grâce à un urlunquote (voir https://github.com/zestedesavoir/zds-site/blob/dev/zds/member/views.py#L68) à cause justement du comportement actuel du parseur markdown.

Actuellement en saisissant:

- https://fr.wikipedia.org/wiki/Compactifié_d'Alexandrov
- https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov
- [Compactifié d'Alexandrov](https://fr.wikipedia.org/wiki/Compactifié_d'Alexandrov)
- [Compactifié d'Alexandrov](https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov)

on obtient:

<ul>
<li>https://fr.wikipedia.org/wiki/Compactifié_d'Alexandrov</li><!-- non détecté -->
<li><a href="https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov">https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov</a></li><!-- OK -->
<li><a href="https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov">Compactifié d'Alexandrov</a></li><!-- OK -->
<li><a href="https://fr.wikipedia.org/wiki/Compactifi%25C3%25A9_d%2527Alexandrov">Compactifié d'Alexandrov</a></li><!-- invalide -->
</ul>

Je trouve cela pas très cohérent d'ailleurs entre les liens automatiques et les liens manuels (avec la syntaxe [texte](lien)).

yapper-git commented Jun 22, 2015

Actuellement le parseur markdown échappe les caractères spéciaux de l'url lorsque l'on utilise la syntaxe [texte](lien). Je me demande si ce comportement est vraiment souhaitable.
D'ailleurs le parseur markdown par défaut n'échappe pas les caractères spéciaux.

J'ai repéré ce comportement en voulant corriger un bug sur zds-site, voir zestedesavoir/zds-site#2301
Le lien vers la page de profil d'un membre donné par le backend, est déjà quoté, prêt à l'emploi. C'est notamment utilisé lorsque l'on signale une typo dans un article ou un tutoriel. ZdS envoie un mail à l'auteur en mettant un lien sur le pseudo de l'auteur.
Du coup l'URL (dans le MP envoyé) est à nouveau quotée par le parseur markdown, donc doublement quoté au final. Actuellement la page de profil accepte des paramètres doublement quotés, grâce à un urlunquote (voir https://github.com/zestedesavoir/zds-site/blob/dev/zds/member/views.py#L68) à cause justement du comportement actuel du parseur markdown.

Actuellement en saisissant:

- https://fr.wikipedia.org/wiki/Compactifié_d'Alexandrov
- https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov
- [Compactifié d'Alexandrov](https://fr.wikipedia.org/wiki/Compactifié_d'Alexandrov)
- [Compactifié d'Alexandrov](https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov)

on obtient:

<ul>
<li>https://fr.wikipedia.org/wiki/Compactifié_d'Alexandrov</li><!-- non détecté -->
<li><a href="https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov">https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov</a></li><!-- OK -->
<li><a href="https://fr.wikipedia.org/wiki/Compactifi%C3%A9_d%27Alexandrov">Compactifié d'Alexandrov</a></li><!-- OK -->
<li><a href="https://fr.wikipedia.org/wiki/Compactifi%25C3%25A9_d%2527Alexandrov">Compactifié d'Alexandrov</a></li><!-- invalide -->
</ul>

Je trouve cela pas très cohérent d'ailleurs entre les liens automatiques et les liens manuels (avec la syntaxe [texte](lien)).

@cgabard

This comment has been minimized.

Show comment
Hide comment
@cgabard

cgabard May 3, 2016

Member

Toute la partie sur la syntaxe [...]() est actuellement corrigé, il reste a uniformiser avec les liens libres.

Member

cgabard commented May 3, 2016

Toute la partie sur la syntaxe [...]() est actuellement corrigé, il reste a uniformiser avec les liens libres.

cgabard pushed a commit that referenced this issue May 9, 2016

christophe
Specific zds-extensions tests : align
Rajoute des tests pour l'extension "align".

Un bug a été corrigé au passage, correspondant au #68 (ce qui explique les tests multiples d'une meme expression, pour vérifier que le parseur s'arrete à la première expression de fin trouvée).

Extension qui mériterai probablement d'être simplifiée mais cela fonctionne et normalement sans bug.

ArnaudCalmettes added a commit that referenced this issue May 10, 2016

Fix #82 + add tests for zds "align" extension #84
* Specific zds-extensions tests : align

Rajoute des tests pour l'extension "align".

Un bug a été corrigé au passage, correspondant au #68 (ce qui explique les tests multiples d'une meme expression, pour vérifier que le parseur s'arrete à la première expression de fin trouvée).

Extension qui mériterai probablement d'être simplifiée mais cela fonctionne et normalement sans bug.

* fix flake8

* Increase coverage with special case and add comments

* flake8

* Precision over a special case not covered

cgabard pushed a commit that referenced this issue May 10, 2016

christophe

ArnaudCalmettes added a commit that referenced this issue May 11, 2016

@cgabard

This comment has been minimized.

Show comment
Hide comment
@cgabard

cgabard May 11, 2016

Member

C'est maintenant corrigé de notre coté !

Member

cgabard commented May 11, 2016

C'est maintenant corrigé de notre coté !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment