fix: encode permalink by default

[curbengh]

What does it do?

While working on hexojs/hexo-generator-sitemap#68 and hexojs/hexo-generator-feed#93, I find it strange that plugins have to encode url themselves.

I believe url should be safe to consume by default. I can't think of any reason to use this.url in its original unescape form, except for aesthetic when displaying as a text, e.g. show http://foo.com/一二三 instead of http://foo.com/%E4%B8%80%E4%BA%8C%E4%B8%89

Displaying a full link as text should be considered as an edge case. In that case, it should be up to the user to decode it (we could write a helper to help).

Do note link inside href is decoded when mouse-over.

<a href="http://xn--fo-8ja.com/b%C3%A1r%20ab/">aaaaaaaaaaaaa</a>

It's a breaking change because existing plugins need to remove url encode function, otherwise the percent symbol gets encoded (double-encoded), e.g. foo%20bar becomes foo%25%20bar.

Note that existing plugin can remain backward compatible with v3 (if they wish) by using encodeURI(decodeURI(str)) (instead of current encodeURI(str), or use encodeURL() of hexo-util.

hexo-util is going to have decodeURL() which is an alternative to decodeURI with added ability to decode punycoded IDN.

How to test

git clone -b encode-url https://github.com/curbengh/hexo.git
cd hexo
npm install
npm test

Pull request tasks

• Add test cases for the changes.
• Passed the CI test.

[coveralls]

Coverage increased (+0.006%) to 97.236% when pulling e91aa2e on curbengh:encode-url into ab90487 on hexojs:master.

[curbengh]

I also notice an unusual behavior in tag/category name. It's automatically converted to ASCII when slugize as path, e.g. bár to bar. Maybe it is intended by slugize.

[curbengh]

Can this be part of v4? Since this is a breaking change, if this PR misses v4, it would have to be in v5 😢 .

[tomap]

I'm not sure If fully agree with this change. Because, the htmldncode should be done when ln you know that you are going to output this url into html, this at the end, in each plugin. A plugin could produce txt. And it would not be nice to ask to decode.
However I understand the intention. And this is a security feature. To be complete, it would be.important to have a raw url available, and a raw permalink. But I'm not sure if there is a need for that

[curbengh]

A plugin could produce txt. And it would not be nice to ask to decode.

That's a valid use case and a new decodeURL (to be implemented if we're going ahead with this) helper can help.

I do, however, consider that as a minor use case. Majority of the url and permalink end up in html, as such I propose to encode by default. Besides, it would be nice not to ask plugin/theme devs (outside of the aforementioned use case) to encode themselves.

Of course, my opinion could be uninformed. @theme-next is this a breaking change for theme?

---

Note that existing plugin can remain backward compatible with v3 (if they wish) by using encodeURI(decodeURI(str)) (instead of current encodeURI(str), or use encodeURL() of hexo-util.

[curbengh]

this fix is already present in https://github.com/hexojs/hexo/pull/3710/files#diff-d89aa048c56f2709ea59155d3f91aa81 , I put this as not to depend #3710