Skip to content
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

Links with hex encoded characters do not work (specifically %20) #1670

Closed
simonpoole opened this issue Oct 31, 2018 · 2 comments
Closed

Links with hex encoded characters do not work (specifically %20) #1670

simonpoole opened this issue Oct 31, 2018 · 2 comments
Labels
Milestone

Comments

@simonpoole
Copy link

@simonpoole simonpoole commented Oct 31, 2018

For the app Vespucci (see vespucci.io) we use mkdocs to create the website and a pegdown based system to use the same markdown files for on device documentation.

For various reasons the file names of the individual documents contain spaces and it would be difficult to avoid this. Inter document links work with no issue on device by encoding the spaces as %20, however this does not work with mkdocs because the logic in https://github.com/mkdocs/mkdocs/blob/master/mkdocs/structure/pages.py line 217 does not decode the path before checking if the corresponding file exists.

Naturally the same issue exists for other hex encoded characters and for using "+" as a space replacement.

PS: yes, I know it works if one does not encode the spaces, however that is not "valid" markdown and causes issues with other markdown parsers, for example pegdown.

@waylan
Copy link
Member

@waylan waylan commented Oct 31, 2018

that is not "valid" markdown

There is some disagreement about that, even among versions of the reference implementation. However...

... and causes issues with other markdown parsers, for example pegdown.

That is true and a real concern. Personally, I never use spaces in my paths and generally consider them a bad idea. But of course, others do use spaces and MkDocs should support that.

And you are correct, the way to address this is to...

decode the path before checking if the corresponding file exists.

I suppose we should also be encoding the URLs that we generate.

@waylan waylan added the Bug label Oct 31, 2018
@waylan waylan added this to the 1.1 milestone Oct 31, 2018
@simonpoole
Copy link
Author

@simonpoole simonpoole commented Oct 31, 2018

@waylan there's a reason I put "valid" in quotes :-). On output the links seem to be correctly encoded as far as I've checked, Wrt a fix: it isn't quite clear to me if there are any performance concerns if there are not, then simply decoding all paths before tacking on the directory and so on, would be the simple fix (and essentially what the money patch I'm using right now does).

waylan added a commit to waylan/mkdocs that referenced this issue Nov 2, 2018
Encode URLs of all internal documents (to acocunt for spaced in 
filenames, etc). Then unencode Markdown links to internal pages before 
confirming existance, etc. Fixes mkdocs#1670.
waylan added a commit to waylan/mkdocs that referenced this issue Nov 2, 2018
Encode URLs of all internal documents (to acocunt for spaced in 
filenames, etc). Then unencode Markdown links to internal pages before 
confirming existance, etc. Fixes mkdocs#1670.
@waylan waylan closed this in #1673 Nov 3, 2018
waylan added a commit that referenced this issue Nov 3, 2018
Encode URLs of all internal documents (to account for spaces in 
filenames, etc). Then unencode Markdown links to internal pages before 
confirming existence, etc. Fixes #1670.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants